Բարեւ բոլորին! Ես Սերգեյ Կոստանբաևն եմ, բորսայում ես մշակում եմ առևտրային համակարգի կորիզը։
Երբ հոլիվուդյան ֆիլմերը ցուցադրում են Նյու Յորքի ֆոնդային բորսան, այն միշտ այսպիսի տեսք ունի՝ մարդկանց բազմություն, բոլորը ինչ-որ բան են բղավում, թղթեր են թափահարում, կատարյալ քաոս է տեղի ունենում։ Դա երբեք տեղի չի ունեցել այստեղ՝ Մոսկվայի բորսայում, քանի որ առևտուրն ի սկզբանե իրականացվել է էլեկտրոնային եղանակով և հիմնված է երկու հիմնական հարթակների վրա՝ Spectra (արտարժույթի շուկա) և ASTS (արտարժույթի բորսա, ֆոնդային և դրամական շուկա): Եվ այսօր ես ուզում եմ խոսել ASTS առևտրային և քլիրինգային համակարգի ճարտարապետության էվոլյուցիայի, տարբեր լուծումների և բացահայտումների մասին: Պատմությունը երկար է լինելու, ուստի ստիպված էի այն բաժանել երկու մասի։
Մենք աշխարհի այն սակավաթիվ բորսաներից ենք, որոնք առևտուր են անում բոլոր դասերի ակտիվներով և տրամադրում փոխանակման ծառայությունների ամբողջական փաթեթ: Օրինակ՝ անցյալ տարի պարտատոմսերի առուվաճառքի ծավալով աշխարհում զբաղեցրել ենք երկրորդ տեղը, 25-րդ տեղը բոլոր ֆոնդային բորսաներում, 13-րդ տեղը կապիտալիզացիայի առումով՝ հանրային բորսաներում։
Առևտրի պրոֆեսիոնալ մասնակիցների համար կարևոր են այնպիսի պարամետրեր, ինչպիսիք են արձագանքման ժամանակը, ժամանակի բաշխման կայունությունը (ցնցում) և ամբողջ համալիրի հուսալիությունը: Ներկայումս մենք օրական մշակում ենք տասնյակ միլիոնավոր գործարքներ: Համակարգի միջուկի կողմից յուրաքանչյուր գործարքի մշակումը տևում է տասնյակ միկրովայրկյաններ: Իհարկե, բջջային օպերատորները Ամանորի գիշերը կամ որոնիչները իրենք ունեն ավելի մեծ ծանրաբեռնվածություն, քան մերը, բայց ծանրաբեռնվածության առումով, վերը նշված բնութագրերի հետ մեկտեղ, քչերը կարող են համեմատվել մեզ հետ, ինձ թվում է: Միաժամանակ մեզ համար կարևոր է, որ համակարգը ոչ մի վայրկյան չդանդաղի, աշխատի բացարձակ կայուն, և բոլոր օգտատերերը լինեն հավասար պայմաններում։
Մի փոքր պատմություն
1994 թվականին Մոսկվայի միջբանկային արժութային բորսայում (MICEX) գործարկվեց ավստրալական ASTS համակարգը, և այդ պահից կարելի է հաշվել էլեկտրոնային առևտրի ռուսական պատմությունը: 1998 թվականին բորսայի ճարտարապետությունը արդիականացվեց՝ ինտերնետ առևտուրը ներմուծելու համար: Այդ ժամանակից ի վեր բոլոր համակարգերում և ենթահամակարգերում նոր լուծումների և ճարտարապետական փոփոխությունների ներդրման արագությունը միայն թափ է հավաքում:
Այդ տարիներին փոխանակման համակարգն աշխատում էր բարձրակարգ ապարատային՝ ծայրահեղ հուսալի HP Superdome 9000 սերվերների վրա (կառուցված), որում կրկնօրինակված էր բացարձակապես ամեն ինչ՝ մուտքային/ելքային ենթահամակարգեր, ցանց, օպերատիվ հիշողություն (իրականում կար RAM-ի RAID զանգված), պրոցեսորներ (hot-swappable): Հնարավոր էր փոխել ցանկացած սերվերի բաղադրիչ առանց մեքենան կանգնեցնելու: Մենք ապավինում էինք այս սարքերին և համարում էինք, որ դրանք գործնականում անվտանգ չեն: Օպերացիոն համակարգը Unix-ի նման HP UX համակարգ էր:
Բայց մոտավորապես 2010 թվականից ի վեր ի հայտ եկավ մի ֆենոմեն, որը կոչվում է բարձր հաճախականությամբ առևտուր (HFT), կամ բարձր հաճախականությամբ առևտուր՝ պարզ ասած, ֆոնդային բորսայի ռոբոտներ: Ընդամենը 2,5 տարվա ընթացքում մեր սերվերների ծանրաբեռնվածությունն ավելացել է 140 անգամ։
Հին ճարտարապետությամբ ու տեխնիկայով նման ծանրաբեռնվածությանը դիմանալն անհնար էր։ Պետք էր ինչ-որ կերպ հարմարվել։
Начало
Փոխանակման համակարգին ուղղված հարցումները կարելի է բաժանել երկու տեսակի.
- Գործարքներ. Եթե ցանկանում եք գնել դոլար, բաժնետոմս կամ այլ բան, դուք գործարք եք ուղարկում առևտրային համակարգ և ստանում պատասխան հաջողության մասին:
- Տեղեկատվության հարցումներ. Եթե ցանկանում եք պարզել ընթացիկ գինը, դիտեք պատվերների գիրքը կամ ցուցանիշները, ապա ուղարկեք տեղեկատվության հարցումներ:
Սխեմատիկորեն համակարգի առանցքը կարելի է բաժանել երեք մակարդակի.
- Հաճախորդի մակարդակը, որտեղ աշխատում են բրոքերները և հաճախորդները: Նրանք բոլորը փոխազդում են մուտքի սերվերների հետ:
- Gateway սերվերները քեշավորման սերվերներ են, որոնք տեղայնորեն մշակում են տեղեկատվության բոլոր հարցումները: Ցանկանու՞մ եք իմանալ, թե ներկայումս ինչ գնով են վաճառվում Սբերբանկի բաժնետոմսերը: Հարցումը գնում է մուտքի սերվեր:
- Բայց եթե ցանկանում եք բաժնետոմսեր գնել, ապա հարցումը գնում է կենտրոնական սերվեր (Trade Engine): Յուրաքանչյուր տեսակի շուկայի համար կա մեկ այդպիսի սերվեր, նրանք կենսական դեր են խաղում, նրանց համար է, որ մենք ստեղծել ենք այս համակարգը:
Առևտրային համակարգի առանցքը խելացի հիշողության տվյալների բազան է, որտեղ բոլոր գործարքները փոխանակման գործարքներ են: Հիմքը գրված էր C-ով, միակ արտաքին կախվածությունը libc գրադարանն էր և ընդհանրապես դինամիկ հիշողության տեղաբաշխում չկար: Մշակման ժամանակը նվազեցնելու համար համակարգը սկսում է զանգվածների ստատիկ շարքով և ստատիկ տվյալների տեղափոխմամբ. նախ ընթացիկ օրվա բոլոր տվյալները բեռնվում են հիշողության մեջ, և սկավառակի հետագա մուտք չի իրականացվում, ամբողջ աշխատանքն իրականացվում է միայն հիշողության մեջ: Երբ համակարգը գործարկվում է, բոլոր տեղեկատու տվյալները արդեն տեսակավորված են, ուստի որոնումը շատ արդյունավետ է աշխատում և գործարկման ժամանակ քիչ ժամանակ է պահանջում: Բոլոր աղյուսակները կազմված են դինամիկ տվյալների կառուցվածքների համար ներխուժող ցուցակներով և ծառերով, որպեսզի դրանք չպահանջեն հիշողության բաշխում գործարկման ժամանակ:
Համառոտ անդրադառնանք մեր առևտրի և քլիրինգային համակարգի զարգացման պատմությանը:
Առևտրային և քլիրինգային համակարգի ճարտարապետության առաջին տարբերակը կառուցվել է այսպես կոչված Unix փոխազդեցության վրա. օգտագործվել են ընդհանուր հիշողություն, սեմաֆորներ և հերթեր, և յուրաքանչյուր գործընթաց բաղկացած է մեկ թելից: Այս մոտեցումը լայն տարածում գտավ 1990-ականների սկզբին։
Համակարգի առաջին տարբերակը պարունակում էր Gateway-ի երկու մակարդակ և առևտրային համակարգի կենտրոնական սերվեր: Աշխատանքային հոսքը հետևյալն էր.
- Հաճախորդը հարցում է ուղարկում, որը հասնում է Gateway: Այն ստուգում է ձևաչափի վավերականությունը (բայց ոչ բուն տվյալները) և մերժում է սխալ գործարքները:
- Եթե տեղեկատվության հարցումն ուղարկվել է, ապա այն կատարվում է տեղում. եթե մենք խոսում ենք գործարքի մասին, ապա այն վերահղվում է կենտրոնական սերվեր:
- Առևտրային շարժիչն այնուհետև մշակում է գործարքը, փոփոխում է տեղական հիշողությունը և պատասխան է ուղարկում գործարքին և ինքնին գործարքին վերարտադրման համար՝ օգտագործելով առանձին կրկնօրինակման շարժիչ:
- Gateway-ը ստանում է պատասխանը կենտրոնական հանգույցից և այն փոխանցում հաճախորդին:
- Որոշ ժամանակ անց Gateway-ը ստանում է գործարքը կրկնօրինակման մեխանիզմի միջոցով, և այս անգամ այն կատարում է տեղական մակարդակում՝ փոխելով իր տվյալների կառուցվածքը, որպեսզի հաջորդ տեղեկատվական հարցումները ցուցադրեն վերջին տվյալները։
Փաստորեն, այն նկարագրում է կրկնօրինակման մոդել, որում Gateway-ն ամբողջությամբ կրկնօրինակում է առևտրային համակարգում կատարված գործողությունները: Առանձին կրկնօրինակման ալիքը երաշխավորում էր, որ գործարքները կատարվում են նույն հերթականությամբ՝ բազմաթիվ մուտքի հանգույցների միջոցով:
Քանի որ կոդը միայնակ էր, շատ հաճախորդներ սպասարկելու համար օգտագործվեց դասական սխեման պրոցեսային պատառաքաղներով: Այնուամենայնիվ, ամբողջ տվյալների բազան բաժանելը շատ թանկ էր, ուստի օգտագործվեցին թեթև սպասարկման գործընթացներ, որոնք հավաքում էին փաթեթներ TCP նիստերից և տեղափոխում դրանք մեկ հերթում (SystemV Message Queue): Gateway-ը և Trade Engine-ն աշխատում էին միայն այս հերթի հետ՝ այնտեղից գործարքներ վերցնելով կատարման համար: Դրան այլևս հնարավոր չէր պատասխան ուղարկել, քանի որ պարզ չէր, թե որ սպասարկման գործընթացում պետք է կարդալ այն։ Այսպիսով, մենք դիմեցինք մի հնարքի. յուրաքանչյուր պատառաքաղված գործընթաց իր համար ստեղծում էր պատասխանի հերթ, և երբ հարցումը մտնում էր մուտքային հերթում, անմիջապես դրան ավելացվում էր պատասխանի հերթի պիտակ:
Հերթից հերթ մեծ քանակությամբ տվյալների անընդհատ պատճենումը խնդիրներ է առաջացրել, հատկապես տեղեկատվական հարցումների համար: Ուստի մենք օգտագործեցինք մեկ այլ հնարք՝ պատասխանների հերթից բացի, յուրաքանչյուր պրոցես ստեղծում էր նաև ընդհանուր հիշողություն (SystemV Shared Memory): Փաթեթներն իրենք դրված էին դրա մեջ, և հերթում պահվում էր միայն պիտակ, որը թույլ էր տալիս գտնել բնօրինակ փաթեթը: Սա օգնեց տվյալների պահպանմանը պրոցեսորի քեշում:
SystemV IPC-ն ներառում է կոմունալ ծառայություններ՝ հերթի, հիշողության և սեմաֆորի օբյեկտների վիճակը դիտելու համար: Մենք ակտիվորեն օգտագործում էինք սա՝ հասկանալու համար, թե ինչ է կատարվում համակարգում կոնկրետ պահին, որտեղ են կուտակվում փաթեթները, ինչն է արգելափակված և այլն։
Առաջին արդիականացումները
Առաջին հերթին, մենք ազատվեցինք մեկ գործընթացի Gateway-ից: Դրա էական թերությունն այն էր, որ այն կարող էր կարգավորել կա՛մ մեկ կրկնօրինակման գործարք, կա՛մ մեկ հաճախորդի կողմից տեղեկատվության հարցում: Եվ քանի որ բեռը մեծանում է, Gateway-ին ավելի երկար կպահանջվի հարցումները մշակելու համար և չի կարողանա մշակել կրկնօրինակման հոսքը: Բացի այդ, եթե հաճախորդը գործարք է ուղարկել, ապա ձեզ հարկավոր է միայն ստուգել դրա վավերականությունը և այն հետագա փոխանցել: Հետևաբար, մենք փոխարինեցինք մեկ Gateway պրոցեսը մի քանի բաղադրիչներով, որոնք կարող են զուգահեռ աշխատել. բազմաթելային տեղեկատվություն և գործարքների գործընթացներ, որոնք աշխատում են միմյանցից անկախ ընդհանուր հիշողության տարածքում՝ օգտագործելով RW կողպումը: Եվ միևնույն ժամանակ մենք ներմուծեցինք դիսպետչերական և վերարտադրման գործընթացներ:
Բարձր հաճախականությամբ առևտրի ազդեցությունը
Ճարտարապետության վերը նշված տարբերակը գոյություն է ունեցել մինչև 2010 թ. Մինչդեռ մենք այլևս գոհ չէինք HP Superdome սերվերների աշխատանքից։ Բացի այդ, PA-RISC ճարտարապետությունը գործնականում մեռած էր, վաճառողը որևէ նշանակալի թարմացում չի առաջարկել: Արդյունքում մենք սկսեցինք HP UX/PA RISC-ից անցնել Linux/x86: Անցումը սկսվեց մուտքի սերվերների հարմարեցմամբ:
Ինչու՞ ստիպված եղանք նորից փոխել ճարտարապետությունը։ Փաստն այն է, որ բարձր հաճախականությամբ առևտուրը զգալիորեն փոխել է բեռի պրոֆիլը համակարգի միջուկում:
Ենթադրենք, մենք ունենք մի փոքր գործարք, որը զգալի գնային փոփոխություն է առաջացրել՝ ինչ-որ մեկը գնել է կես միլիարդ դոլար։ Մի երկու միլիվայրկյան անց շուկայի բոլոր մասնակիցները նկատում են դա և սկսում են ուղղումներ կատարել։ Բնականաբար, հարցումները շարվում են հսկայական հերթում, որը համակարգը երկար ժամանակ կպահանջի մաքրելու համար:
Այս 50 մվ միջակայքում միջին արագությունը կազմում է վայրկյանում մոտ 16 հազար գործարք: Եթե պատուհանը կրճատենք մինչև 20 մվ, ապա միջին արագությունը կկազմի վայրկյանում 90 հազար գործարք՝ գագաթնակետին 200 հազար գործարքով: Այսինքն՝ բեռը հաստատուն չէ, հանկարծակի պոռթկումներով։ Իսկ հարցումների հերթը միշտ պետք է արագ մշակվի։
Բայց ինչո՞ւ է ընդհանրապես հերթ գոյանում։ Այսպիսով, մեր օրինակում շատ օգտատերեր նկատեցին գնի փոփոխությունը և համապատասխանաբար ուղարկեցին գործարքներ: Նրանք գալիս են Gateway, դրանք սերիականացնում են, որոշակի կարգ են դնում և ուղարկում ցանց։ Երթուղիչները խառնում են փաթեթները և փոխանցում դրանք: Ում փաթեթն առաջինը եկավ, այդ գործարքը «հաղթեց»։ Արդյունքում փոխանակման հաճախորդները սկսեցին նկատել, որ եթե նույն գործարքն ուղարկվում է մի քանի Gateway-ից, ապա դրա արագ մշակման հնարավորությունները մեծանում են: Շուտով փոխանակման ռոբոտները սկսեցին ռմբակոծել Gateway-ը հարցումներով, և գործարքների ավալանշ սկսվեց:
Էվոլյուցիայի նոր փուլ
Լայնածավալ փորձարկումներից և հետազոտություններից հետո մենք անցանք իրական ժամանակի օպերացիոն համակարգի միջուկին: Դրա համար մենք ընտրեցինք RedHat Enterprise MRG Linux-ը, որտեղ MRG նշանակում է իրական ժամանակի հաղորդագրությունների ցանց: Իրական ժամանակի patches-ի առավելությունն այն է, որ դրանք օպտիմիզացնում են համակարգը հնարավորինս արագ կատարման համար. բոլոր գործընթացները շարված են FIFO-ի հերթում, միջուկները կարող են մեկուսացվել, արտահոսքեր չկան, բոլոր գործարքները մշակվում են խիստ հաջորդականությամբ:
Կարմիր - սովորական միջուկում հերթի հետ աշխատելը, կանաչ - իրական ժամանակի միջուկում աշխատելը:
Բայց սովորական սերվերների վրա ցածր հետաձգման հասնելն այնքան էլ հեշտ չէ.
- SMI ռեժիմը, որը x86 ճարտարապետության մեջ հիմք է հանդիսանում կարևոր ծայրամասային սարքերի հետ աշխատելու համար, մեծապես խանգարում է: Բոլոր տեսակի ապարատային իրադարձությունների մշակումը և բաղադրիչների և սարքերի կառավարումն իրականացվում է որոնվածի կողմից, այսպես կոչված, թափանցիկ SMI ռեժիմով, որի դեպքում օպերացիոն համակարգը ընդհանրապես չի տեսնում, թե ինչ է անում որոնվածը: Որպես կանոն, բոլոր խոշոր վաճառողները առաջարկում են հատուկ ընդլայնումներ որոնվածի սերվերների համար, որոնք թույլ են տալիս նվազեցնել SMI-ի մշակման ծավալը:
- Պրոցեսորի հաճախականության դինամիկ հսկողություն չպետք է լինի, դա հանգեցնում է լրացուցիչ պարապուրդի:
- Երբ ֆայլային համակարգի գրանցամատյանը մաքրվում է, միջուկում տեղի են ունենում որոշակի գործընթացներ, որոնք անկանխատեսելի ուշացումներ են առաջացնում:
- Դուք պետք է ուշադրություն դարձնեք այնպիսի բաների, ինչպիսիք են CPU Affinity, Interrupt affinity, NUMA:
Պետք է ասեմ, որ Linux-ի սարքաշարի և միջուկի տեղադրման թեման իրական ժամանակում մշակման համար արժանի է առանձին հոդվածի։ Մենք շատ ժամանակ ծախսեցինք փորձերի և հետազոտությունների վրա, մինչև լավ արդյունքի հասնեինք։
PA-RISC սերվերներից x86 տեղափոխելիս մենք գործնականում ստիպված չենք եղել շատ փոխել համակարգի կոդը, մենք պարզապես հարմարեցրել և վերակազմավորել ենք այն։ Միևնույն ժամանակ մենք շտկեցինք մի քանի սխալներ։ Օրինակ, արագորեն ի հայտ եկան այն փաստի հետևանքները, որ PA RISC-ը մեծ էնդիական համակարգ էր, իսկ x86-ը՝ Փոքր էնդիական համակարգ. օրինակ՝ տվյալները սխալ են կարդացվել: The trickier bug էր, որ PA RISC օգտագործում () հիշողության հասանելիություն, մինչդեռ x86-ը կարող է վերադասավորել կարդալու գործողությունները, այնպես որ մի հարթակում բացարձակապես վավերական ծածկագիրը կոտրվել է մյուս հարթակում:
x86-ին անցնելուց հետո կատարողականը աճել է գրեթե երեք անգամ, գործարքների մշակման միջին ժամանակը նվազել է մինչև 60 մկվ:
Եկեք հիմա ավելի սերտ նայենք, թե ինչ հիմնական փոփոխություններ են կատարվել համակարգի ճարտարապետության մեջ:
Թեժ պահուստային էպոս
Ապրանքային սերվերներին անցնելիս մենք տեղյակ էինք, որ դրանք ավելի քիչ հուսալի են: Հետևաբար, նոր ճարտարապետություն ստեղծելիս մենք ապրիորի ենթադրում էինք մեկ կամ մի քանի հանգույցների ձախողման հնարավորությունը։ Հետևաբար, անհրաժեշտ էր տաք սպասման համակարգ, որը կարող էր շատ արագ անցնել պահեստային մեքենաների:
Բացի այդ, կային նաև այլ պահանջներ.
- Ոչ մի դեպքում չպետք է կորցնեք մշակված գործարքները:
- Համակարգը պետք է բացարձակապես թափանցիկ լինի մեր ենթակառուցվածքների համար։
- Հաճախորդները չպետք է տեսնեն անջատված կապեր:
- Վերապահումները չպետք է նշանակալի ուշացումներ առաջացնեն, քանի որ դա կարևոր գործոն է փոխանակման համար:
Թեժ սպասման համակարգ ստեղծելիս մենք նման սցենարները չենք դիտարկել որպես կրկնակի ձախողումներ (օրինակ, ցանցը մեկ սերվերի վրա դադարել է աշխատել, իսկ հիմնական սերվերը սառել է); չի դիտարկել ծրագրային ապահովման մեջ սխալների հնարավորությունը, քանի որ դրանք հայտնաբերվում են փորձարկման ժամանակ. և հաշվի չի առել սարքավորման սխալ աշխատանքը:
Արդյունքում մենք եկանք հետևյալ սխեմային.
- Հիմնական սերվերը ուղղակիորեն փոխազդեց Gateway սերվերների հետ:
- Հիմնական սերվերի վրա ստացված բոլոր գործարքներն ակնթարթորեն կրկնօրինակվել են պահուստային սերվերին առանձին ալիքի միջոցով: Արբիտրը (նահանգապետը) համակարգել է անցումը, եթե խնդիրներ առաջանան:
- Հիմնական սերվերը մշակել է յուրաքանչյուր գործարք և սպասել է պահուստային սերվերի հաստատմանը: Հապաղումը նվազագույնի հասցնելու համար մենք խուսափեցինք սպասել, որ գործարքը ավարտվի պահուստային սերվերում: Քանի որ այն ժամանակը, որ տևեց գործարքը ցանցով անցնելու համար, համեմատելի էր կատարման ժամանակի հետ, լրացուցիչ ուշացում չի ավելացվել:
- Մենք կարողացանք ստուգել միայն հիմնական և պահուստային սերվերների վերամշակման կարգավիճակը նախորդ գործարքի համար, և ընթացիկ գործարքի մշակման կարգավիճակն անհայտ էր: Քանի որ մենք դեռ օգտագործում էինք մեկ թելային գործընթացներ, Backup-ից պատասխան սպասելը կդանդաղեցներ ամբողջ մշակման հոսքը, ուստի մենք ողջամիտ փոխզիջման գնացինք. մենք ստուգեցինք նախորդ գործարքի արդյունքը:
Սխեման գործել է հետևյալ կերպ.
Ենթադրենք, որ հիմնական սերվերը դադարում է արձագանքել, բայց Gateways-ը շարունակում է շփվել: Պահուստային սերվերի վրա ժամանակի ավարտ է տեղի ունենում, այն կապվում է մարզպետի հետ, որը նրան վերագրում է հիմնական սերվերի դերը, և բոլոր Gateway-ները անցնում են նոր հիմնական սերվերին:
Եթե հիմնական սերվերը վերադառնում է առցանց, այն նաև առաջացնում է ներքին ժամանակի դադարեցում, քանի որ որոշակի ժամանակ Gateway-ից սերվերին զանգեր չեն եղել: Հետո նա նույնպես դիմում է մարզպետին, և նա նրան դուրս է հանում սխեմայից։ Արդյունքում բորսան աշխատում է մեկ սերվերով մինչև առևտրային շրջանի ավարտը։ Քանի որ սերվերի խափանման հավանականությունը բավականին ցածր է, այս սխեման համարվում էր բավականին ընդունելի, այն չէր պարունակում բարդ տրամաբանություն և հեշտ էր փորձարկել:
Շարունակելի
Source: www.habr.com