Резюме:Предисловие Полное название службы обмена мгновенными сообщениями — «Обмен мгновенными сообщениями», а китайское название — «Обмен мгновенными сообщениями». В эпоху мобильного Интернета, основанного на информации, продукты для обмена мгновенными сообщениями стали обязательными в жизни, а такие известные продукты, как DingTalk, WeChat и QQ, имеют IM в качестве основной функции. Конечно, WeChat превратился в экологический продукт, но его основной функцией по-прежнему остается обмен мгновенными сообщениями.
предисловие
Полное название службы обмена мгновенными сообщениями — «Обмен мгновенными сообщениями», а китайское — «Обмен мгновенными сообщениями». В эпоху мобильного Интернета, основанного на информации, продукты для обмена мгновенными сообщениями стали обязательными в жизни, а такие известные продукты, как DingTalk, WeChat и QQ, имеют IM в качестве основной функции. Конечно, WeChat превратился в экологический продукт, но его основной функцией по-прежнему остается обмен мгновенными сообщениями. Существуют также некоторые приложения, не ориентированные на систему обмена мгновенными сообщениями, такие как некоторые онлайн-игры и приложения для социальных сетей, для которых обмен мгновенными сообщениями также является важным функциональным модулем. Можно сказать, что для приложений с социальными атрибутами функция обмена мгновенными сообщениями должна быть незаменимой.
Система обмена мгновенными сообщениями существовала на заре Интернета, и ее базовая техническая архитектура неоднократно обновлялась и итерировалась за последние десять лет.Из ранней архитектуры CS и P2P фон превратился в сложную распределенную систему, включающую мобильные устройства. терминалы, все аспекты технологии, такие как сеть, безопасность и хранение. Масштабы его поддержки также изменились: от небольшого количества активных пользователей в день в первые дни до последнего объявления гиганта WeChat о достижении 900 миллионов активных пользователей в день.
Основной частью системы обмена мгновенными сообщениями является система сообщений, а основной функцией системы сообщений является синхронизация и хранение сообщений:
синхронизация сообщений: Полная и быстрая доставка сообщения от отправителя к получателю является синхронизацией сообщения. Наиболее важными показателями для системы синхронизации сообщений являются режим реального времени, целостность и поддерживаемый размер доставки сообщений. Функционально он обычно поддерживает как минимум онлайн- и офлайн-продвижение, а продвинутые системы обмена мгновенными сообщениями также поддерживают «многотерминальную синхронизацию».
хранилище сообщений: Хранилище сообщений - это постоянное хранилище сообщений. Это относится не к локальному хранилищу сообщений на стороне клиента, а к хранилищу в облаке. Функция соответствует "роумингу сообщений". Преимущество «роуминга сообщений» заключается в том, что учетная запись может войти в систему с любого конца, чтобы просмотреть все исторические сообщения, что также является одной из уникальных функций усовершенствованной системы обмена мгновенными сообщениями.
Содержание этой статьи в основном связано с архитектурой системы сообщений в системе обмена мгновенными сообщениями. В ней будет представлена синхронизация сообщений на основе TableStore и реализация архитектуры системы хранения, которая может поддерживать расширенные функции системы сообщений «многотерминальная синхронизация». и «роуминг сообщений». С точки зрения производительности и масштаба, он может обеспечить полное облачное хранилище сообщений, миллионы TPS и возможности синхронизации сообщений с миллисекундной задержкой.
Архитектурный дизайн
Эта глава в основном знакомит с архитектурой современной системы обмена мгновенными сообщениями на основе TableStore.Прежде чем подробно представить структуру архитектуры, будет представлена логическая модель временной шкалы, чтобы абстрагироваться и упростить понимание модели синхронизации и хранения IM-сообщений. После понимания модели временной шкалы мы познакомимся с тем, как моделировать синхронизацию и хранение сообщений на основе этой модели. На основе модели временной шкалы будут технические компромиссы в различных аспектах при реализации синхронизации и хранения сообщений, например, как сравнить и выбрать две общие модели распространения чтения и распространения записи для синхронизации сообщений, а также как выбрать нижний уровень. в соответствии с характеристиками модели временной шкалы базы данных.
Традиционная архитектура против современной архитектуры
На рисунке выше показано простое сравнение традиционной архитектуры системы обмена сообщениями и современной архитектуры.
В традиционной архитектуре сообщения сначала синхронизируются, а затем сохраняются. Для онлайн-пользователей сообщение будет напрямую синхронизировано с онлайн-приемником в режиме реального времени. После успешной синхронизации сообщение не будет сохранено. Для пользователей, не подключенных к сети, или когда сообщение не может быть успешно синхронизировано в режиме реального времени, сообщение будет сохранено в автономной библиотеке.Когда получатель повторно подключится, все непрочитанные сообщения будут извлечены из автономной библиотеки. После того, как сообщение в автономной библиотеке будет успешно синхронизировано с получателем, сообщение будет удалено из автономной библиотеки. В традиционных системах обмена сообщениями основная задача сервера заключается в поддержании состояния соединения между отправителем и получателем, а также в обеспечении онлайн-синхронизации сообщений и возможностей автономного кэширования сообщений, чтобы гарантировать, что сообщения могут быть доставлены от отправителя к получателю. Сервер не сохраняет сообщения, поэтому он не может поддерживать перемещение сообщений.
В современных архитектурах сообщения сначала сохраняются, а затем синхронизируются. Преимущество предварительного сохранения, а затем синхронизации заключается в том, что если получатель подтвердит получение сообщения, оно должно быть сохранено в облаке. И сообщения будут храниться в двух репозиториях, один из которых является репозиторием сообщений, который используется для полного хранения сообщений всех сеансов, в основном используемых для поддержки роуминга сообщений. Другая — это библиотека синхронизации сообщений, которая в основном используется для многотерминальной синхронизации приемника. После того как сообщение отправлено отправителем, оно пересылается сервером, и сервер сначала сохраняет сообщение в хранилище сообщений, а затем сохраняет его в хранилище синхронизации сообщений. После того, как постоянное сохранение сообщения будет завершено, для онлайн-получателя будет напрямую выбран онлайн-пуш. Но онлайн-пуш — это не обязательный путь, а просто лучший путь доставки сообщений. Для получателей, которые не могут отправить сообщение онлайн или находятся в автономном режиме, будет использоваться другой унифицированный метод синхронизации сообщений. Получатель будет активно извлекать все несинхронизированные сообщения с сервера, но серверу неизвестно, когда приемник будет синхронизироваться и какие терминалы будут синхронизировать сообщения, поэтому сервер должен сохранять все сообщения, которые необходимо синхронизировать, на приемнике. Это основная роль библиотеки синхронизации сообщений. Для новых устройств синхронизации потребуется роуминг сообщений, который является основной ролью репозитория сообщений.В репозиторий сообщений может быть извлечен полный объем исторических сообщений любой сессии.
Выше приведено простое сравнение между традиционной архитектурой и современной архитектурой.Процесс синхронизации и хранения всего сообщения в современной архитектуре не становится слишком сложным, но он может обеспечить многотерминальную синхронизацию и роуминг сообщений. Ядром современной архитектуры являются две библиотеки сообщений «библиотека синхронизации сообщений» и «библиотека хранения сообщений», которые являются основной основой синхронизации и хранения сообщений. Остальная часть этой статьи посвящена разработке и реализации этих двух библиотек.
Модель временной шкалы
Прежде чем анализировать дизайн и реализацию «библиотеки синхронизации сообщений» и «репозитория сообщений», в этой главе будет представлена логическая модель — временная шкала. Модель временной шкалы поможет нам упростить понимание модели синхронизации и хранения сообщений, а проектирование и реализация библиотеки сообщений также основаны на характеристиках и требованиях временной шкалы.
Фигура - это абстрактное представление модели временной шкалы. Сроки можно просто понять как очередь сообщений, но это очередь сообщений имеет следующие характеристики:
Каждое сообщение имеет идентификатор последовательности (SeqId).SeqId сообщения в конце очереди должен быть больше, чем SeqId предыдущего сообщения, то есть гарантировано, что SeqId должен увеличиваться, но не требуется строго увеличивать.
Новые сообщения всегда добавляются в конце, гарантируя, что SeqId нового сообщения всегда больше, чем сообщение, уже находящееся в очереди.
Согласно SeqId, конкретное сообщение может быть случайно расположено для чтения, или все сообщения в заданном диапазоне могут быть прочитаны произвольно.
Благодаря этим функциям синхронизацию сообщений можно легко реализовать с помощью Timeline. В примере на рисунке отправителем сообщения является A, получателем сообщения является B, а B имеет несколько получателей, а именно B1, B2 и B3. A отправляет сообщение B, и это сообщение необходимо синхронизировать с несколькими концами B. Сообщения, которые необходимо синхронизировать, передаются через временную шкалу. Все сообщения, отправленные от A к B, будут храниться на этой временной шкале, и каждый получатель B будет извлекать сообщения из этой временной шкалы независимо. После того, как каждая принимающая сторона будет синхронизирована, она локально запишет SeqId последнего синхронизированного сообщения, то есть самое последнее местоположение, в качестве начального местоположения для синхронизации следующего сообщения. Сервер не сохраняет состояние синхронизации каждого терминала, и каждый терминал может начать получать сообщения из любой точки в любое время.
Роуминг сообщений также основан на временной шкале, и единственное отличие от синхронизации сообщений заключается в том, что для роуминга сообщений сервер должен иметь возможность сохранять все данные на временной шкале.
На основе временной шкалы легко понять, как реализовать синхронизацию и хранение сообщений на стороне сервера из логической модели, а также поддерживаются расширенные функции, такие как многотерминальная синхронизация и роуминг сообщений. Сложность перехода к реализации заключается в том, как сопоставить логическую модель с физической моделью.Какие требования будут предъявляться к базе данных при реализации Timeline? Какую базу данных мы должны выбрать для реализации? Вот вопросы, которые будут обсуждаться далее.
модель хранения сообщений
Как показано в модели хранения сообщений на основе временной шкалы, для хранения сообщений требуется, чтобы каждый сеанс соответствовал независимой временной шкале. Как показано в примере на рисунке, у A и B/C/D/E/F есть беседы. Каждая беседа соответствует независимой временной шкале. Каждая временная шкала содержит все сообщения в беседе. Сервер может сохранять полный объем сообщений на всех временных шкалах сеансов и, таким образом, имеет возможность перемещать сообщения.
модель синхронизации сообщений
Модель синхронизации сообщений немного сложнее, чем модель хранения сообщений.Как правило, существует два разных способа синхронизации сообщений: распространение чтения и распространение записи, которые соответствуют разным физическим моделям временной шкалы.
Как показано на рисунке, существуют разные модели временной шкалы, соответствующие двум различным режимам синхронизации: распространение чтения и распространение записи.Согласно примеру на рисунке, A, как получатель сообщения, ведет диалог с B/C/D/E. / F. Каждый Все новые сообщения в сеансе должны быть синхронизированы с определенным концом A. Давайте посмотрим, как сообщения синхронизируются в двух режимах распространения чтения и распространения записи.
чтение диффузии: в модели хранения сообщений временная шкала каждого сеанса хранит полное количество сообщений сеанса. В режиме синхронизации сообщений при распространении чтения новые сообщения, сгенерированные в каждом сеансе, необходимо записать на временную шкалу, используемую для хранения, только один раз, и принимающая сторона извлекает новые сообщения из этой временной шкалы. Преимущество состоит в том, что сообщение нужно написать только один раз, что может значительно сократить количество записываемых сообщений по сравнению с режимом распространения записи, особенно в случае групповых сообщений. Однако относительно очевидны и его недостатки: логика рассинхронизации сообщений на принимающей стороне относительно сложна и неэффективна. Принимающая сторона должна выполнить один раз для каждого сеанса, чтобы получить все сообщения, чтение значительно усиливается, и будет много недействительных чтений, потому что не в каждом сеансе будут новые сообщения.
написать диффузию: в режиме синхронизации сообщений при распространении записи для синхронизации сообщений требуется дополнительная временная шкала.Обычно каждый получатель будет иметь независимую временную шкалу синхронизации для хранения всех сообщений, которые необходимо синхронизировать с получателем. Сообщения в каждом сеансе будут записаны несколько раз.В дополнение к временной шкале сеанса, используемой для хранения сообщений, также необходимо записать временную шкалу синхронизации принимающей стороны, которую необходимо синхронизировать. В разговоре между людьми сообщение записывается дважды дополнительно, в дополнение к сохраненной временной шкале разговора, а также к временной шкале синхронизации двух получателей, участвующих в разговоре. В групповом сценарии записи будут еще более усилены: если в группе N участников, каждое сообщение нужно записать N дополнительных раз. Преимущество режима синхронизации с распространением записи заключается в том, что логика синхронизации сообщений на принимающей стороне очень проста, и ему нужно только один раз прочитать из своей временной шкалы синхронизации, что значительно снижает давление чтения, необходимое для синхронизации сообщений. Недостатком является то, что написание сообщений будет усилено, особенно для групп.
В сценарии применения IM обычно выбирается режим синхронизации сообщений с распространением записи. В сценарии обмена мгновенными сообщениями сообщение будет создано только один раз, но будет прочитано несколько раз.Это типичный сценарий большего количества операций чтения и меньшего количества операций записи.Соотношение операций чтения и записи сообщений составляет примерно 10:1. Если используется режим синхронизации диффузии чтения, соотношение чтения/записи всей системы будет увеличено до 100:1. Хорошо оптимизированная система должна быть спроектирована так, чтобы сбалансировать это давление чтения-записи и избежать любого одномерного чтения или записи, достигающего потолка. Поэтому в таких сценариях, как системы обмена мгновенными сообщениями, режим синхронизации распространения записи обычно применяется для балансировки чтения и записи, а соотношение чтения и записи 100:1 уравновешивается соотношением 30:30. Конечно, режим синхронизации распространения записи также должен работать в некоторых экстремальных сценариях, таких как большая группа из 10 000 человек. Для таких экстремальных сценариев распространения записи он сведется к использованию распространения чтения. Простая система обмена мгновенными сообщениями обычно ограничивает существование таких больших групп на уровне продукта, в то время как в продвинутой системе обмена мгновенными сообщениями для удовлетворения потребностей таких продуктов используется смешанный режим синхронизации чтения-записи.
дизайн базы сообщений
Основываясь на модели временной шкалы и применении модели временной шкалы в хранилище сообщений и синхронизации сообщений, давайте рассмотрим структуру библиотеки синхронизации сообщений и библиотеки хранения сообщений.
На картинке показан дизайн библиотеки сообщений на основе Timeline.
Библиотека синхронизации сообщений: База данных сообщений Synchronization для хранения сообщений для всех временных шкале синхронизации, каждая графика, соответствующая приемному терминалу, используется в основном в качестве диффузионного режима сообщения Synchronization. Эта библиотека не должна постоянно хранить все сообщения, которые необходимо синхронизировать, потому что сообщение синхронизируется до конца после того, как все его жизненный цикл может закончиться, он может быть переработан. Однако, как описано ранее, простая многосекретная система синхронного обмена сообщениями не будет сохранена в состоянии синхронизации Synchronization на стороне сервера всех, полагаясь на их собственную инициативу. Таким образом, сервер не знает, когда сообщение может быть восстановлено, обычная практика - установить фиксированный жизненный цикл для этой библиотеки новостей, таких как неделя или месяц, конец жизни может быть устранена.
репозиторий сообщений: Хранилище сообщений используется для хранения временных шкал всех бесед, и каждая временная шкала содержит все сообщения в беседе. Эта библиотека в основном используется для извлечения всех исторических сообщений сеанса во время роуминга сообщений, а также для синхронизации сообщений в режиме распространения чтения.
Библиотека синхронизации сообщений и библиотека хранения сообщений имеют разные требования к базе данных, о том, как выбрать базу данных, будет рассказано ниже.
Выбор базы данных
Две основные библиотеки системы сообщений — это библиотека синхронизации сообщений и библиотека хранения сообщений.Эти две библиотеки предъявляют разные требования к базе данных:
Подводя итог, требования к базе данных следующие:
1. Структура таблицы может соответствовать функциональным требованиям модели временной шкалы: она не требует реляционной модели, может реализовывать модель очереди и может поддерживать генерацию самоувеличивающегося SeqId.
2. Он может поддерживать высокую одновременную запись и чтение диапазона со шкалой 100 000 TPS.
3. Возможность сохранять массивные данные, сотни терабайт.
4. Возможность определить жизненный цикл данных.
Alibaba Cloud Table Store (TableStore) — это распределенная база данных NoSQL, основанная на механизме хранения LSM.Он поддерживает миллионы одновременных операций чтения и записи с высокой скоростью TPS, хранение данных на уровне PB, а данные поддерживают TTL, что вполне соответствует вышеуказанным требованиям и поддерживает автоинкрементные столбцы.Физическая модель временной шкалы может быть идеально спроектирована и реализована.
Реализация архитектуры
В этой главе будет использоваться очень упрощенный код, чтобы показать, как реализовать модель временной шкалы на основе TableStore, а также хранить и отправлять сообщения на основе модели временной шкалы.
Основной целью кода, приведенного в этой статье, является демонстрация того, как добиться оптимизированной временной шкалы самых основных функций. Вскоре мы запустим полную библиотеку Timeline, которая будет основана на Timeline для хранилища сообщений, и разработка кода станет очень простой.
Все образцы кода основаны на следующих версиях SDK:
дизайн структуры таблицы
Выше приведен пример кода для создания таблицы временной шкалы Всего необходимо создать две таблицы, одна таблица — это библиотека синхронизации сообщений с именем «PushTable», а другая — хранилище сообщений с именем «StoreTable».
Нажмите и сохраните реализацию
Выше приведен пример кода, который имитирует синхронизацию и хранение сообщений в группе. Имя группы — «TableStore (номер DingTalk: 11789671)», а члены группы — «A, B, C, D, E». Новые сообщения в группе должны храниться на временной шкале хранения группы (идентификатор временной шкалы — это имя группы), а затем помещаться в синхронную временную шкалу каждого члена группы в режиме распространения записи (идентификатор временной шкалы сообщения). член группы используется в качестве идентификатора временной шкалы).
Выше приведен пример кода для получения истории сообщений в группе и синхронизации сообщений членом группы.Основная логика находится в функции syncMessages. В примере кода извлечение сообщений начинается с seq_id, равного 0, что является минимальным значением в автоматически увеличивающемся столбце TableStore, поэтому это означает, что сообщения извлекаются с наименьшей позиции, то есть извлекаются полные сообщения.
постскриптум
В этой статье в основном представлена реализация архитектуры отправки и хранения сообщений в современных системах обмена мгновенными сообщениями.Основываясь на логической модели временной шкалы, мы можем четко понять всю архитектуру доставки и хранения сообщений. На основе TableStore модель временной шкалы может быть реализована очень просто.Функция автоинкремента столбца идеально соответствует наиболее важному автоинкременту SeqId, необходимому в модели временной шкалы.
TableStore (Table Store) — это распределенная база данных NoSQL профессионального уровня, независимо разработанная Alibaba Cloud.Это высокопроизводительная, недорогая, легко расширяемая, полностью управляемая полуструктурированная платформа хранения данных на основе общего хранилища, поддерживающая эффективное хранение данных Интернета и Интернета вещей, расчет и анализ. Сценарий отправки и хранения сообщений в системе обмена мгновенными сообщениями является одним из важных приложений TableStore в социальной сфере.
Хранение сообщений на основе временной шкалы и модель push-уведомлений будут использоваться не только в системе обмена мгновенными сообщениями, но и в таких сценариях, как потоковая передача каналов, синхронизация сообщений в реальном времени и живое заграждение. В сценарии потоковой передачи каналов у нас также есть более глубокое исследование, вы можете обратиться к "Как построить систему потоковой передачи каналов из 10 миллионов уровней"Эта статья. В других сценариях у нас будет более глубокое исследование.
В ответ на требования высокой надежности данных и высокой доступности услуг в социальных сценариях мы также разрабатываем:
1."Как табличное хранилище обеспечивает высокую надежность и высокую доступность》
2."Как Table Store реализует аварийное восстановление между регионами》
В то же время в новой бессерверной архитектуре мы пытаемся:
В дополнение к социальной сфере, в области Интернета вещей и Интернета транспортных средств Table Store также использует свои мощные возможности распределенной базы данных:
1."Как эффективно хранить массивные данные GPS》
2."Super Express - Как использовать систему, чтобы обеспечить своевременную экспресс-доставку》