Я использую notifications
стол и subnotifications
таблица, и я также использую очереди, поэтому он работает в фоновом режиме, когда пользователь что-то публикует. Когда у пользователя есть 10 подписчиков, и они создают сообщение, notifications
таблица получает одну запись, которая включает в себя данные публикации для уведомления, и subnotifications
таблица получает 10 записей (по одной субно-уведомления на каждого подписчика, каждая ссылается на идентификатор уведомления, поэтому нам не нужно повторять данные уведомления 10 раз, с read_at
узнать, читал ли он этот подписчик или нет).
Это быстро и прекрасно работает без каких-либо проблем. Однако при тестировании с 1 миллионом подписчиков требуется около ~ 6 часов Вставить субно-уведомления для одного поста! Это, конечно, неприемлемо, так как для вставки 1 миллиона вложенных уведомлений требуется слишком много времени, по одному на каждого подписчика. Представьте, что тот же пользователь постит 10 постов, это будет как ~ 60 часов вставки и 10 миллионов строк субнотификации.
Я просто хочу, чтобы подписчики знали, что есть новое сообщение, если они еще не читали его. Есть ли лучший, более эффективный способ масштабирования?
ОБНОВЛЕНИЕ: Застрял с текущим подходом, см. Ниже …
Если последователь $user
имеет 100 лидеров, которых они следуют (которые они следовали в разных created_at
временные метки, конечно, в таблице фолловеров), что будет правильным запросом о новых постах лидера со времени, когда фолловер следил за каждым лидером? Я застрял в created_at
с этим псевдокодом:
// Assume `leader_id` is a column in the notifications table
DB::table('notifications')
->whereIn('leader_id', $leaderIds)
->where(`created_at`, '>', $whatTimestampsGoHere)
->paginate(20);
Существует 100 различных временных меток, и я застрял на том, как решить эту проблему правильно и эффективно. Есть идеи?
Как указано в комментариях, вы можете уменьшить вставки, если вы вставляете только в дочернюю таблицу, т.е. subnotifications
когда пользователь читает его, а не создает его при создании уведомления, что позволяет избежать этой проблемы.
При попытке проверить, видел ли пользователь уведомление, просто проверьте, существуют ли они в subnotifications
для пользователя и уведомления.
Кроме того, как сказано, при извлечении уведомлений, чтобы показать пользователям извлекать их из notifications
но ограничить уведомления созданными уведомлениями после пользователь начал следить за тем, чтобы новые пользователи не были заполнены уведомлениями.
Других решений пока нет …