Мащабните онлайн приложения изминаха дълъг път през последните две десетилетия. Тези иновации промениха нашите възприятия за разработката на софтуер. Facebook, Instagram и Twitter, например, са мащабируеми платформи.
Тези системи трябва да бъдат изградени за управление на огромни обеми трафик и данни, тъй като милиарди хора ги използват едновременно по целия свят. Това е когато дизайн на системата влиза в картината.
Процесът на установяване на архитектура, интерфейси и данни за система, която отговаря на определени критерии, е известен като системен дизайн. Чрез сплотени и ефективни системи, системният дизайн удовлетворява изискванията на вашия бизнес или организация.
След като вашата компания или организация са определили своите критерии, можете да започнете да ги включвате в дизайн на физическа система, който отговаря на изискванията на вашите потребители.
Независимо дали решите да използвате разработка по поръчка, търговски решения или комбинация от двете, начина, по който проектирате вашата система, ще определи как ще я изградите.
Ще разгледаме подробно дизайна на системата на времевата линия в Twitter в тази публикация, в комплект с урок. Да започваме.
Стъпка 1: Очертайте случай на употреба и ограничения
Случай за употреба
- Потребител качва туит.
- Услугата изпраща push известия и имейли до последователите на туитове.
- Времевата линия на потребителя се преглежда (активност от потребителя)
- Потребителят разглежда домашната времева линия (активност от хора, които потребителят следва)
- Ключовите думи се търсят от потребителя.
- Услугата е наистина достъпна.
Извън обхвата
- Туитовете се изпращат до Twitter Firehose и други потоци, използващи тази услуга.
- Услугата премахва туитове въз основа на настройките за видимост на потребителя.
- Ако потребителят също не следва лицето, на което се отговаря, скрийте отговора.
- Спазвайте опцията „скриване на ретуитове“.
- Анализи
Ограничения и предположения
Държавни предположения
- Трафикът не е равномерно разпределен.
- Трябва да е лесно да изпратите туит.
- Освен ако нямате милиони последователи, изпращането на туит до всичките ви последователи трябва да бъде бързо.
- Има 100 милиона активни потребители.
- 15 милиарда туитове всеки месец или 500 милиона туитове всеки ден
- Всеки туит има разклонение от 10 доставки средно.
- Всеки ден fanout доставя 5 милиарда туитове.
- Fanout доставя 150 милиарда туитове всеки месец.
- 250 милиарда месечни заявки за четене
- 10 милиарда месечни търсения
История
- Времевата линия трябва да е лесна за навигация.
- Twitter е повече за четене, отколкото за писане.
- Оптимизирайте за бързо четене на туит
- Консумацията на туит отнема много време.
Търсене
- Процесът на търсене трябва да бъде бърз.
- Търсенето отнема много време.
Изчислете употребата
Размер на всеки туит:
- 8 байта идентификатор на туит
- 32 байта потребителски идентификатор
- 140 байта текст
- медия – средно 10 KB
- Общо: ~10 KB
Всеки месец се генерират 150 TB свежо туит съдържание.
- * 500 милиона туитове всеки ден * 30 дни на месец * 10 KB на туит
- За три години имаше 5.4 PB ново съдържание в туит.
Всяка секунда има 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 милиона заявки на месец x 40 заявки в секунда
- 1 милиард заявки на месец = 400 заявки в секунда
Стъпка 2: Диаграма на високо ниво
Стъпка 3: Обяснение на основните компоненти
Бихме могли да запазим собствените туитове на потребителя, за да попълним времевата линия на потребителя (активност от потребителя) в релационна база данни, ако изпратят туит. По-трудно е да се доставят туитове и да се развива домашната времева линия (дейност от лица, които потребителят следва).
Типичната релационна база данни ще бъде затрупана от разпръскване на туитове до всички последователи (60 хиляди туитове, доставяни всяка секунда). Вероятно ще искаме да използваме хранилище за бързо записване на данни като NoSQL база данни или кеш на паметта.
Четенето на 1 MB последователно от паметта отнема приблизително 250 микросекунди, но четенето от SSD отнема 4 пъти повече време, а четенето от диск отнема 80 пъти повече време.
Магазин за обекти може да се използва за съхраняване на данни като изображения и видеоклипове.
- Уеб сървърът, който действа като обратен прокси, получава туит от Клиента.
- Заявката се изпраща към Write API сървъра от уеб сървъра.
- API за писане записва туита в SQL база данни във времевата линия на потребителя.
Услугата Fan-Out се свързва от Write API и изпълнява следните задачи.
- Намира последователите на потребителя в кеша на паметта, като отправя заявка към услугата User Graph.
- В кеша на паметта туитът се запазва в домашната времева линия на последователите на потребителя.
- 1,000 последователи = 1,000 търсения и вмъквания = O(n) операция.
- Туитът се запазва в услугата Search Index за бързо търсене.
- Магазинът на обекти се използва за съхранение на медии.
- Изпраща push сигнали до последователите чрез услугата за уведомяване.
- За да изпраща сигнали асинхронно, той използва опашка.
Можем да използваме собствен списък на Redis със следната структура, ако нашия кеш памет е Redis:
Домашната времева линия на потребителя ще бъде актуализирана с новия туит, който ще се съхранява в кеша на паметта. Ще използваме следния публичен REST API:
Времевата линия на потребителя се преглежда от потребителя.
- Уеб сървърът получава заявка за времева линия на потребителя от Клиента.
- Заявката се изпраща до сървъра Read API от уеб сървъра.
- API за четене отправя заявка към SQL базата данни за потребителския времеви период.
REST API ще работи подобно на домашната времева линия, с изключение, че всички туитове ще произхождат от потребителя, а не от хората, които следват.
Потребител търси ключови думи:
- Уеб сървърът получава заявка за търсене от Клиента.
- Заявката се изпраща към сървъра на Search API от уеб сървъра.
Стъпка 4: Времева линия в Twitter
Създаването на времева линия е трудна задача. Необходим е сървър за генериране на времева линия, който се свързва към уеб сървърите или сървърите на приложения.
Всеки път, когато потребител влезе, услугата времева линия поддържа проследяване на най-новите туитове от потребителите в таблицата на последователите и актуализира или опреснява времевата линия на потребителя.
Тук не прилагаме никаква система за класиране; вместо това предполагаме, че първите 5 туита от последователите на потребителя са представени във времевата линия по реда на времето на създаване. Можем да поддържаме прекъсване на опресняване от 50 туита. Все още спираме да опресняваме или изграждаме времева линия, след като този праг бъде достигнат, докато потребителят не опресни страницата.
Притесненията за висока латентност и производителност ще дойдат от създаването на емисии на живи потребители. Вместо това създаването на офлайн поток, който може да бъде представен незабавно, е най-добрият начин за подобряване на производителността. Стартирайте специални сървъри на времевата линия, които редовно пингуват сървъра на приложения, за да обновят емисията въз основа на времето, когато е създадена.
Алгоритъмът за класиране трябва да вземе предвид важни сигнали и да осигури тежест, за да гарантира, че времевата линия на потребителя не е доминирана от материали от един или повече от акаунтите, които следва.
По-точно, можем да избираме функции, свързани с уместността на всеки елемент от емисия, като брой харесвания, коментари, споделяния и време за актуализиране. Всеки от тези критерии трябва да се използва за оценяване на туита и след това този ранг трябва да се използва за показване на туитове на времевата линия.
Трябва ли постоянно да предупреждаваме потребителите, когато стане достъпно ново съдържание за тяхната емисия с новини? Потребителите могат да намерят за полезно да бъдат предупредени, когато станат налични нови данни. На мобилни устройства обаче, когато използването на данни е доста скъпо, това може да загуби честотна лента.
В резултат на това можем да изберем да не изпращаме данни към мобилни устройства и вместо това да позволим на потребителите да „Издърпват за опресняване“ за нови публикации.
Стъпка 5: Дизайн на мащабиране
Потенциално тесно място е услугата Fanout. Потребителите на Twitter с милиони последователи ще трябва да изчакат няколко минути, за да се пуснат техните туитове. Това може да доведе до надпревара с отговори на туита, което бихме могли да избегнем, като пренаредим туитовете по време на обслужване.
Бихме могли също да предотвратим разпространението на туитове от хора с голям брой последователи. Вместо това можем да търсим туитове от много следвани лица, да интегрираме резултатите от търсенето с резултатите от домашната времева линия на потребителя и след това да пренареждаме туитовете по време на обслужване.
Допълнителните подобрения включват:
- Съхранявайте само няколкостотин туитове в кеша на паметта за всяка домашна времева линия.
- В кеша на паметта се запазва само информацията за домашната времева линия на активните потребители.
- Можем да възстановим хронологията от SQL базата данни, ако потребителят не е бил активен през предходните 30 дни.
- За да разберете кой е потребителят, използвайте услугата User Graph.
- Добавете туитовете към кеша на паметта, като ги извлечете от SQL базата данни.
- Информационната услуга за туит може да спести само туитове за един месец.
- В услугата за информация за потребителя се записват само активни потребители.
- За да запази латентността ниска, най-вероятно клъстерът за търсене ще трябва да поддържа туитовете в паметта.
Заключение
Въпреки че Twitter е голяма организация, тя има по-добра разбиране на системния дизайн. Направих всичко възможно да ви предоставя преглед на високо ниво на времевата линия в Twitter.
Надявам се, че сте получили полезна информация от него и можете да го използвате добре.
Оставете коментар