Լայնածավալ առցանց հավելվածները մեծ ճանապարհ են անցել նախորդ երկու տասնամյակների ընթացքում: Այս նորամուծությունները փոխել են ծրագրային ապահովման մշակման մեր պատկերացումները: Facebook-ը, Instagram-ը և Twitter-ը, օրինակ, բոլորն էլ մասշտաբային հարթակներ են:
Այս համակարգերը պետք է ստեղծվեն երթևեկության և տվյալների հսկայական ծավալները կառավարելու համար, քանի որ միլիարդավոր մարդիկ դրանք օգտագործում են միաժամանակ ամբողջ աշխարհում: Սա այն դեպքում, երբ համակարգի նախագծում մտնում է նկարը:
Որոշ չափանիշներին համապատասխանող համակարգի համար ճարտարապետության, միջերեսների և տվյալների հաստատման գործընթացը հայտնի է որպես համակարգի ձևավորում: Համատեղ և արդյունավետ համակարգերի միջոցով համակարգի դիզայնը բավարարում է ձեր բիզնեսի կամ կազմակերպության պահանջները:
Երբ ձեր ընկերությունը կամ կազմակերպությունը որոշի իր չափանիշները, դուք կարող եք սկսել դրանք ներառել ֆիզիկական համակարգի ձևավորման մեջ, որը համապատասխանում է ձեր սպառողների պահանջներին:
Անկախ նրանից, թե դուք ընտրում եք գնալ պատվերով մշակման, առևտրային լուծումների կամ այս երկուսի համակցման հետ, այն, թե ինչպես եք նախագծում ձեր համակարգը, կորոշի, թե ինչպես եք այն կառուցել:
Մենք մանրամասն կանդրադառնանք Twitter-ի ժամանակացույցի համակարգի ձևավորմանը այս գրառման մեջ՝ ամբողջական ձեռնարկով: Եկեք սկսենք.
Քայլ 1. Ուրվագծեք օգտագործման դեպքը և սահմանափակումները
Օգտագործման դեպքը
- Օգտատերը վերբեռնում է թվիթ:
- Ծառայությունը ուղարկում է push ծանուցումներ և էլեկտրոնային նամակներ թվիթերի հետևորդներին:
- Օգտագործողի ժամանակացույցը դիտվում է (գործունեությունը օգտվողից)
- Օգտագործողը նայում է տան ժամանակացույցին (ակտիվություն մարդկանց կողմից, որոնց հետևում է օգտվողը)
- Հիմնաբառերը որոնվում են օգտագործողի կողմից:
- Ծառայությունն իսկապես հասանելի է։
Շրջանակից դուրս
- Թվիթերն ուղարկվում են Twitter Firehose և այլ հոսքեր՝ օգտագործելով այս ծառայությունը:
- Ծառայությունը հեռացնում է թվիթերը՝ ելնելով օգտատիրոջ տեսանելիության կարգավորումներից։
- Եթե օգտատերը նույնպես չի հետևում նրան, ում պատասխանում են, թաքցրեք պատասխանը:
- Դիտեք «թաքցնել retweets» տարբերակը:
- Վերլուծություն
Սահմանափակումներ և ենթադրություններ
Պետական ենթադրություններ
- Երթևեկությունը հավասարապես չի ցրվում.
- Թվիթ ուղարկելը պետք է լինի պարզ:
- Եթե դուք միլիոնավոր հետևորդներ չունեք, ձեր բոլոր հետևորդներին թվիթ ուղարկելը պետք է արագ լինի:
- 100 միլիոն ակտիվ օգտատեր կա։
- 15 միլիարդ թվիթ ամեն ամիս կամ 500 միլիոն թվիթ ամեն օր
- Յուրաքանչյուր թվիթ ունի միջինը 10 առաքում:
- Ամեն օր fanout-ը 5 միլիարդ թվիթ է հաղորդում:
- Fanout-ը ամեն ամիս տրամադրում է 150 միլիարդ թվիթ:
- 250 միլիարդ ամսական ընթերցման հարցում
- 10 միլիարդ ամսական որոնումներ
Խրոնոլոգիա
- Ժամանակացույցը պետք է հեշտ լինի նավարկելու համար:
- Twitter-ը ավելի շատ կարդալու, քան գրելու մասին է:
- Օպտիմալացնել թվիթերի արագ ընթերցման համար
- Թվիթերի օգտագործումը ժամանակատար է:
Որոնել
- Որոնման գործընթացը պետք է լինի արագ:
- Որոնումը ժամանակատար է:
Հաշվարկել օգտագործումը
Յուրաքանչյուր թվիթի չափը՝
- 8 բայթ թվիթ id
- 32 բայթ օգտագործողի ID
- 140 բայթ տեքստ
- մեդիա – միջինը 10 ԿԲ
- Ընդհանուր՝ ~10 ԿԲ
Ամեն ամիս ստեղծվում է 150 ՏԲ թարմ թվիթերի բովանդակություն:
- * 500 միլիոն թվիթ ամեն օր * 30 օր ամսական * 10 ԿԲ մեկ թվիթում
- Երեք տարվա ընթացքում եղել է 5.4 PB թարմ թվիթերի բովանդակություն:
Ամեն վայրկյան 100,000 ընթերցման հարցում կա:
- * (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 անգամ ավելի երկար:
Object Store-ը կարող է օգտագործվել տվյալների պահպանման համար, ինչպիսիք են պատկերները և տեսանյութերը:
- Վեբ սերվերը, որը հանդես է գալիս որպես հակադարձ պրոքսի, հաճախորդից թվիթ է ստանում:
- Հարցումը ուղարկվում է Write API սերվերին վեբ սերվերի կողմից:
- Write API-ն թվիթը պահում է օգտատիրոջ ժամանակացույցի SQL տվյալների բազայում:
Fan-Out ծառայության հետ կապվում է Write API-ն, և այն կատարում է հետևյալ առաջադրանքները.
- Հիշողության քեշում գտնում է օգտատիրոջ հետևորդներին՝ հարցումներ կատարելով Օգտատերերի գրաֆիկական ծառայությանը:
- Հիշողության քեշի վրա թվիթը պահվում է օգտատիրոջ հետևորդների հիմնական ժամանակացույցում:
- 1,000 հետևորդ = 1,000 որոնում և ներդիր = O(n) գործողություն:
- Թվիթը պահվում է Search Index Service-ում արագ որոնման համար:
- Օբյեկտների խանութը օգտագործվում է լրատվամիջոցները պահելու համար:
- Ծանուցումների ծառայության միջոցով ուղարկում է ծանուցումներ հետևորդներին:
- Ազդանշանները ասինխրոն կերպով ուղարկելու համար այն օգտագործում է հերթ:
Մենք կարող ենք օգտագործել բնիկ Redis ցուցակը հետևյալ կառուցվածքով, եթե մեր հիշողության քեշը Redis է.
Օգտատիրոջ տան ժամանակացույցը կթարմացվի նոր թվիթով, որը կպահվի Memory Cache-ում: Մենք կօգտագործենք հետևյալ հանրային REST API-ն.
Օգտագործողի ժամանակացույցը դիտվում է օգտագործողի կողմից:
- Վեբ սերվերը հաճախորդից ստանում է օգտվողի ժամանակացույցի հարցում:
- Հարցումն ուղարկվում է Read API սերվերին Web Server-ի կողմից:
- Read API-ն հարցնում է SQL տվյալների բազան օգտվողի ժամանակային շրջանակի համար:
REST API-ն կաշխատի տնային ժամանակացույցի նման, բացառությամբ, որ բոլոր թվիթերը ծագում են օգտատերից, այլ ոչ թե այն մարդկանցից, ում հետևում են:
Օգտագործողը որոնում է հիմնաբառեր.
- Վեբ սերվերը հաճախորդի կողմից որոնման հարցում է ստանում:
- Հարցումն ուղարկվում է Search API սերվերին վեբ սերվերի կողմից:
Քայլ 4. Twitter-ի ժամանակացույցը
Ժամանակացույցի ստեղծումը բարդ խնդիր է: Պահանջվում է ժամանակացույցի ստեղծող սերվեր, որը կապում է համացանցին կամ հավելվածի սերվերներին:
Ամեն անգամ, երբ օգտատերը մուտք է գործում, ժամանակացույցի ծառայությունը հետևում է հետևորդների աղյուսակում օգտատերերի ամենանոր թվիթներին և թարմացնում կամ թարմացնում է օգտվողի ժամանակացույցը:
Այստեղ մենք որևէ տեսակի վարկանիշային համակարգ չենք իրականացնում. փոխարենը, մենք ենթադրում ենք, որ օգտատերերի հետևորդների լավագույն 5 թվիթերը ներկայացված են ժամանակացույցում՝ ըստ ստեղծման ժամանակի: Մենք կարող ենք պահպանել 50 թվիթների թարմացման կտրվածք: Այդ շեմը լրանալուց հետո մենք դեռ դադարում ենք թարմացնել կամ ստեղծել ժամանակացույց, մինչև օգտատերը թարմացնի էջը:
Բարձր հետաձգման և արդյունավետության հետ կապված մտահոգությունները կառաջանան կենդանի օգտատերերի հոսքի ստեղծումից: Փոխարենը, օֆլայն հոսքի ստեղծումը, որը կարող է ակնթարթորեն ներկայացվել, կատարողականությունը բարելավելու լավագույն միջոցն է: Գործարկեք հատուկ ժամանակացույցի սերվերներ, որոնք կանոնավոր կերպով ping են անում հավելվածի սերվերին՝ թարմացնելու համար թարմացվող բովանդակությունը՝ հիմնվելով դրա ստեղծման ժամանակի վրա:
Վարկանիշային ալգորիթմը պետք է հաշվի առնի կարևոր ազդանշանները և ապահովի կշիռ՝ երաշխավորելու, որ օգտագործողի ժամանակագրության մեջ գերակշռում են մեկ կամ մի քանի հաշիվների նյութերը, որոնց նրանք հետևում են:
Ավելի ճիշտ, մենք կարող ենք ընտրել ցանկացած ֆիդ նյութի համապատասխանության հետ կապված գործառույթներ, ինչպիսիք են հավանումների քանակը, մեկնաբանությունները, համօգտագործումները և թարմացման ժամանակը: Այս չափանիշներից յուրաքանչյուրը պետք է օգտագործվի թվիթը գնահատելու համար, այնուհետև այդ վարկանիշը պետք է օգտագործվի՝ թվիթները ժամանակացույցի վրա ցուցադրելու համար:
Արդյո՞ք մենք պետք է անընդհատ զգուշացնենք օգտատերերին, երբ նոր բովանդակությունը հասանելի է դառնում նրանց նորությունների համար: Օգտատերերը կարող են շահավետ համարել զգոնությունը, երբ նոր տվյալներ հայտնվեն: Շարժական սարքերում, սակայն, երբ տվյալների օգտագործումը բավականին ծախսատար է, այն կարող է վատնել թողունակությունը:
Արդյունքում, մենք կարող ենք ընտրել չուղարկել տվյալները դեպի շարժական սարքեր և փոխարենը թույլ տալ օգտատերերին «Քաշել թարմացնելու» նոր հրապարակումների համար:
Քայլ 5. Սանդղակի ձևավորում
Հնարավոր խոչընդոտը Fanout ծառայությունն է: Միլիոնավոր հետևորդներ ունեցող Twitter-ի օգտատերերը ստիպված կլինեն մի քանի րոպե սպասել իրենց թվիթերի հրապարակմանը: Սա կարող է առաջացնել թվիթին պատասխաններով մրցավազք, որից մենք կարող ենք խուսափել՝ վերահաստատելով թվիթերը սպասարկման ժամանակ:
Մենք կարող էինք նաև կանխել մեծ թվով հետևորդներ ունեցող մարդկանց թվիթերի տարածումը: Փոխարենը, մենք կարող ենք որոնել թվիթներ մեծ հետևորդներից օգտվող անձանցից, ինտեգրել որոնման արդյունքները օգտատիրոջ հիմնական ժամանակացույցի արդյունքների հետ, և այնուհետև վերադասավորել թվիթերը սպասարկման ժամանակ:
Լրացուցիչ բարելավումները ներառում են.
- Պահպանեք ընդամենը մի քանի հարյուր թվիթ Հիշողության քեշում յուրաքանչյուր տնային ժամանակացույցի համար:
- Հիշողության քեշում պահվում են միայն ակտիվ օգտատերերի տնային ժամանակացույցի տեղեկությունները:
- Մենք կարող ենք վերակառուցել ժամանակագրությունը SQL տվյալների բազայից, եթե օգտատերը ակտիվ չի եղել նախորդ 30 օրվա ընթացքում:
- Պարզելու համար, թե ով է օգտատերը, օգտագործեք Օգտագործողի գրաֆիկի ծառայությունը:
- Թվիթերը ավելացրեք «Memory Cache»-ին՝ դրանք առբերելով SQL տվյալների բազայից:
- Tweet Info Service-ը կարող է խնայել միայն մեկ ամսվա թվիթերը:
- Օգտատիրոջ տեղեկատվության ծառայությունում պահպանվում են միայն ակտիվ օգտվողները:
- Լատենտությունը ցածր պահելու համար Search Cluster-ին, ամենայն հավանականությամբ, պետք է պահպանի թվիթները հիշողության մեջ:
Եզրափակում
Չնայած Twitter-ը մեծ կազմակերպություն է, այն ունի ավելի լավը համակարգի դիզայնի իմացություն. Ես ամեն ինչ արեցի, որպեսզի ձեզ տրամադրեմ Twitter-ի ժամանակացույցի բարձր մակարդակի ակնարկ:
Հուսով եմ, որ դուք դրանից օգտակար տեղեկատվություն եք ստացել և կարող եք այն լավ օգտագործել:
Թողնել գրառում