В последнее время внедряется модуль центра сообщений, аналогичный Weibo и Netease Cloud. Основная функция — объединение лайков, комментариев, @ и других сообщений в системе. Сегодня я поделюсь с вами нашими идеями дизайна и реализации.
Во-первых, сейчас мы находимся в архитектуре микросервисов. Поэтому дизайн центра сообщений в этой статье также основан на микросервисах, а центр сообщений и другие модули не зависят друг от друга.
Проанализировав требования, мы можем обнаружить, что роль центра сообщений выглядит следующим образом (в качестве примера возьмем подобное сообщение):
В соответствии с требованиями у нас есть следующие два решения для хранения.
Вариант первый:
Таблица сообщений: сообщение. Поля следующие: user_id [пользователь атрибуции сообщения], sender_id [пользователь, отправивший сообщение], src_type [источник контента, соответствующий сообщению], src_id [идентификатор сообщения], action [действие], content_json [контент], create_time [время создания сообщения]
Описание поля:
src_type и src_id в основном используются для идентификации источника сообщения и необходимы при щелчке для ввода сведений.
Поле действия в основном используется для хранения типа действия, которое используется для определения того, является ли сообщение лайком, комментарием или другими типами.
Поле content_json используется для хранения всего контента, необходимого для отображения сообщения, включая содержимое поста, изображение поста, автора поста и т. д.
Вариант 2:
Таблица сообщений: сообщение. Поля следующие:
user_id [пользователь атрибуции сообщения], sender_id [пользователь, отправивший сообщение], src_type [источник, соответствующий сообщению], src_id [идентификатор сообщения], action [действие], action_id [идентификатор действия], create_time [время создания сообщения]
Поле action_id в основном используется для поиска содержимого действия. Когда действием является лайк или комментарий, это поле сохранять не нужно. Когда действие является комментарием, значение можно получить из таблицы содержимого сообщения через это поле.
Таблица содержимого сообщения: message_content, поля следующие:
src_type [источник контента: посты, комментарии и т. д.], src_id [идентификатор контента], content [контент], status [статус контента]
Некоторые могут задаться вопросом, зачем нужна таблица message_content? На самом деле, мы упоминали в начале, что мы являемся микросервисной архитектурой. Центр сообщений и другие модули независимы друг от друга, поэтому центр сообщений не будет обращаться к каждому модулю для получения значений, и при этом он не должен обращаться к каждому модулю для получения значений, это относительно независимый модуль. Поэтому нам нужна библиотека контента для хранения контента в нашей системе. Причина, по которой поле content_json в схеме 1 должно хранить так много контента, та же.
Далее мы рассмотрим сравнение двух схем.
Вариант первый:
Преимущества: 1. Высокая масштабируемость, независимо от того, какое сообщение можно добавить в таблицу сообщений. 2. Низкая связанность с другими проектами. Недостатки: 1. Сложное действие обновления 2. Больше избыточных данных
Вариант 2: Преимущества: 1. Простое действие обновления. 2. Низкая связанность с другими проектами. Недостатки: 1. Низкая масштабируемость, есть требования к формату содержимого, хранящегося в таблице message_content.
Исходя из реальных потребностей бизнеса, рекомендуется использовать второй вариант. Потому что в реальных сценариях такие операции, как удаление публикации или удаление комментария, должны влиять на статус содержимого в сообщении. Вариант 2 имеет абсолютное преимущество в обновлении контента. Если вы используете вариант 1, обновление содержимого сообщения будет довольно головной болью.
Если у вас есть какие-либо вопросы или предложения получше, добро пожаловать на обсуждение~