Масштабні онлайн-додатки пройшли довгий шлях за останні два десятиліття. Ці інновації змінили наше уявлення про розробку програмного забезпечення. Facebook, Instagram і Twitter, наприклад, є масштабованими платформами.
Ці системи мають бути побудовані для керування величезними обсягами трафіку та даних, оскільки мільярди людей використовують їх одночасно по всьому світу. Це коли проектування системи входить в картинку.
Процес встановлення архітектури, інтерфейсів і даних для системи, яка відповідає певним критеріям, відомий як проектування системи. Завдяки згуртованим та ефективним системам дизайн системи задовольняє потреби вашого бізнесу чи організації.
Коли ваша компанія чи організація визначила свої критерії, ви можете почати включати їх у фізичний проект системи, який відповідає вимогам ваших споживачів.
Незалежно від того, чи ви виберете розробку на замовлення, комерційні рішення чи комбінацію обох, те, як ви розробляєте свою систему, визначатиме, як ви її будуєте.
Ми детально розглянемо системний дизайн хронології Twitter у цій публікації разом із підручником. Давайте розпочнемо.
Крок 1: окресліть сценарій використання та обмеження
Використовуйте футляр
- Користувач завантажує твіт.
- Сервіс надсилає push-повідомлення та електронні листи підписникам твітів.
- Переглядається хронологія користувача (активність користувача)
- Користувач переглядає домашню хронологію (активність людей, за якими стежить користувач)
- Ключові слова шукає користувач.
- Послуга дійсно доступна.
Виходить за рамки
- Твіти надсилаються на Twitter Firehose та інші потоки за допомогою цієї служби.
- Сервіс видаляє твіти на основі налаштувань видимості користувача.
- Якщо користувач також не підписаний на особу, якій відповідають, приховайте відповідь.
- Зверніть увагу на опцію «приховати ретвіти».
- Аналітика
Обмеження та припущення
Державні припущення
- Рух розподілений нерівномірно.
- Надіслати твіт має бути просто.
- Якщо у вас немає мільйонів підписників, надсилання твіту всім вашим підписникам повинно бути швидким.
- Є 100 мільйонів активних користувачів.
- 15 мільярдів твітів щомісяця або 500 мільйонів твітів щодня
- Кожен твіт має в середньому 10 повідомлень.
- Щодня fanout доставляє 5 мільярдів твітів.
- Fanout доставляє 150 мільярдів твітів щомісяця.
- 250 мільярдів щомісячних запитів на читання
- 10 мільярдів пошукових запитів щомісяця
Timeline
- Часова шкала має бути легкою для навігації.
- Twitter – це більше читання, ніж писання.
- Оптимізуйте для швидкого читання твітів
- Споживання твітів займає багато часу.
Пошук
- Процес пошуку має бути швидким.
- Це трудомісткий пошук.
Розрахувати використання
Розмір кожного твіту:
- 8-байтовий ідентифікатор твіту
- 32 байти ідентифікатора користувача
- 140 байт тексту
- медіа – в середньому 10 КБ
- Разом: ~10 Кб
Щомісяця генерується 150 ТБ свіжого вмісту твітів.
- * 500 мільйонів твітів щодня * 30 днів на місяць * 10 Кб на твіт
- За три роки було 5.4 ПБ свіжого вмісту твітів.
Кожну секунду надходить 100,000 XNUMX запитів на читання.
- * (400 запитів на секунду / 1 мільярд запитів на місяць) 250 мільярдів запитів на читання щомісяця
Є 6,000 твітів кожну секунду.
- * (400 запитів на секунду / 1 мільярд запитів на місяць) 15 мільярдів твітів щомісяця
На fanout щосекунди надсилається 60 тисяч твітів.
- Fanout доставляє 150 мільярдів твітів щомісяця* (400 запитів на секунду / 1 мільярд запитів на місяць).
4,000 запитів на інформацію щосекунди
- * (400 запитів на секунду / 1 мільярд запитів на місяць) 10 мільярдів пошуків щомісяця
Деякі корисні перетворення
- Щомісяця проходить 2.5 мільйона секунд.
- 2.5 мільйона запитів на місяць зі швидкістю 1 запит в секунду
- 100 мільйонів запитів на місяць х 40 запитів на секунду
- 1 мільярд запитів на місяць = 400 запитів на секунду
Крок 2: діаграма високого рівня
Крок 3: Пояснення основних компонентів
Ми могли б зберегти власні твіти користувача, щоб заповнити часову шкалу користувача (діяльність користувача) у реляційній базі даних, якщо вони надсилають твіт. Важче доставляти твіти та розробляти домашню шкалу часу (діяльність осіб, за якими стежить користувач).
Типова реляційна база даних була б переповнена розсиланням твітів усім підписникам (60 тисяч твітів доставляються щосекунди). Ймовірно, ми захочемо скористатися сховищем даних із швидким записом, наприклад базою даних NoSQL або кеш-пам’яттю.
Послідовне читання 1 МБ з пам’яті займає приблизно 250 мікросекунд, але читання з SSD займає в 4 рази більше часу, а читання з диска займає у 80 разів більше часу.
Сховище об’єктів можна використовувати для зберігання таких даних, як зображення та відео.
- Веб-сервер, який діє як зворотний проксі-сервер, отримує твіт від клієнта.
- Веб-сервер надсилає запит на сервер Write API.
- Write API зберігає твіт у базі даних SQL на часовій шкалі користувача.
Служба Fan-Out зв’язується через Write API, і вона виконує наступні завдання.
- Знаходить підписників користувача в кеші пам’яті, надсилаючи запит до служби User Graph.
- У кеші пам’яті твіт зберігається на домашній шкалі підписників користувача.
- 1,000 підписників = 1,000 пошуків і вставок = O(n) операцій.
- Твіт зберігається в Search Index Service для швидкого пошуку.
- Object Store використовується для зберігання мультимедійних даних.
- Надсилає push-сповіщення підписникам через службу сповіщень.
- Щоб надсилати сповіщення асинхронно, він використовує чергу.
Ми можемо використовувати власний список Redis із такою структурою, якщо наш кеш пам’яті є Redis:
Домашня шкала часу користувача оновлюватиметься новим твітом, який зберігатиметься в кеші пам’яті. Ми будемо використовувати такий публічний REST API:
Часова шкала користувача переглядається користувачем.
- Веб-сервер отримує від клієнта запит користувача на часову шкалу.
- Веб-сервер надсилає запит на сервер Read API.
- Read API надсилає запит до бази даних SQL для часових рамок користувача.
REST API працюватиме так само, як і домашня хронологія, за винятком того, що всі твіти надходитимуть від користувача, а не від людей, за якими вони стежать.
Користувач здійснює пошук за ключовими словами:
- Веб-сервер отримує пошуковий запит від клієнта.
- Веб-сервер надсилає запит на сервер API пошуку.
Крок 4: Хронологія Twitter
Створення шкали часу – складне завдання. Потрібен сервер генерації шкали часу, який має посилання на веб-сервери або сервери додатків.
Кожного разу, коли користувач входить, служба часової шкали відстежує найновіші твіти від користувачів у таблиці підписників і оновлює або оновлює часову шкалу користувача.
Ми не впроваджуємо тут жодної системи рейтингу; замість цього ми припускаємо, що 5 найпопулярніших твітів від підписників користувача представлені на часовій шкалі в порядку часу створення. Ми можемо підтримувати обмеження для оновлення 50 твітів. Ми все ще припиняємо оновлення або створення шкали часу після досягнення цього порогу, доки користувач не оновить сторінку.
Великі затримки та занепокоєння щодо продуктивності виникнуть у зв’язку зі створенням живих каналів користувачів. Натомість створення офлайн-потоку, який можна миттєво представити, є найкращим способом покращити продуктивність. Запустіть виділені сервери шкали часу, які регулярно перевіряють сервер додатків, щоб оновити стрічку на основі часу її створення.
Алгоритм ранжирування має враховувати важливі сигнали та надавати вагу, щоб гарантувати, що на часовій шкалі користувача не домінує матеріал з одного або кількох облікових записів, за якими вони стежать.
Точніше, ми можемо вибирати функції, пов’язані з релевантністю будь-якого елемента стрічки, наприклад кількість лайків, коментарів, поширення та час оновлення. Кожен із цих критеріїв слід використовувати для оцінки твіту, а потім цей рейтинг слід використовувати для показу твітів на часовій шкалі.
Чи повинні ми постійно сповіщати користувачів, коли стає доступним новий вміст для їхньої стрічки новин? Користувачам може бути корисно отримувати сповіщення, коли стають доступними нові дані. Однак на мобільних пристроях, коли використання даних є досить дорогим, це може втрачати пропускну здатність.
У результаті ми можемо не надсилати дані на мобільні пристрої, а натомість дозволити користувачам «Потягнути, щоб оновити» для нових публікацій.
Крок 5: Дизайн масштабування
Потенційним вузьким місцем є служба Fanout. Користувачам Twitter з мільйонами підписників доведеться чекати кілька хвилин, поки їхні твіти опублікуються. Це може спричинити гонку з відповідями на твіт, чого ми могли б уникнути, змінивши порядок твітів під час обслуговування.
Ми також могли б запобігти поширенню твітів від людей із великою кількістю підписників. Натомість ми можемо здійснити пошук твітів від людей, які часто підписуються, інтегрувати результати пошуку з результатами домашньої хронології користувача, а потім змінити порядок твітів під час показу.
Додаткові покращення включають:
- Зберігайте лише кілька сотень твітів у кеші пам’яті для кожної домашньої шкали часу.
- У кеші пам’яті зберігається лише інформація про домашню часову шкалу активних користувачів.
- Ми можемо реконструювати хронологію з бази даних SQL, якщо користувач не був активним протягом попередніх 30 днів.
- Щоб дізнатися, хто є користувачем, скористайтеся службою User Graph Service.
- Додайте твіти до кешу пам’яті, отримавши їх із бази даних SQL.
- Служба інформації про твіти може зберегти твіти лише за місяць.
- У інформаційній службі користувача зберігаються лише активні користувачі.
- Щоб підтримувати низьку затримку, пошуковому кластеру, швидше за все, потрібно буде зберігати твіти в пам’яті.
Висновок
Хоча Twitter є великою організацією, вона має кращу розуміння дизайну системи. Я зробив усе можливе, щоб надати вам загальний огляд хронології Twitter.
Сподіваюся, ви отримали з нього корисну інформацію та зможете використати її з користю.
залишити коментар