В сфере Интернета, особенно в нынешнюю эпоху мобильного Интернета, очень распространены продукты для потоковой передачи, такие как Moments, Weibo, который мы используем каждый день, является очень типичным продуктом для потоковой передачи, а также сайты для обмена изображениями Pinterest, Petal Net. и т. д. - это еще одна форма продукта потоковой подачи. Кроме того, многие приложения будут иметь модуль, называемый либо динамическим, либо квадратом сообщений.Это также продукты потоковой передачи каналов.Можно сказать, что продукты потоковой передачи каналов можно найти во всех приложениях в мире.

концепция

Прежде чем мы поговорим о том, как спроектировать систему потока корма, давайте рассмотрим некоторые концепции потока корма:

Лента: каждый статус или сообщение в ленте — это лента, например, статус в кругу друзей — это лента, а Weibo в Weibo — это лента.
Feed Stream: поток информации, который постоянно обновляется и предоставляется пользователю. Круг друзей каждого, страницы подписчиков Weibo и т. д. — все это поток новостей.
Временная шкала: временная шкала на самом деле является типом ленты новостей. Weibo и Moments — это потоки ленты типа временной шкалы. для представления потока подачи.
Временная шкала страницы следования: страница, на которой отображаются сообщения ленты других людей, такие как Моменты, домашняя страница Weibo и т. д.
Хронология личной страницы: страница, на которой отображаются отправленные вами сообщения ленты, такие как фотоальбом в WeChat, личная страница Weibo и т. д.

особенность

Системы потокового вещания имеют некоторые очень типичные особенности, такие как:

Потоковая передача контента с несколькими учетными записями: в системе потоковой передачи каналов определенно будут тысячи учетных записей, и между учетными записями могут выполняться такие операции, как подписка, разблокировка, добавление друзей и блокировка. Пока это удовлетворяется, его можно спроектировать как систему подачи потока.
Нестабильные отношения учетной записи: из-за таких операций, как подписка, снятие и т. д., отношения между пользователями в системе всегда будут меняться, что является нестабильным состоянием.
Соотношение чтения-записи 100:1: Соотношение чтения-записи сильно несбалансировано, с большим количеством чтения и меньшим количеством записи.Как правило, соотношение чтения-записи составляет 10:1 или даже более 100:1.
К сообщению должны предъявляться высокие требования: Например, после отправки кругу друзей, некоторые друзья его видят, а некоторые нет.Если не видит подруга, то могут быть серьезные эмоциональные конфликты, а последствия очень серьезный.

Выше приведены некоторые особенности продуктов Feed Streaming. Давайте взглянем на классификацию систем Feed Streaming.

Классификация

Существует много категорий потоков подачи, но две наиболее распространенные категории:

Временная шкала: сортировка в хронологическом порядке выпуска: те, которые были выпущены первыми, отображаются первыми, а те, которые были выпущены позже, располагаются вверху, как в WeChat Moments, Weibo и т. д. Это также самая распространенная форма. Если продукт выбирает тип Timeline, то считается, чтоFeed流中的Feed不多，但是每个Feed都很重要，都需要用户看到.
Ранг: Сортировка по фактору, не связанному со временем, как правило, в соответствии с предпочтениями пользователя, фаворит пользователя занимает первое место, а второе фаворитное место занимает последнее место. Такого рода общее предположение состоит в том, что пользователь может видеть много каналов, и время, которое пользователь проводит здесь, ограничено, затем выберите первые N результатов, которые пользователь больше всего хочет видеть для пользователя, рекомендовать и т. д.

Вышеуказанные два являются наиболее типичными и распространенными методами классификации.Кроме того, существуют и другие стандарты классификации.В других стандартах классификации будет еще два типа:

Агрегировать: Тип агрегирования. Например, несколько друзей смотрели один и тот же фильм. Это можно агрегировать в ленту: A, B, C смотрели фильм «Твое имя». Эта функция агрегирования больше подходит для реализации на стороне клиента. Общий тип агрегации — тип временной шкалы + агрегация на стороне клиента.
Примечание: Тип уведомления, на самом деле это функциональный тип.Тип уведомления обычно используется для различных уведомлений в приложении, и личные сообщения являются общими. Это также тип временной шкалы или агрегатный тип.

выполнить

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

Если вы хотите спроектировать систему потоковой передачи, двумя наиболее важными ядрами являются хранение и отправка.

место хранения

Давайте сначала посмотрим на хранилище.Контент, который необходимо хранить в системе потоковой передачи, разделен на две части: одна — это отношения с учетной записью (например, список наблюдения), а другая — содержимое сообщения в ленте. Независимо от типа хранилища, необходимо учитывать несколько вопросов:

Как он может поддерживать объем данных 100 ТБ или даже петабайт?
Когда объем данных велик, стоимость очень важна. Как стоимость может быть дешевле?
Как гарантировать, что отношения аккаунта и фиды не будут потеряны?

Мы ответим на эти три вопроса позже, давайте продолжим видеть толчок

толкать

Системе push нужны две функции: одна — публиковать фид, а другая — читать поток фида. Для систем доставки все еще есть некоторые вопросы, которые необходимо рассмотреть перед выбором:

Как мы можем обеспечить десятки миллионов TPS и QPS?
Как сделать так, чтобы задержка чтения и записи была 10 мс или даже меньше 2 мс?
Как обеспечить доступность фида?

Прежде чем ответить на эти вопросы, давайте кратко рассмотрим TableStore от Alibaba Cloud.

TableStore

TableStore — это распределенная база данных NoSQL профессионального уровня, разработанная независимо Alibaba Cloud.Это высокопроизводительная, недорогая, легко масштабируемая, полностью управляемая полуструктурированная платформа хранения данных на основе общего хранилища.
Поддержка эффективных вычислений и анализа данных Интернета и IoT.

В настоящее время тысячи систем используются как внутри Alibaba Group, так и внешними пользователями публичного облака. Он охватывает автономные приложения с высокой пропускной способностью, а также онлайн-приложения с высокой стабильностью и чувствительностью к производительности. Из систем, используемых сегодня, некоторые системы записывают более3500万行,每秒流量超过5GB,单表总行数超过10万亿行,单表数据量超过10PB.

Конкретные характеристики табличного хранилища можно увидеть на следующем рисунке.

Я не буду здесь подробно описывать функции и возможности TableStore.Если вам интересно, вы можете перейти на страницу официального сайта и в блог Yunqi, чтобы узнать о нем.Адреса следующие:

Официальный адрес сайта Table Store:Aliyun.com/product/O Жалоба…
Блог магазина столов Yunqi:Особенно aliyun.com/teams/4/бутылка с маслом для буксировки…
Хранение таблиц Группа связи Dingding: 11789671

выбор системы хранения

Далее мы рассмотрим вопросы, поднятые ранее.
Существует два типа систем, которые должны храниться в системе потоковой передачи: одна — это связь с учетной записью (например, список наблюдения), а другая — сообщения в ленте.

Отношения с учетной записью магазина

Давайте сначала рассмотрим хранение отношений учетных записей (таких как списки наблюдения).Для отношений учетных записей оно имеет некоторые характеристики:

это серия变长链表,长度可达亿级别.
Это приведет к数据量比较大,но关系极其简单.
Еще один момент заключается в том, что производительность чувствительна, что напрямую влияет на скорость реакции внимания и выключения.

Наиболее подходящей системой для хранения отношений учетных записей (списков наблюдения) должна быть распределенная база данных NoSQL, поскольку объем данных огромен, отношения просты и не требуют сложных объединений, а требования к производительности высоки.
Внутренний дизайн прост в реализации, а внешний пользовательский интерфейс хорош.

Помимо вышеперечисленных особенностей, есть еще одна особенность:

Упорядочивание: Упорядочивание не требует функции сортировки. Его нужно сортировать только в соответствии с первичным ключом. Пока он может быть отсортирован в соответствии с первичным ключом, порядок списка наблюдения и списка поклонников является фиксированным и предсказуемым.

Используйте HBase с открытым исходным кодом для хранения отношений учетных записей

HBase с открытым исходным кодом — это одна из распределенных баз данных NoSQL, которая может обеспечить упорядоченность, поэтому многие компании выбирают HBase с открытым исходным кодом для хранения отношений учетных записей или списков наблюдения.

Таким образом, несмотря на то, что вышеуказанные четыре характеристики удовлетворены, система может быть построена, но возникнут некоторые неприятные проблемы:

Вам нужно управлять и поддерживать его самостоятельно, исследовать проблемы и исправлять ошибки, что приведет к большей сложности и затратам.
GC вызовет относительно большие сбои и повлияет на работу пользователей.

Используйте TableStore для хранения взаимосвязей учетных записей

Кроме того, хранилище таблиц Alibaba Cloud также представляет собой упорядоченную распределенную базу данных NoSQL. Раньше многие известные системы предпочитали использовать хранилище таблиц, что приносило системе преимущества в следующих областях:

Поддержка одного стола10万亿行+，10PB+Объем данных, независимо от того, насколько быстро они растут, не беспокойтесь.
пресс данных主键列排序, чтобы обеспечить упорядоченность и предсказуемость.
Задержка чтения и записи одной клавиши составляет毫秒уровень, гарантировать внимание и сократить время отклика.
да全托管служба распределенной базы данных NoSQL,无需任何运维.
все采用C++осознать, полностью无GC问题, это не вызовет больших сбоев из-за GC.

Использование TableStore для хранения взаимосвязей учетных записей было бы лучшим выбором.

Далее обратите внимание на хранилище сообщений ленты.

Хранить сообщения ленты

Сообщения в ленте имеют одну из самых больших функций:

Объем данных велик, и в системе потоковой передачи часто выбирается режим диффузии записи (режим push).В это время объем данных будет увеличиваться на несколько порядков, поэтому объем данных здесь может легко достигать 100 ТБ или даже уровень ПБ.

Кроме того, есть еще некоторые особенности:

Простой формат данных
Данные не могут быть потеряны, и требуется высокая надежность
Функция самоинкрементного первичного ключа гарантирует, что идентификатор сообщения фида, отправленного отдельным пользователем, строго увеличивается в отдельном исходящем ящике, так что для чтения требуется только один диапазон. Поскольку параллелизм фидов, публикуемых отдельными лицами, очень низок, временные метки также могут удовлетворить базовые потребности.Однако, когда очереди прикладного уровня заблокированы, увеличивается сетевая задержка или откат времени, временные метки не могут гарантировать строгие приращения. Здесь лучше иметь функцию автоинкремента.
Чем ниже стоимость, тем лучше

потенциальная система хранения

Исходя из этих характеристик, оптимальная система должна быть具有主键自增功能的分布式NoSQL数据库, но не в системе с открытым исходным кодом, поэтому есть два часто используемых метода:

Реляционная база данных + подбаза данных и подтаблица
Реляционная база данных + распределенная база данных NoSQL: реляционная база данных обеспечивает функцию автоматического увеличения первичного ключа.

Используйте реляционную базу данных для хранения сообщений канала

В настоящее время многие пользователи в отрасли выбрали реляционные базы данных + подбазы данных и подтаблицы, включая некоторые очень известные потоковые продукты.Хотя эта архитектура может работать, есть некоторые проблемы.

Подтаблица подбиблиотеки приносит运维复杂性.
Подбаза данных и подтаблица приносят логический уровень и уровень данных极大耦合性.
Реляционные базы данных, такие как база данных MySQL с открытым исходным кодом, имеют низкую производительность автоматического увеличения первичного ключа. Независимо от того, используете ли вы MyISAM или механизм InnoDB, чтобы обеспечить строгое увеличение самоувеличивающегося идентификатора, необходимо использовать блокировку таблицы.Эта степень детализации очень велика, что серьезно ограничивает параллелизм и влияет на производительность.
Некоторые пользователи считают, что надежность реляционных баз данных выше, но надежность реляционных баз данных обычно не превышает 6 9. Эта надежность полностью отличается от надежности распределенных баз данных и на 4-5 уровней ниже.

Используйте TableStore для хранения взаимосвязей учетных записей

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

Одна таблица может достигать 10 ПБ и 10 триллионов строк.
10个9的SLA保障Контент ленты не теряется.
Естественно распределенная база данных,无需分库分表
Два типа инстансов. В высокопроизводительных инстансах используются только твердотельные накопители, что обеспечивает превосходную производительность чтения и записи. Экземпляры гибридного хранилища используют носители SSD+SATA, что обеспечивает чрезвычайно низкую стоимость хранения.
Функция автоинкремента первичного ключа имеет превосходную производительность.Все другие системы должны быть заблокированы при выполнении функции автоинкремента.Тем не менее, функция автоинкремента первичного ключа хранилища таблиц вообще не требует блокировок при записи столбца автоинкремента строк, а также не требует блокировок таблиц и блокировок строк.

Из вышесказанного, если вы используете TableStore, он больше подходит с точки зрения функциональности, производительности, масштабируемости и стоимости.

Ознакомившись с выбором системы push, давайте посмотрим на выбор схемы push.

толчок план

Давайте сначала рассмотрим самые большие функции системы Feed Streaming, упомянутой ранее:

Чтение и письмо сильно дисбалансированы, больше чтения и меньше письма Обычно соотношение чтения и письма выше 10:1 или даже 100:1.

В дополнение к этому есть еще один аспект, на который будет влиять пуш-схема:

Публикация, задержка при обновлении фида в основном вызвана推送方案Решено, что любую другую операцию можно только оптимизировать, а качество изменить нельзя.

Сравнение режима push и pull

В проталкивающей схеме есть две схемы, а именно:

Схема вытягивания: также известная как读扩散.
План Push: также стать写扩散.

Для схем pull и push они полностью противоположны по многим параметрам.Прежде чем рассматривать сравнение, следует подчеркнуть один момент:

Для пользователей продуктов потоковой передачи новостей чувствительность к задержке при обновлении потока ленты (чтение) намного выше, чем при публикации (записи).

Режим вытягивания (читай диффузия)	Push-режим (распространение записи)
выпуск	Хронология личной страницы (исходящие)
читать	Профиль Хронология всех подписчиков
максимальная стоимость сети	Когда пользователь обновляет
усиление чтения и записи	Увеличенное чтение: отношение чтения-записи до 10 000:1
персонализировать	не поддерживается
таргетированная реклама	не поддерживается

Побочный эффект режима push

Из приведенного выше сравнения очевидно, что режим проталкивания намного лучше, чем режим протягивания, но он также имеет побочный эффект:

Данные будут сильно завышены.

Для устранения этого недостатка можно рассмотреть два аспекта:

Текущая цена хранилища очень низкая. Возьмем, к примеру, табличное хранилище. В экземпляре емкости хранится 10 ТБ данных. В настоящее время (октябрь 2017 г.) годовая стоимость составляет 16 000 юаней, и в будущем цена будет зависеть от аппаратной технологии. , оптимизация производительности программного обеспечения и т. д. продолжают снижаться. Кроме того, чем больше объем данных, тем дешевле цена.
Если вы хотите сэкономить немного денег, вы можете продолжить оптимизацию:
- Режим pull используется для больших V, а режим push используется обычными пользователями У этого режима есть недостаток, который будет проанализирован позже.
- Используйте push-режим для активных поклонников и pull-режим для неактивных поклонников (этот метод может лучше избежать влияния большого трафика на платформу).

Применимая сцена

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

Режим вытягивания:
- Первые версии многих продуктов для потоковой передачи будут использовать эту схему, но вскоре от нее откажутся.
- Кроме того, режим извлечения + расчет графика будет другим миром, но на этот раз основное внимание уделяется расчету графика.
Нажимной режим:
- Наиболее часто используемый и эффективный режим в системе Feed Streaming;
- Количество пользовательских отношений относительно однородно или имеет верхний предел, например круг друзей;
- Категория частичной рекомендации, один и тот же канал имеет разные значения для разных пользователей и должен рассчитывать баллы для разных пользователей, таких как pinterest.
Двухтактная комбинация
- Большинство пользователей имеют сотни отношений с учетными записями, но у некоторых пользователей их более 10 миллионов, например, у Weibo.

Схема пуш понятна выше, а дальше рассмотрим выбор системы пуш

толкающая система

Если вы реализуете заказ на десять продуктов потока подачи, то нажмите систему, необходимо иметь некоторые функции:

С возможностью десятков миллионов TPS/QPS.
Ссылки для чтения и записи чувствительны к задержке, а чтение и запись будут напрямую влиять на публикацию пользователей и задержку обновления потока канала, особенно чрезвычайно чувствительную задержку обновления.
Сообщения в ленте должны предъявлять высокие требования.
Функция автоинкремента первичного ключа по-прежнему гарантирует, что идентификатор канала в почтовом ящике пользователя строго увеличивается, гарантируя, что последние непрочитанные сообщения могут быть прочитаны с помощью сканирования (самый большой идентификатор прочитан последним ---> MAX).
Лучше всего хранить все каналы на временной шкале для пользователя.

Исходя из приведенных выше характеристик, требуемая система push предпочтительно должна быть системой NoSQL с отличной производительностью и надежной функцией автоинкремента.Поэтому, если в отрасли выбирается система с открытым исходным кодом, в качестве системы хранения будет выбрана реляционная база данных. , выберите Redis с открытым исходным кодом, который может покрыть вышеупомянутые функции и обеспечить нормальную работу системы потоковой передачи, но также принесет некоторые другие проблемы:

Для систем с чистой памятью цена памяти чрезвычайно высока, а общая стоимость относительно высока.
Он относится к автономной системе.Для поддержки десятков миллионов TPS и обеспечения доступности сообщений необходимо использовать режимы кластера и реплики.Результатом является не только сложность эксплуатации и обслуживания, но и увеличение стоимости машин, и стоимость снова возрастает.
После того, как стоимость возросла, некоторые архитекторы начали задумываться над тем, могут ли они сократить расходы. Единственный способ сэкономить — уменьшить объем данных, хранящихся в Redis с открытым исходным кодом. Как правило, существует два метода, каждый из которых может снизить объем данных, хранящихся в Redis.Количество данных:
- Сохраняйте в Redis с открытым исходным кодом только идентификатор канала, а не его содержимое. Общий объем данных сильно уменьшится, но при чтении нужно сначала прочитать идентификатор фида, а потом прочитать содержимое фида в системе хранения.Сетевые накладные расходы удваиваются, и он последовательный, и задержка обновления для пользователей ограничено большее влияние.
- Используйте режим push только для обычных пользователей или активных пользователей и напрямую используйте режим pull для больших V и неактивных пользователей.

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

Использование TableStore в качестве push-системы

В дополнение к использованию систем с открытым исходным кодом вы также можете использовать TahleStore от Alibaba Cloud.Многие пользователи выбирают TableStore в качестве системы push-уведомлений по следующим причинам:

Естественно распределенная, одна таблица может поддерживать десятки миллионов TPS/QPS.
Механизм хранения LSM огромен优化写, высокопроизводительные экземпляры чрезвычайно велики优化读.
Успешность записи означает, что диск успешно размещен, а достоверность данных обеспечивает 10 9 SLA-гарантий.
Дисковые базы данных на несколько порядков меньше, чем базы данных в оперативной памяти.
В одной таблице может храниться более десяти триллионов строк данных, а цена низкая, и можно легко сохранить все данные канала в потоке канала пользователя.

Выше упоминались сходства и различия между использованием Redis с открытым исходным кодом и Alibaba Cloud TableStore.Если вы используете открытый исходный код, вы можете использовать Redis.Если вы выбираете базу данных NoSQL собственной разработки Alibaba Cloud, вы можете использовать TableStore.

Диаграмма архитектуры

Давайте взглянем на архитектурную схему использования TableStore.Для универсальности принята комбинация push-pull, а push-режим проще.

место хранения

Давайте сначала посмотрим на часть в черном ящике посередине.Эта часть представляет собой данные, использующие TableStore, слева направо:

Личная страница Хронология: Это исходящая каждого пользователя, то есть его личная страница.
Временная шкала страницы подписки: это почтовый ящик каждого пользователя, то есть его собственная страница подписки, а контент — это сообщения, публикуемые людьми, на которых они подписаны.
Список наблюдения: сохранить отношения учетной записи, например, отношения друзей в Моментах; список наблюдения в Weibo и т. д.
Виртуальный список наблюдения: в основном используется для персонализации и рекламы.

Процесс публикации фида

Когда вы публикуете сообщение канала, процесс выглядит следующим образом:
1. Сообщения ленты сначала поступают в службу очереди.
2. Сначала прочитайте свой список поклонников из списка наблюдения и решите, являетесь ли вы большим V.
3. Напишите собственное сообщение в ленте новостей на временной шкале (исходящие) вашей личной страницы. Если это большая буква V, процесс записи на этом заканчивается.
4. Если вы обычный пользователь, вам также необходимо написать свое сообщение в ленте своим поклонникам.Если у вас 100 поклонников, вам нужно написать 100 пользователям, включая содержимое ленты и идентификатор ленты.
5. Шаги 3 и 4 можно объединить вместе, используя интерфейс BatchWriteRow для одновременной записи нескольких строк данных в TableStore.
6. На этом процесс публикации фида завершен.

Чтение потока потока данных

При обновлении собственного потока каналов процесс выглядит следующим образом:
1. Сначала прочтите список больших V, которым вы следуете
2. Чтобы прочитать папку "Входящие", вам нужен только GetRange для чтения диапазона. Начальная позиция диапазона – это идентификатор последнего канала, прочитанного в последний раз, а конечная позиция может быть текущим временем или MAX. Рекомендуется МАКСИМАЛЬНОЕ значение. Поскольку ранее использовалась функция автоинкремента первичного ключа, ее можно прочитать здесь с помощью GetRange.
3. Если есть большие V, на которые вы подписаны, еще раз одновременно прочитайте исходящие сообщения каждого большого V. Если вы подписаны на 10 больших V, то потребуется 10 посещений.
4. Результаты шагов 2 и 3 объединяются, сортируются по времени и возвращаются пользователю.

На этом процесс считывания фид-потока методом двухтактного комбинирования завершен.

Упрощенный push-режим

Если вы просто используете push-режим, это будет проще:

Опубликовать ленту:
1. Нет необходимости различать, является ли это большой буквой V или нет, процесс для всех пользователей одинаков и состоит из трех шагов.
Читать ленту новостей:
1. Нет необходимости в первом шаге или третьем шаге, требуется только второй шаг, уменьшающий предыдущие 2 + N (N — количество рассматриваемых больших V) служебных данных сети до 1 служебной нагрузки сети. Задержка чтения значительно снижена.

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

Персонализация и таргетированная реклама — две очень важные потребности продукта. Персонализация может хорошо служить пользователям, повышать конкурентоспособность продукта и прилипчивость пользователей, а таргетированная реклама может увеличить каналы получения прибыли для продуктов, а также может избежать отвращения пользователей.Так как же реализовать эти два метода? Реализация этих двух функций в потоке Feeds аналогична, для иллюстрации возьмем таргетированную рекламу:
1. Классифицировать пользователей с помощью анализа пользовательских характеристик.Например, одна из них — категория первокурсников: первокурсники, только что поступившие в колледж в этом году. (Анализ конкретных пользовательских функций может опираться на TableStore + MaxCompute, которые здесь не обсуждаются).
2. Создайте рекламный аккаунт: Newborn Advertising
3. Пусть эти пользователи с новыми характеристиками виртуально следят за новым рекламным аккаунтом. Пользователи не видят этот слой внимания.
4. С июля можно отправлять рекламу через новый рекламный аккаунт.
5. В конечном итоге у каждого пользователя может быть несколько характеристик, поэтому можно виртуально следить за несколькими рекламными аккаунтами.

Вышеописанное является относительно простой реализацией таргетированной рекламы, и другие способы повторяться не будут.

доход

Выше мы подробно описали архитектуру использования TableStore в качестве системы хранения и push-уведомлений, а дальше посмотрим, что нам может дать новая архитектура.

Используется только одна система, а архитектура и реализация просты. Отсутствие необходимости в доступе к нескольким системам, архитектуре, разработке, тестированию, эксплуатации и обслуживанию может сэкономить много времени рабочей силы.
Функция автоинкремента первичного ключа TableStore имеет отличную производительность. Из-за различных архитектур не требуются блокировки не только таблиц, но и строк, поэтому производительность намного выше, чем у реляционных баз данных.
Все каналы могут быть сохранены. Во-первых, система может поддерживать хранение всех каналов, а во-вторых, низкая цена и возможность хранения.
Нет необходимости хранить идентификаторы фидов и контент отдельно. Цена дешевая, и нет необходимости хранить ID и контент отдельно.
Полностью управляемый сервис, никаких операций по эксплуатации и техническому обслуживанию, а также отсутствие необходимости в подбазе данных и подтаблице.
Тип диска (SSD, Hybrid) база данных, низкая стоимость.
Надежность 10 9, данные более надежны и с меньшей вероятностью будут потеряны.
Порог сегментации больших V и обычных пользователей выше, количество раз чтения больших V меньше, а общая задержка ниже.

недостаток дизайна

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

Big V отправляет сообщения в ленте.
Большой V, используй режим вытягивания.
Активные поклонники большого V (группа пользователей A) начинают читать новую ленту большого V через режим извлечения (шаг 3 читайте на диаграмме архитектуры, для краткости читайте 3).
Контент ленты слишком актуален и быстро распространяется.
Поклонники большого V (группа пользователей B), которые не вошли в систему, начинают входить в продукт. После входа в систему они автоматически обновятся и прочитают содержимое канала большого V, снова прочитав 3 шага.
Нефанаты (группа пользователей C) переходят на хронологию личной страницы большого V, чтобы посмотреть, и им снова нужно прочитать личную хронологию большого V и прочитать 3.

В результате обычный нормальный трафик только用户群A, теперь результат用户群A + 用户群B+ 用户群C, трафик увеличился в несколько раз, а то и в десятки раз, в результате чего служебный модуль пути чтения 3 попадает на сервер, занятый или ресурсы машины переполняются, в результате чего путь чтения 3 чтения большого V не может вернуться запрос, если пользователь в фиде продукта Все обращают внимание на большой V, поэтому в основном все пользователи застрянут на пути чтения 3 чтения большого V, и тогда они не смогут обновить.

Поэтому при проектировании здесь нужно ориентироваться на следующие два момента:

Недоступность одного модуля не должна блокировать весь путь потока потока чтения ключа.Если большой V не может быть прочитан, но обычный пользователь может вернуться, после восстановления сервиса содержимое большого V может быть дополнено.
Когда модуль не может выдержать такой большой объем трафика, модуль не должен быть полностью неработоспособным, а должен продолжать обеспечивать максимальную пропускную способность обслуживания и отбрасывать излишки.

Так как его оптимизировать?

Не используйте метод оптимизации больших V/обычных пользователей, а используйте метод оптимизации активных пользователей/неактивных пользователей. Таким образом, пользовательская группа А и часть пользовательской группы В могут быть распределены по другим, более рассредоточенным путям. Более того, даже если путь чтения 3 недоступен, это все равно не влияет на активных пользователей.
Полное использование push-режима может полностью решить эту проблему, но это увеличит емкость хранилища и увеличит общее время отправки большого V Weibo.Это может занять несколько минут от первого подписчика до последнего подписчика (один 100 миллионов поклонников, 1 миллион строк в секунду, 100 секунд) и резервирование ресурсов для максимального параллелизма.Если вы используете Table Store, так как это облачная служба, вам не нужно рассматривать вопрос о резервировании максимального количества ресурсов.

упражняться

Далее реализуем функцию квадрата сообщений. Многие приложения имеют функцию динамического квадрата или квадрата сообщения.Как правило, в квадрате сообщения есть две вкладки, один - подписчик, а другой - квадрат. Здесь мы фокусируемся на подписчике.

Функции, которые необходимо реализовать, следующие:

Пользователи могут подписываться друг на друга
Пользователи могут публиковать новые сообщения
Пользователи могут просматривать список сообщений, опубликованных ими самими.
Пользователи могут просматривать сообщения от людей, на которых они подписаны

Возьмите предыдущий сценарий:

Используйте TableStore в качестве системы хранения и отправки
Используя метод отображения временной шкалы, я надеюсь, что пользователи смогут внимательно читать каждую ленту.
Принять push-режим

Роль

Далее давайте рассмотрим роли и возможности, которые требуются для каждой роли:

отправитель
- Статус отправки: add_activity()
получатель
- Следовать: следить()
- Чтение потока ленты: get_activity()

Сообщения в ленте должны включать как минимум следующее:

Информация:
- отправитель: актер
- Тип: глагол, например изображение, видео, текст
- Текстовый текст: сообщение

Диаграмма архитектуры

Публиковать новые новости
- Интерфейс: add_activity()
- выполнить:
  - Интерфейс get_range вызывает список подписчиков и возвращает список подписчиков.
  - Интерфейс batch_write_row записывает содержимое ленты и идентификатор в таблицу личных страниц (исходящие) и таблицу фолловеров (входящие) всех поклонников в пакетах. Если сумма слишком велика, ее можно записать несколько раз. Или вызовите асинхронный интерфейс batch_write_row.В настоящее время C++ SDK и JAVA SDK предоставляют асинхронные интерфейсы.
обрати внимание на
- Интерфейс: следовать()
- выполнить:
  - Интерфейс put_row может напрямую записывать строку данных (последователи, подписчики) в список наблюдения и список поклонников (последователи, подписчики).
Получать сообщения потоковой передачи
- Интерфейс: get_activity()
- выполнить:
  - Получить идентификатор последнего сообщения, прочитанного клиентом: last_id
  - Используйте интерфейс get_range для чтения последнего сообщения, начальная позиция — last_id, а конечная позиция — MAX.
  - Если вы хотите прочитать содержимое личной страницы, просто посетите таблицу личных страниц. Если вы хотите прочитать содержимое следующей страницы, просто посетите таблицу следующих страниц.

план

Выше показано, как использовать для этого Table Store API. Хотя при этом используется только несколько интерфейсов, изучение API и функций табличного хранилища все же занимает немного времени.

Для большей простоты использования мы предоставим полное решение для потока фидов, предоставив LIB, интерфейс напрямую похож на add_activity(), follow() и get_activity(), которые будут проще и быстрее в использовании.

расширять

Описанные выше типы потоков фидов относятся к типу временной шкалы, но есть еще один тип потока фидов, более распространенный, то есть рекомендации новостей и тип ранжирования, обычно используемый веб-сайтами для обмена изображениями.
Давайте рассмотрим области, в которых хорош ранговый тип:

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

Давайте сначала посмотрим на архитектурную диаграмму:

Этот метод Rank является относительно легким и подходит для двухтактных комбинированных сценариев.
Процесс написания в основном тот же
В процессе чтения весь контент канала будет прочитан первым. Это то же самое, что и временная шкала. Если он находится на временной шкале, он будет возвращен пользователю напрямую, но тип ранга должен быть отсортирован по определенному значению атрибута в модуль сортировки, а затем все результаты будут отсортированы. Сохраните его в кеше временной шкалы и верните N результатов с наивысшими оценками, а также верните результаты [N+1, 2N] при следующем чтении.

Посмотрим на другой:

Этот относительно тяжеловесный вариант подходит для чистого пуш-режима.
Процесс написания такой же, как и в Timeline.
У каждого пользователя есть два ящика:
- Одной из них является временная шкала страницы подписки, которая сохраняет исходное содержимое канала, и пользователи не могут напрямую просматривать этот почтовый ящик.
- Одним из них является временная шкала рейтинга, которая сохраняется как выбранный пользователем контент канала, и пользователь напрямую просматривает этот почтовый ящик.
После того, как процесс записи закончен, происходит еще один процесс обработки данных. Персонализированная система сортировки получает новое содержимое фида из исходного почтового ящика и вычисляет оценку в соответствии с характеристиками пользователя и фида.Каждый фид может иметь разные баллы на временной шкале разных пользователей.После завершения расчета Сортировка а затем напишите в хронологию окончательного ранга.
Таким образом можно действительно достичь «тысячи людей и тысячи лиц» для каждого пользователя.

Вышеупомянутые два метода являются относительно простыми и широко используемыми методами для достижения ранга.

Наконец

Исходя из приведенного выше контента, TableStore может поддерживать уровень 10 ПБ с точки зрения хранилища и может поддерживать десятки миллионов TPS/QPS в секунду с точки зрения push-уведомлений, что может иметь большое значение в системе потоковой передачи.

В настоящее время многие известные компании используют TableStore для создания собственных систем потоковой передачи, что в конечном итоге приносит много преимуществ системе, продуктам и компаниям.

Если вы заинтересованы в хранении таблиц или у вас есть вопросы, связанные с хранилищем таблиц, вы можете присоединиться:

表格存储公开交流群：钉钉群号码：11789671