За апошнія два дзесяцігоддзі буйнамаштабныя онлайн-прыкладанні прайшлі вялікі шлях. Гэтыя новаўвядзенні змянілі наша ўяўленне аб распрацоўцы праграмнага забеспячэння. Напрыклад, Facebook, Instagram і Twitter з'яўляюцца маштабаванымі платформамі.
Гэтыя сістэмы павінны быць пабудаваны для кіравання велізарнымі аб'ёмамі трафіку і дадзеных, паколькі мільярды людзей выкарыстоўваюць іх адначасова па ўсім свеце. Гэта калі дызайн сістэмы ўваходзіць у карціну.
Працэс усталявання архітэктуры, інтэрфейсаў і даных для сістэмы, якая адпавядае пэўным крытэрам, вядомы як праектаванне сістэмы. Дзякуючы згуртаваным і эфектыўным сістэмам дызайн сістэмы задавальняе патрабаванням вашага бізнесу або арганізацыі.
Пасля таго, як ваша кампанія або арганізацыя вызначылі свае крытэрыі, вы можаце пачаць уключаць іх у дызайн фізічнай сістэмы, якая адпавядае патрабаванням вашых спажыўцоў.
Незалежна ад таго, выбіраеце вы распрацоўку на заказ, камерцыйныя рашэнні або камбінацыю таго і іншага, тое, як вы спраектуеце сваю сістэму, будзе вызначаць, як вы яе будуеце.
Мы падрабязна разгледзім сістэмны дызайн часовай шкалы Twitter у гэтай публікацыі разам з падручнікам. Давайце пачнем.
Крок 1: Акрэсліце варыянт выкарыстання і абмежаванні
Варыянт выкарыстання
- Карыстальнік загружае твіт.
- Сэрвіс адпраўляе пуш-апавяшчэнні і электронныя лісты падпісчыкам твітаў.
- Часавая шкала карыстальніка праглядаецца (дзейнасць карыстальніка)
- Карыстальнік глядзіць на хатнюю графіку (дзейнасць людзей, за якімі ён сочыць)
- Ключавыя словы шукае карыстальнік.
- Сэрвіс сапраўды даступны.
Па-за рамкамі
- Твіты адпраўляюцца ў 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 разоў больш часу.
Для захоўвання такіх дадзеных, як выявы і відэа, можна выкарыстоўваць Object Store.
- Вэб-сервер, які дзейнічае як адваротны проксі, атрымлівае твіт ад Кліента.
- Вэб-сервер адпраўляе запыт на сервер Write API.
- Write API захоўвае твіт у базе дадзеных SQL у часовай шкале карыстальніка.
Да службы Fan-Out звяртаецца Write API, і яна выконвае наступныя задачы.
- Знаходзіць паслядоўнікаў карыстальніка ў кэшы памяці, запытваючы ў сэрвіс графа карыстальнікаў.
- У кэшы памяці твіт захоўваецца ў хатняй шкале часу падпісчыкаў карыстальніка.
- 1,000 падпісчыкаў = 1,000 пошукаў і ўставак = аперацыя O(n).
- Твіт захоўваецца ў сэрвісе індэкса пошуку для хуткага пошуку.
- Аб'ектнае крама выкарыстоўваецца для захоўвання медыя.
- Адпраўляе 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.
Я спадзяюся, што вы атрымалі з яго карысную інфармацыю і зможаце выкарыстоўваць яе з карысцю.
Пакінуць каментар