Алдыңғы екі онжылдықта ауқымды онлайн қосымшалар ұзақ жолдан өтті. Бұл инновациялар бағдарламалық жасақтаманы әзірлеуге деген көзқарасымызды өзгертті. Мысалы, Facebook, Instagram және Twitter - барлығы масштабталатын платформалар.
Бұл жүйелер трафик пен деректердің үлкен көлемін басқару үшін салынуы керек, өйткені оларды бүкіл әлемде миллиардтаған адамдар бір уақытта пайдаланады. Бұл кезде жүйелік дизайн суретке кіреді.
Белгілі бір критерийлерге сәйкес келетін жүйенің архитектурасын, интерфейстерін және деректерін орнату процесі жүйелік дизайн деп аталады. Бірыңғай және тиімді жүйелер арқылы жүйе дизайны сіздің бизнесіңіздің немесе ұйымыңыздың талаптарын қанағаттандырады.
Сіздің компанияңыз немесе ұйымыңыз өз критерийлерін анықтағаннан кейін, сіз оларды тұтынушылардың талаптарын қанағаттандыратын физикалық жүйе дизайнына қосуды бастай аласыз.
Арнайы әзірлемелерді, коммерциялық шешімдерді немесе екеуінің комбинациясын таңдайсыз ба, жүйені қалай құрастырғаныңыз оны қалай құрастыратыныңызды анықтайды.
Біз оқулықпен бірге осы постта Twitter хронологиясының жүйелік дизайнын егжей-тегжейлі қарастырамыз. Бастайық.
1-қадам: пайдалану жағдайын және шектеулерді көрсетіңіз
Қолдану жағдайы
- Пайдаланушы твиттерді жүктеп салады.
- Қызмет твиттер жазылушыларына push-хабарландырулар мен электрондық хаттарды жібереді.
- Пайдаланушының хронологиясы қаралды (пайдаланушының әрекеті)
- Пайдаланушы үй уақыт шкаласына қарайды (пайдаланушы бақылайтын адамдар әрекеті)
- Түйінді сөздерді пайдаланушы іздейді.
- Қызмет шынымен қол жетімді.
Қолдану аясынан тыс
- Твиттер осы қызметті пайдаланып Twitter Firehose және басқа ағындарға жіберіледі.
- Қызмет пайдаланушының көріну параметрлеріне негізделген твиттерді жояды.
- Егер пайдаланушы жауап берілген адамға да бақыланбаса, жауапты жасырыңыз.
- «Ретвиттерді жасыру» опциясын ескеріңіз.
- Талдау
Шектеулер мен болжамдар
Мемлекет жорамалдары
- Көлік қозғалысы бірдей таралмаған.
- Твит жіберу оңай болуы керек.
- Миллиондаған жазылушыларыңыз болмаса, барлық ізбасарларыңызға твит жіберу жылдам болуы керек.
- 100 миллион белсенді пайдаланушылар бар.
- Ай сайын 15 миллиард твит немесе күн сайын 500 миллион твит
- Әрбір твиттерде орташа есеппен 10 жеткізу фануттары бар.
- Күн сайын fanout 5 миллиард твит жібереді.
- Fanout ай сайын 150 миллиард твит жібереді.
- Ай сайын 250 миллиард оқу сұрауы
- Ай сайын 10 миллиард іздеу
Timeline
- Уақыт шкаласын шарлау оңай болуы керек.
- Твиттер жазудан гөрі оқуға көбірек көңіл бөледі.
- Твиттерді жылдам оқу үшін оңтайландырыңыз
- Твиттерді тұтыну көп уақытты алады.
іздеу
- Іздеу процесі жылдам болуы керек.
- Іздеу көп уақытты алады.
Пайдалануды есептеңіз
Әрбір твиттің өлшемі:
- 8 байт твиттер идентификаторы
- 32 байт пайдаланушы идентификаторы
- 140 байт мәтін
- медиа – орташа 10 КБ
- Барлығы: ~10 КБ
Ай сайын 150 ТБ жаңа твиттер мазмұны жасалады.
- * Күн сайын 500 миллион твит * Айына 30 күн * Әр твитке 10 КБ
- Үш жыл ішінде 5.4 PB жаңа твиттер мазмұны болды.
Әр секунд сайын 100,000 XNUMX оқу сұрауы бар.
- * (секундына 400 сұраныс / айына 1 миллиард сұраныс) ай сайын 250 миллиард оқу сұрауы
Секундына 6,000 твит келеді.
- * (секундына 400 сұраныс / айына 1 миллиард сұраныс) ай сайын 15 миллиард твит
Фанутта секунд сайын 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 Мбайтты ретімен оқу шамамен 250 микросекундты алады, бірақ SSD дискінен оқу 4 есе, ал дискіден оқу 80 есе көп уақыт алады.
Объектілер қоймасын кескіндер мен бейнелер сияқты деректерді сақтау үшін пайдалануға болады.
- Кері прокси ретінде әрекет ететін веб-сервер Клиенттен твит алады.
- Сұрау Write API серверіне веб-сервер арқылы жіберіледі.
- Write API твиттерді пайдаланушының уақыт шкаласында SQL дерекқорына сақтайды.
Fan-Out қызметі Write API арқылы байланысады және ол келесі тапсырмаларды орындайды.
- Пайдаланушының графикалық қызметіне сұрау салу арқылы жад кэшінен пайдаланушының жазылушыларын табады.
- Жад кэшінде твит пайдаланушы ізбасарларының негізгі хронологиясында сақталады.
- 1,000 ізбасар = 1,000 іздеу және кірістіру = O(n) операциясы.
- Твит жылдам іздеу үшін Іздеу индексі қызметінде сақталады.
- Объектілер қоймасы медианы сақтау үшін пайдаланылады.
- Хабарландыру қызметі арқылы жазылушыларға push ескертулерін жібереді.
- Ескертулерді асинхронды түрде жіберу үшін ол кезекті пайдаланады.
Жад кэшіміз Redis болса, біз келесі құрылыммен жергілікті Redis тізімін пайдалана аламыз:
Пайдаланушының үй хронологиясы жад кэшінде сақталатын жаңа твитпен жаңартылады. Біз келесі жалпыға ортақ REST API қолданамыз:
Пайдаланушы уақыт шкаласын пайдаланушы қарайды.
- Веб-сервер Клиенттен пайдаланушының уақыт шкаласы сұрауын алады.
- Сұраныс Read API серверіне веб-сервер арқылы жіберіледі.
- Read API пайдаланушы уақыт аралығы үшін SQL дерекқорын сұрайды.
REST API негізгі уақыт кестесіне ұқсас жұмыс істейді, тек барлық твиттер олар бақылайтын адамдардан гөрі пайдаланушыдан шығады.
Пайдаланушы кілт сөздерді іздейді:
- Веб-сервер Клиенттен іздеу сұрауын алады.
- Сұраныс Search API серверіне веб-сервер арқылы жіберіледі.
4-қадам: Twitter хронологиясы
Уақыт кестесін жасау - қиын жұмыс. Веб немесе қолданба серверлеріне сілтеме жасайтын уақыт кестесін жасайтын сервер қажет.
Пайдаланушы жүйеге кірген сайын уақыт шкаласы қызметі жазылушы кестесіндегі пайдаланушылардың ең жаңа твиттерін қадағалайды және пайдаланушының хронологиясын жаңартады немесе жаңартады.
Біз мұнда рейтингтік жүйенің қандай да бір түрін енгізбейміз; оның орнына, пайдаланушы ізбасарларының ең жақсы 5 твиттері жасау уақытының реті бойынша хронологияда берілген деп болжаймыз. Біз 50 твиттік жаңартуды сақтай аламыз. Пайдаланушы бетті жаңартқанша, осы шекке жеткеннен кейін жаңартуды немесе хронологияны құруды әлі де тоқтатамыз.
Жоғары кідіріс пен өнімділікке қатысты мәселелер тікелей пайдаланушы арнасын жасаудан туындайды. Оның орнына, лезде ұсынылатын желіден тыс ағын жасау өнімділікті жақсартудың ең жақсы жолы болып табылады. Арнаны жасалған уақыт негізінде жаңарту үшін қолданба серверіне жүйелі түрде пинг жіберетін арнайы уақыт шкаласы серверлерін іске қосыңыз.
Реттеу алгоритмі маңызды сигналдарды ескеріп, пайдаланушының уақыт шкаласында олар бақылайтын бір немесе бірнеше тіркелгілердің материалдары басым болмайтынына кепілдік беру үшін салмақты қамтамасыз етуі керек.
Дәлірек айтқанда, біз ұнатулар, пікірлер, бөлісулер саны және жаңарту уақыты сияқты кез келген арна элементінің өзектілігіне қатысты мүмкіндіктерді таңдай аламыз. Осы критерийлердің әрқайсысы твиттерді бағалау үшін пайдаланылуы керек, содан кейін бұл дәреже уақыт шкаласында твиттерді көрсету үшін пайдаланылуы керек.
Жаңалықтар арнасы үшін жаңа мазмұн қолжетімді болған кезде пайдаланушыларды үнемі ескертуіміз керек пе? Пайдаланушылар жаңа деректер қолжетімді болған кезде ескерту алуды тиімді деп санайды. Дегенмен, мобильді құрылғыларда деректерді пайдалану өте қымбат болғанда, өткізу қабілеттілігін жоғалтуы мүмкін.
Нәтижесінде біз деректерді мобильді құрылғыларға жібермеуді таңдай аламыз және оның орнына пайдаланушыларға жаңа хабарламалар үшін «Жаңарту үшін тартуға» рұқсат бере аламыз.
5-қадам: масштабтау дизайны
Ықтимал тығырықтан шығу қызметі Fanout қызметі болып табылады. Миллиондаған жазылушылары бар Twitter қолданушылары өздерінің твиттерін тарату үшін бірнеше минут күтулері керек. Бұл твиттерге жауап беретін жарысты тудыруы мүмкін, біз твиттерге қызмет көрсету уақытында қайта тапсырыс беру арқылы болдырмауға болады.
Сондай-ақ біз көптеген ізбасарлары бар адамдардың твиттерін таратудың алдын ала аламыз. Оның орнына, біз жоғары жазылатын адамдардың твиттерін іздей аламыз, іздеу нәтижелерін пайдаланушының негізгі хронологиясы нәтижелерімен біріктіріп, содан кейін твиттерді қызмет көрсету уақытында қайта реттей аламыз.
Қосымша жақсартуларға мыналар кіреді:
- Әрбір үй уақыт шкаласы үшін жад кэшінде тек бірнеше жүз твиттер сақтаңыз.
- Жад кэшінде тек белсенді пайдаланушылардың үй уақыт кестесі туралы ақпарат сақталады.
- Егер пайдаланушы алдыңғы 30 күнде белсенді болмаса, хронологияны SQL дерекқорынан қайта құруға болады.
- Пайдаланушының кім екенін білу үшін пайдаланушы графигі қызметін пайдаланыңыз.
- Твиттерді SQL дерекқорынан шығарып алу арқылы жад кэшіне қосыңыз.
- Tweet Info қызметі тек бір айлық твиттерді сақтай алады.
- Пайдаланушы туралы ақпарат қызметінде тек белсенді пайдаланушылар сақталады.
- Кідіріс уақытын төмен ұстау үшін Іздеу кластері твиттерді жадта сақтауы мүмкін.
қорытынды
Twitter үлкен ұйым болғанымен, оның жақсырақ түрі бар жүйе дизайнын түсіну. Мен сізге Twitter хронологиясына жоғары деңгейдегі шолуды ұсыну үшін барымды салдым.
Сіз одан пайдалы ақпарат алдыңыз және оны тиімді пайдалана аласыз деп үміттенемін.
пікір қалдыру