Проектирование и реализация системы обмена мгновенными сообщениями

задняя часть

1. Объяснение терминов

  • Одноадресная рассылка: сервер отправляет сообщение одному пользователю клиента.
  • Многоадресная рассылка: сервер отправляет сообщения нескольким пользователям-клиентам.
  • Multicast / Broadcast: сервер отправляет сообщение группе клиентов. Есть идентификатор группы для идентификации этой группы пользователей
  • Вверх по течению сообщения: сервер отправляет сообщение группе клиентов. Есть идентификатор группы для идентификации этой группы пользователей
  • Сообщение нисходящего канала: сервер отправляет сообщение клиенту

2. Архитектура системы

  • прокси: развернут в пограничном компьютерном зале, клиент обращается рядом через smart dns
  • LogicService: обрабатывает аутентификацию, сердцебиение, онлайн и оффлайн, внутри и вне групп.
  • pushService: одноадресная рассылка, широковещательная рассылка, пересылка на комету после получения сообщения, а затем отправка сообщения кометой
  • imService: сервер чата, обработка группового чата с одним чатом, автономные сообщения
  • Cosumerservice: асинхронная диффузия записи для групповых сообщений
  • AuthService: служба аутентификации

структура данных

cacheService поддерживает глобальных онлайн-пользователей и является вторичной картойuser_id -> conn_id -> server_id.

  • user_id определяется компанией и однозначно идентифицирует пользователя.
  • conn_id, выделенный процессом памяти, однозначно идентифицирует пользователя соединения.
  • server_id определяет, какому процессу доступа принадлежит это соединение.

Прокси-сервер процесса доступа поддерживает своих онлайн-пользователей,user_id+conn_id -> Connection

  • Соединение — это оболочка для клиентского соединения, на которое могут быть отправлены сообщения.

Прокси процесса доступа поддерживает информацию о комнате соединений,room_id -> ConnectionList

В-третьих, модель сообщения

3.1 Чтение диффузионной модели

  • Преимущества: напишите только один раз, уменьшая количество пишет, особенно в групповом режиме
  • Недостатки: Логика сообщений синхронизации будет более сложной, и каждый сеанс принимающей стороны считывается один раз, расширенное чтение будет генерировать много недействительных запросов.

3.2 Написание модели распространения

  • Преимущества: Логика получения сообщений проста.
  • Недостатки: Увеличено и написано, одиночный чат нужно написать дважды, а группу нужно написать N раз

В-четвертых, метод реализации

4.1 Чат один на один

4.1.1 Цели дизайна

4.1.2 Онлайн-сообщения

4.1.3 Офлайн-сообщения

4.1.4 Обнаружение потери сообщения

4.2 Групповой чат

4.2.1 Цели проектирования

4.2.2 Малые группы (распространение записи)

4.2.3 Большие группы (читай диффузия)

5. Высокопроизводительный анализ

Узкое место ЦП > Пропускная способность > Память

5.1 Планирование емкости: (облачный хост Alibaba 16C32G-2,5 ГГц, резерв 50% запаса)

  • 10,000 conn per proxy
  • 100 proxy
  • 50 logicService/cacheService/pushService
  • или улучшенный:
    • 10 logicService
    • 5 pushService
    • kafka cluster
    • zookeeper cluster
    • 10 cacheService

5.2 Узких мест во внутренней коммуникации нет, а пути горизонтального расширения:

  • RPC, инициированный клиентом mobile -> proxy -> micro
  • Перейти в онлайн/офлайн/переключиться на мобильный телефон/сердцебиение -> прокси -> LogicService -> cacheService
  • Unicast micro -> logicService (-> cacheService) -> pushService -> прокси -> мобильный
  • Информационный запрос онлайн
    • Проверить онлайн-комнаты/сеансы по пользователю

5.3 Внутренняя связь, пути, которые могут иметь узкие места:

  • Bulk unicast micro -> logicService ((N-parallel) -> router) -> pushService -> proxy -> mobile
    • Ограничение: общее количество пользователей в пакете, не слишком много
  • Broadcast micro -> logicService -> pushService -> proxy -> mobile
    • Ограничение: Поскольку pushService регулярно поглощает список комнат на прокси, количество pushService не должно быть слишком большим.
    • Улучшение: отделить LogicService и pushService и использовать kafka для подключения. Поскольку pushService потребляет меньше всего ЦП среди proxy/logicService/cacheService, требуется очень мало экземпляров pushService.
  • Информационный запрос онлайн
    • Проверьте общее количество подключенных к сети /count Так как LogicService регулярно поглощает пользователей комнаты в cacheService, только ограниченное количество LogicService может открывать счетчик для регулярной проверки.
    • Проверять пользователей по комнате/комнате с помощью /count
    • Интерфейс Traverse/list для отладки, а не для служб

5.4 узкие места производительности прокси

Узкое место производительности 5,5 RPC

6. Анализ высокой доступности

Предоставьте пользователям 7-24 часа бесперебойной работы. Итеративная разработка требует обновления и расширения внутренних модулей и бизнес-сервисов, чтобы пользователи не знали об этом.

  • Прокси — это служба без сохранения состояния.При перезапуске или обновлении клиент обнаруживает, что соединение отключено, и автоматически переподключается к другому прокси.
  • logicService — это служба без сохранения состояния, при перезапуске или обновлении прокси автоматически найдет следующую логику
  • pushService — это служба без сохранения состояния.При перезапуске и обновлении появляются другие pushServices, предоставляющие услуги внешнему миру.
  • cacheService — это stateful-сервис, при перезапуске или обновлении резервный cacheService оказывается сверху, а по завершении обновления переключается обратно на основной cacheService.
  • imService — это служба без сохранения состояния.При перезапуске и обновлении появляются другие pushServices, предоставляющие услуги внешнему миру.
  • mysql: используйте мастер-механизм mysql master, чтобы гарантировать
  • Redis: использовать дозорный механизм для обеспечения доступности

7. Обработка исключений

  • Как предотвратить потерю сообщения (принимающая сторона сообщает о максимальном полученном идентификаторе сообщения, а аварийный сервер отправляет его повторно)
  • Переключатель Redis master-slave вызывает прерывистый идентификатор автоинкремента
  • Как повысить производительность прокси-трансляции
  • Как избежать того, чтобы одно соединение rpc стало узким местом

8. Низкая стоимость и безопасность

  • Практически полное отсутствие внешних зависимостей, чрезвычайно низкие затраты на эксплуатацию и техническое обслуживание.
  • Высокопроизводительная реализация кода, экономия затрат на сервер
  • Встроенная аутентификация и аутентификация, также поддерживает HTTPS

(Заканчивать)