Skip to content

Latest commit

 

History

History
58 lines (49 loc) · 6.31 KB

7hw.md

File metadata and controls

58 lines (49 loc) · 6.31 KB

Масштабируемая подсистема диалогов

Цель:

  • Отправка сообщения пользователю (метод /dialog/{user_id}/send из спецификации)
  • Получение диалога между двумя пользователями (метод /dialog/{user_id}/list из спецификации)
  • Обеспечить горизонтальное масштабирование хранилищ на запись с помощью шардинга.
  • Предусмотреть: Возможность решардинга

Реализация:

  • в ходе выполнения работы написан микросервис диалогов

  • подключены прометеус и графана для просмотра метрик приложения

  • реализован алгоритм консистентного хэширования, который размазывает данные по шардам

    • данный подход поможет реализовывать решардинг с меньшими потерями, в отличие от определения через обычное хэширование

  • в качестве проверки было имплементировано 2 "шарда"

    • инфраструктурный код, регистрирующий базки в алгоритме консистентного хэширования: код
    • компоуз с контейнерами: код

  • реализованы 3 ручки

    • создание диалога [POST] localhost:8070/dialog
    • создание сообщения [POST] localhost:8070/dialog/send
    • получение сообщений в диалоге [GET] localhost:8070/dialog/{dialogId}/list

  • ключом шардинга является dialogID потому что следует держать все сообщения для одного диалога в одном и том же шарде

  • можно было бы сделать размазывание по dialogID и времени написания сообщения, но хотелось сделать самописное решение, которое сможет хотя бы базово работать с шардированием

  • в качестве продового решения стоит использовать ydb. (ну или монгу, если хочется Nosql решения)

    • данные инструменты из коробки позволяют использовать шардирование, причем без даунтайма

  • в моем решении самым простым решением шардирования без даунтайма может быть следующее:

    • создаем N подов с приложением и катим туда новую версию.
    • создаем копию шардов + новые шарды и решардируемся уже в нее
    • отключаем запись в старой версии и катим решардинг одновременно с этим изменением
    • возможны аномалии и разъезд стейта, на старых данных
    • это достаточно коряво ;) поэтому стоит сразу использовать надстройки над постгрей (не самописные), которые знают в каком шарде сейчас лежат данные.

Схема:

dialog.png

Запуск и проверка

  1. склонировать данный репозиторий и поднять его с помощью команды make rebuild
  2. склонировать cервис диалогов и поднять его с помощью команды make rebuild
  3. зарегистрироваться в ручке /user/register (для проверки будет достаточно двух пользователей).
  4. залогиниться и получить свой токен для авторизации для обоих пользователей (в каждом последующем запросе его передавать в заголовке Authorization).
  5. создать диалог [POST] localhost:8070/dialog (в ручке сервиса диалогов) или в [POST] localhost:8080/dialog.
  6. отправить сообщение в диалог [POST] localhost:8070/dialog/send (в ручке сервиса диалогов) или в [POST] localhost:8080/dialog/send.
  7. получить все сообщения в диалоге [GET] localhost:8070/dialog/{dialogId}/list (в ручке сервиса диалогов) или в [GET] localhost:8080/dialog/{dialogId}/list.
  8. все необходимые ручки есть в постман коллекции. В работе можно использовать ручки в коллекции 8th hw http collection.

Логи:

2024-07-05T18:19:08.561Z        INFO    servers/http.go:146     http request: localhost:8070/dialog/dlgd5f0c5434208b46a98cbfdcf0ea06798f/list
2024-07-05T18:19:08.577Z        INFO    sharder/core.go:75      get shard: second_shard

2024-07-05T18:18:53.019Z        INFO    servers/http.go:146     http request: localhost:8070/dialog
2024-07-05T18:18:53.044Z        INFO    sharder/core.go:75      get shard: first_shard

2024-07-05T18:57:16.406Z        INFO    servers/http.go:146     http request: localhost:8070/dialog/send
2024-07-05T18:57:16.465Z        INFO    sharder/core.go:75      get shard: second_shard
  • из логов видно, что запросы размазываются по разным шардам и все методы работают корректно