Саламатсызбы, менин атым Евгений. Мен Yandex.Market издөө инфраструктурасында иштейм. Мен Хабр коомчулугуна Базардын ички ашканасы жөнүндө айткым келет - жана айта турган нерселерим көп. Биринчиден, Базар издөө кандайча иштейт, процесстер жана архитектура. Өзгөчө кырдаалдар менен кантип күрөшөбүз: бир сервер иштебей калса эмне болот? Ушундай 100 сервер болсочы?
Сиз ошондой эле бир нече серверлерде жаңы функцияларды кантип ишке ашырганыбызды үйрөнөсүз. Жана кантип биз татаал кызматтарды түздөн-түз өндүрүштө сынайбыз, колдонуучуларга эч кандай ыңгайсыздык жаратпай. Жалпысынан алганда, ар бир адам жакшы убакыт өткөрүү үчүн Базар издөө кандай иштейт.
Биз жөнүндө бир аз: биз кандай маселени чечебиз
Текстти киргизгенде, продуктту параметрлер боюнча издөөдө же ар кандай дүкөндөрдөгү бааларды салыштырганда, бардык суроо-талаптар издөө кызматына жөнөтүлөт. Издөө - бул базардагы эң чоң кызмат.
Биз бардык издөө өтүнүчтөрүн иштетебиз: market.yandex.ru, beru.ru сайттарынан, Supercheck кызматы, Yandex.Advisor, мобилдик тиркемелер. Биз ошондой эле yandex.ru сайтындагы издөө натыйжаларына продукт сунуштарын киргизебиз.
Издөө кызматы менен мен издөөнүн өзүн эле эмес, ошондой эле Базардагы бардык сунуштар менен маалымат базасын айтып жатам. Масштабы мындай: күнүнө бир миллиарддан ашык издөө сурамдары иштетилет. Жана баары тез, үзгүлтүксүз иштеп, ар дайым каалаган натыйжаны бериши керек.
Бул эмне: Базар архитектурасы
Мен кыскача Базардын учурдагы архитектурасын сүрөттөп берем. Бул болжол менен төмөндөгү диаграмма менен сүрөттөлүшү мүмкүн:
Бизге өнөктөш дүкөн келди дейли. Ал мен оюнчук саткым келет дейт: бул кычыраган мышык. Жана дагы бир ачуусу жок мышык. Жана жөн гана мышык. Андан кийин дүкөн Базар издеген сунуштарды даярдашы керек. Дүкөн сунуштары менен атайын xml түзөт жана өнөктөш интерфейси аркылуу бул xml жолун кабарлайт. Андан кийин индексатор мезгил-мезгили менен бул xml жүктөп алып, каталарды текшерет жана бардык маалыматты чоң маалымат базасына сактайт.
Мындай сакталган xml'лер көп. Бул маалымат базасынан издөө индекси түзүлөт. Индекс ички форматта сакталат. Индекс түзүлгөндөн кийин, Layout кызматы аны издөө серверлерине жүктөйт.
Натыйжада, маалымат базасында кычыраган ачуулуу мышык пайда болот, ал эми серверде мышыктын индекси пайда болот.
Мен сизге издөө архитектурасы боюнча мышыкты кантип издей турганыбызды айтып берем.
Рынок издөө архитектурасы
Биз микросервистердин дүйнөсүндө жашайбыз: ар бир келген суроо көптөгөн субсуроолорду жаратат жана аларды иштетүүгө ондогон кызматтар тартылат. Диаграмма бир нечесин гана көрсөтөт:
Сурамдарды иштетүүнүн жөнөкөйлөштүрүлгөн схемасы
Ар бир кызматтын сонун нерсеси бар - уникалдуу аталышы бар өзүнүн баланстоочусу:
Балансатор бизге кызматты башкарууда көбүрөөк ийкемдүүлүктү берет: сиз, мисалы, жаңыртуулар үчүн талап кылынган серверлерди өчүрө аласыз. Балансатор сервердин жеткиликсиз экенин көрүп, сурамдарды автоматтык түрдө башка серверлерге же маалымат борборлоруна багыттайт. Серверди кошкондо же алып салганда жүк серверлер арасында автоматтык түрдө бөлүштүрүлөт.
Балансты уникалдуу аталышы маалымат борборунан көз каранды эмес. А кызматы Вге суроо-талап кылганда, демейки боюнча баланстоочу В суроону учурдагы маалымат борборуна багыттайт. Эгерде кызмат жеткиликтүү болбосо же учурдагы маалымат борборунда жок болсо, анда суроо-талап башка маалымат борборлоруна багытталат.
Бардык маалымат борборлору үчүн бирдиктүү FQDN А кызматына жайгашкан жерлерден толугу менен абстракциялоого мүмкүндүк берет. Анын В кызматына кайрылуусу ар дайым каралат. Кызмат бардык маалымат борборлорунда жайгашкан учур өзгөчө болуп саналат.
Бирок, бул баланстоочу менен баары ушунчалык кызгылт эмес: бизде кошумча аралык компонент бар. Балансты туруксуз болушу мүмкүн жана бул көйгөй ашыкча серверлер тарабынан чечилет. А жана В кызматтарынын ортосунда дагы кошумча кечигүү бар. Бирок иш жүзүндө ал 1 мсден аз жана көпчүлүк кызматтар үчүн бул өтө маанилүү эмес.
Күтүлбөгөн жагдайлар менен күрөшүү: Издөө кызматынын тең салмактуулугу жана туруктуулугу
Коллапс болуп жатканын элестетиңиз: сиз кычыраган мышыкты табышыңыз керек, бирок сервер бузулат. Же 100 сервер. Кантип чыгуу керек? Биз чын эле колдонуучуну мышыксыз калтырабызбы?
Абал коркунучтуу, бирок биз ага даярбыз. Мен сага ирети менен айтам.
Издөө инфраструктурасы бир нече маалымат борборлорунда жайгашкан:
Долбоорлоодо биз бир маалымат борборун өчүрүү мүмкүнчүлүгүн киргизебиз. Жашоо сюрприздерге бай - мисалы, экскаватор жер астындагы кабелди кесип алат (ооба, ошондой болгон). Калган маалымат борборлорунун кубаттуулугу эң жогорку жүктөмгө туруштук берүүгө жетиштүү болушу керек.
Келгиле, бирдиктүү маалымат борборун карап көрөлү. Ар бир маалымат борборунда бирдей баланстоочу иш схемасы бар:
Бир баланстоочу - кеминде үч физикалык сервер. Бул ашыкча ишенимдүүлүк үчүн жасалган. Балансерлер HAProxте иштешет.
Биз HAProxту анын жогорку өндүрүмдүүлүгүнө, аз ресурстук талаптарга жана кеңири функционалдуулугуна байланыштуу тандап алдык. Биздин издөө программабыз ар бир сервердин ичинде иштейт.
Бир сервердин иштебей калуу ыктымалдыгы төмөн. Бирок, эгерде сизде көп серверлер болсо, жок дегенде бирөө иштебей калуу ыктымалдыгы жогорулайт.
Бул чындыгында болот: серверлер бузулат. Ошондуктан, бардык серверлердин абалын дайыма көзөмөлдөп туруу зарыл. Сервер жооп бербей калса, ал трафиктен автоматтык түрдө ажыратылат. Бул максатта, HAProxy камтылган ден соолук текшерүү бар. Ал бардык серверлерге секундасына бир жолу HTTP сурамы “/ping” менен барат.
HAProxy дагы бир өзгөчөлүгү: агент текшерүү бардык серверлерди бирдей жүктөөгө мүмкүндүк берет. Бул үчүн HAProxy бардык серверлерге кошулат жана алар учурдагы жүктөмгө жараша 1ден 100гө чейин салмагын кайтарып беришет. Салмагы иштетүү үчүн кезекте турган суроо-талаптардын санына жана процессорго жүктөлгөн жүккө жараша эсептелет.
Эми мышыкты табуу жөнүндө. Издөө натыйжалары сыяктуу сурамдарда: /search?text=ачуу+мышык. Издөө тез болушу үчүн, кошка индексинин баары RAMга туура келиши керек. Ал тургай, SSDден окуу жетиштүү ылдам эмес.
Бир жолу, сунуш базасы кичинекей болчу, ал үчүн бир сервердин оперативдүү эс тутуму жетиштүү болчу. Сунуш базасы өскөн сайын бул оперативдик эстутумга баары туура келбейт жана маалыматтар эки бөлүккө бөлүндү: 1 жана 2 сынык.
Бирок бул дайыма болот: кандай гана чечим болбосун, ал тургай жакшы чечим дагы башка көйгөйлөрдү жаратат.
Балансатор дагы эле каалаган серверге кетти. Бирок сураныч келген машинада көрсөткүчтүн жарымы гана болгон. Калганы башка серверлерде болчу. Ошондуктан, сервер кээ бир кошуна машинага барышы керек болчу. Эки серверден маалыматтарды алгандан кийин, натыйжалар бириктирилип, кайрадан рейтингге коюлду.
Балансатор суроо-талаптарды бирдей бөлүштүргөндөн улам, бардык серверлер маалыматтарды жөн эле жөнөтпөстөн, кайра рейтинг менен алектенишкен.
Көйгөй кошуна сервер жеткиликсиз болгондо келип чыккан. Чечим ар кандай артыкчылыктарга ээ болгон бир нече серверлерди “коңшу” сервер катары көрсөтүү болгон. Биринчиден, суроо-талап учурдагы стойкадагы серверлерге жөнөтүлдү. Жооп жок болсо, суроо-талап ушул маалымат борборунун бардык серверлерине жөнөтүлдү. Акыр-аягы, суроо-талап башка маалымат борборлоруна кетти.
Сунуштардын саны өскөн сайын маалыматтар төрт бөлүккө бөлүндү. Бирок бул чек эмес болчу.
Учурда сегиз сыныктан турган конфигурация колдонулууда. Мындан тышкары, көбүрөөк эстутумду үнөмдөө үчүн, индекс издөө бөлүгүнө (издөө үчүн колдонулат) жана үзүндү бөлүгүнө (издөөгө катышпаган) бөлүнгөн.
Бир сервер бир гана сынык үчүн маалыматты камтыйт. Ошондуктан, толук индексти издөө үчүн, ар кандай сыныктарды камтыган сегиз серверден издөө керек.
Серверлер кластерлерге топтоштурулган. Ар бир кластер сегиз издөө системаларын жана бир үзүндү серверди камтыйт.
Фрагмент сервери статикалык маалыматтар менен ачкыч-маанилер базасын иштетет. Алар документтерди берүү үчүн керек, мисалы, мышыктын сыпаттамасы скрипка менен. Издөө серверлеринин эс тутумун жүктөбөш үчүн маалыматтар атайын өзүнчө серверге өткөрүлүп берилет.
Документтин идентификаторлору бир гана индекстин ичинде уникалдуу болгондуктан, үзүндүлөрдөгү документтер жок болгон жагдай пайда болушу мүмкүн. Ооба, же бир ID үчүн ар кандай мазмун болот. Ошондуктан, издөө натыйжалары жана натыйжалары кайтарылышы үчүн, бардык кластер боюнча ырааттуулук зарыл болгон. Мен ырааттуулукту кантип көзөмөлдөй турганыбызды төмөндө айтып берем.
Издөөнүн өзү төмөнкүдөй структураланган: издөө өтүнүчү сегиз сервердин каалаганына келиши мүмкүн. Ал 1-серверге келди дейли. Бул сервер бардык аргументтерди иштеп чыгат жана эмнени жана кантип издөө керектигин түшүнөт. Кирүүчү суроо-талапка жараша сервер керектүү маалымат үчүн тышкы кызматтарга кошумча суроо-талаптарды жасай алат. Бир суроо-талаптын артынан сырткы кызматтарга онго чейин кайрылууга болот.
Керектүү маалыматты чогулткандан кийин сунуштар базасында издөө башталат. Бул үчүн кластердеги бардык сегиз серверге субсуроолор жасалат.
Жооптор алынгандан кийин жыйынтыктар бириктирилет. Акыр-аягы, натыйжаларды түзүү үчүн үзүндү серверине дагы бир нече подсуроолор талап кылынышы мүмкүн.
Кластердин ичиндеги издөө сурамдары төмөнкүдөй көрүнөт: /shard1?text=angry+cat. Мындан тышкары, форманын подсуроолору кластердин ичиндеги бардык серверлердин ортосунда секундасына бир жолу жасалат: /статус.
справка /статус сервер жеткиликтүү эмес кырдаалды аныктайт.
Ал ошондой эле издөө системасынын версиясы жана индекс версиясы бардык серверлерде бирдей экендигин көзөмөлдөйт, антпесе кластердин ичинде дал келбеген маалыматтар болот.
Бир үзүндү сервер сегиз издөө системаларынын суроо-талаптарын иштеткенине карабастан, анын процессору өтө жеңил жүктөлгөн. Ошондуктан, биз азыр үзүндү маалыматтарды өзүнчө кызматка өткөрүп жатабыз.
Маалыматтарды өткөрүү үчүн биз документтер үчүн универсалдуу ачкычтарды киргиздик. Эми башка документтин мазмунун бир ачкыч менен кайтарып берүү мүмкүн эмес.
Бирок башка архитектурага өтүү толук бүтө элек. Эми биз атайын фрагмент серверинен арылгыбыз келет. Анан кластердик структурадан таптакыр алыстагыла. Бул бизге мындан ары да оңой масштабда болууга мүмкүндүк берет. Кошумча бонус олуттуу темир үнөмдөө болуп саналат.
Ал эми азыр бактылуу аягы менен коркунучтуу окуялар. Келгиле, сервердин жетишсиздигинин бир нече учурларын карап көрөлү.
Коркунучтуу бир нерсе болду: бир сервер жеткиликсиз
Бир сервер жеткиликтүү эмес дейли. Андан кийин кластердеги калган серверлер жооп бере алат, бирок издөө натыйжалары толук эмес болуп калат.
Статус текшерүү аркылуу /статус кошуна серверлер бирөө жеткиликтүү эмес экенин түшүнүшөт. Ошондуктан, толуктукту сактоо үчүн, кластердеги бардык серверлер суроо-талабы боюнча /ping алар да жеткиликсиз деп баланстоочуга жооп бере башташат. Көрсө, кластердеги бардык серверлер өлүп калган (бул туура эмес). Бул биздин кластердик схеманын негизги кемчилиги - ошондуктан биз андан алыс болгубуз келет.
Ката менен ишке ашпай калган суроо-талаптар башка серверлердеги баланстоочу тарабынан кайра жөнөтүлөт.
Балансатор ошондой эле өлүк серверлерге колдонуучу трафигин жөнөтүүнү токтотот, бирок алардын абалын текшерүүнү улантат.
Сервер жеткиликтүү болгондо, ал жооп бере баштайт /ping. Өлгөн серверлерден пингдерге кадимки жооптор келе баштаганда, баланстоочулар колдонуучу трафигин ал жакка жөнөтө башташат. Кластердин иши калыбына келтирилди.
Андан да жаманы: көптөгөн серверлер жеткиликсиз
Маалымат борборундагы серверлердин олуттуу бөлүгү кыскартылган. Эмне кылуу керек, кайда качыш керек? Балансатор дагы жардамга келет. Ар бир баланстоочу эстутумда учурдагы серверлердин санын сактап турат. Ал учурдагы маалымат борбору иштете ала турган трафиктин максималдуу көлөмүн дайыма эсептеп турат.
Маалымат борборундагы көптөгөн серверлер иштебей калганда, баланстоочу бул маалымат борбору бардык трафикти иштете албасын түшүнөт.
Андан кийин ашыкча трафик башка маалымат борборлоруна туш келди бөлүштүрүлө баштайт. Баары иштейт, баары бактылуу.
Муну кантип кылабыз: релиздерди басып чыгаруу
Эми кызматка киргизилген өзгөртүүлөрдү кантип жарыялоо жөнүндө сүйлөшөлү. Бул жерде биз процесстерди жөнөкөйлөтүү жолуна өттүк: жаңы релизди чыгаруу дээрлик толугу менен автоматташтырылган.
Долбоордо белгилүү бир сандагы өзгөртүүлөр топтолгондо, жаңы релиз автоматтык түрдө түзүлүп, анын түзүлүшү башталат.
Андан кийин кызмат тестирлөөгө чыгарылат, анда иштөөнүн туруктуулугу текшерилет.
Ошол эле учурда, автоматтык аткаруу тестирлөө ишке киргизилет. Бул атайын кызмат тарабынан ишке ашырылат. Мен азыр бул тууралуу сөз кылбайм - анын сүрөттөлүшү өзүнчө макалага татыктуу.
Эгерде тестирлөөдө жарыялоо ийгиликтүү болсо, релизди алдын ала стабилде жарыялоо автоматтык түрдө башталат. Prestable - бул кадимки колдонуучу трафиги багытталган атайын кластер. Эгер катаны кайтарса, баланстоочу өндүрүшкө кайра суроо салат.
Алдын ала туруктуу режимде жооп берүү убакыттары ченелет жана өндүрүштөгү мурунку чыгарылыш менен салыштырылат. Эгерде баары жакшы болсо, анда адам кошулат: графиктерди жана жүктөмдү текшерүүнүн натыйжаларын текшерип, андан кийин өндүрүшкө чыга баштайт.
Бардык жакшы колдонуучуга кетет: A/B тестирлөө
Кызматка өзгөртүүлөр реалдуу пайда алып келери дайыма эле ачык боло бербейт. Өзгөртүүлөрдүн пайдалуулугун өлчөө үчүн адамдар A/B тестирлөөсүн ойлоп табышты. Мен сизге Yandex.Market издөөсүндө кантип иштээри жөнүндө бир аз айтып берем.
Мунун баары жаңы функцияларды иштеткен жаңы CGI параметрин кошуу менен башталат. Биздин параметр болсун: market_new_functionality=1. Андан кийин коддо желек бар болсо, бул функцияны иштетебиз:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Жаңы функция өндүрүшкө жайылтылууда.
A/B тестирлөө автоматташтыруу үчүн, толук маалымат менен камсыз кылуу үчүн атайын кызмат бар . Кызматта эксперимент түзүлөт. Трафиктин үлүшү, мисалы, 15% белгиленген. Проценттер сурамдар үчүн эмес, колдонуучулар үчүн коюлган. Эксперименттин узактыгы да көрсөтүлөт, мисалы, бир жума.
Бир эле учурда бир нече эксперименттерди жүргүзүүгө болот. Жөндөөлөрдөн сиз башка эксперименттер менен кесилиши мүмкүнбү же жокпу көрсөтө аласыз.
Натыйжада, кызмат автоматтык түрдө аргумент кошот market_new_functionality=1 колдонуучулардын 15% га чейин. Ал ошондой эле тандалган көрсөткүчтөрдү автоматтык түрдө эсептейт. Эксперимент аяктагандан кийин талдоочулар жыйынтыктарды карап, жыйынтык чыгарышат. Жыйынтыктардын негизинде өндүрүшкө чыгаруу же тактоо чечими кабыл алынат.
Рыноктун чебер колу: өндүрүштө сыноо
Көбүнчө өндүрүштө жаңы функциянын иштешин сынап көрүшүңүз керек болот, бирок сиз анын оор жүктө "согуштук" шарттарда өзүн кандай алып барарын билбейсиз.
Чечим бар: CGI параметрлериндеги желектерди A/B тестирлөө үчүн гана эмес, жаңы функцияларды сыноо үчүн да колдонсо болот.
Биз миңдеген серверлердеги конфигурацияны дароо өзгөртүүгө мүмкүндүк берген куралды жасап, кызматты тобокелге салбастан. Ал "Stop Tap" деп аталат. Баштапкы идея макети жок эле кээ бир функцияларды тез өчүрө алуу болгон. Андан кийин курал кеңейип, татаалдашып кетти.
Тейлөө агымынын схемасы төмөндө келтирилген:
Желектин маанилери API аркылуу коюлат. Башкаруу кызматы бул баалуулуктарды маалымат базасында сактайт. Бардык серверлер ар бир он секундада маалымат базасына кирип, желектин маанилерин чыгарып, бул маанилерди ар бир суроого колдонушат.
Токтотуу таптоосунда сиз эки маанинин түрүн орното аласыз:
1) Шарттуу туюнтмалар. Маанилердин бири чын болгондо колдонуңуз. Мисалы:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Сурам DC3 жеринде иштетилгенде "1" мааниси колдонулат. Ал эми суроо-талап beru.ru сайтынын экинчи кластеринде иштетилгенде мааниси "4" болуп саналат.
2) Шартсыз баалуулуктар. Шарттардын бири да аткарылбаса, демейки боюнча колдонуңуз. Мисалы:
баалуулук, баалуулук!
Эгерде маани илеп белгиси менен аяктаса, ага артыкчылык берилет.
CGI параметр талдоочу URL талдоо. Андан кийин Stop Tap маанисин колдонот.
Төмөнкү артыкчылыктарга ээ баалуулуктар колдонулат:
- Stop Tap (илеп белгиси) артыкчылыгы менен.
- Сурамдын мааниси.
- Stop Tap'дан демейки маани.
- Коддогу демейки маани.
Шарттуу маанилерде көрсөтүлгөн көптөгөн желектер бар - алар бизге белгилүү болгон бардык сценарийлер үчүн жетиштүү:
- Маалымат борбору.
- Курчап турган чөйрө: өндүрүш, сыноо, көлөкө.
- Өтчү жери: базар, Беру.
- Кластер номери.
Бул куралдын жардамы менен сиз серверлердин белгилүү бир тобунда жаңы функцияларды иштете аласыз (мисалы, бир гана маалымат борборунда) жана бул функциянын иштешин бүткүл кызмат үчүн өзгөчө коркунучсуз сынай аласыз. Эгер сиз кандайдыр бир жерде олуттуу ката кетирсеңиз да, баары кулай баштады жана бүт маалымат борбору иштебей калды, баланстоочулар суроо-талаптарды башка маалымат борборлоруна багыттайт. Акыркы колдонуучулар эч нерсени байкабайт.
Көйгөйдү байкасаңыз, дароо желектин мурунку маанисине кайтарып алсаңыз болот жана өзгөртүүлөр артка кайтарылат.
Бул кызматтын да терс жактары бар: иштеп чыгуучулар аны абдан жакшы көрүшөт жана көбүнчө бардык өзгөртүүлөрдү Stop Tap баскычына түртүүгө аракет кылышат. Биз туура эмес пайдалануу менен күрөшүүгө аракет кылып жатабыз.
Stop Tap ыкмасы өндүрүшкө жайылтууга даяр туруктуу кодуңуз болгондо жакшы иштейт. Ошол эле учурда, сизде дагы эле шектенүүлөр бар жана сиз кодду "согуштук" шарттарда текшергиңиз келет.
Бирок, Stopcock иштеп чыгуу учурунда сыноо үчүн ылайыктуу эмес. Иштеп чыгуучулар үчүн “көмүскө кластер” деп аталган өзүнчө кластер бар.
Жашыруун тестирлөө: Shadow Cluster
Кластерлердин биринен келген суроо-талаптар көмүскө кластерге кайталанат. Бирок баланстоочу бул кластердин жоопторуна таптакыр көңүл бурбайт. Анын иштөө схемасы төмөндө келтирилген.
Биз чыныгы "согуштук" шарттарда болгон сыноо кластерин алабыз. Кадимки колдонуучу трафик ошол жакка кетет. Эки кластердеги аппараттык камсыздоо бирдей, андыктан аткарууну жана каталарды салыштырууга болот.
Ал эми баланстоочу жоопторду таптакыр этибарга албагандыктан, акыркы колдонуучулар көмүскө кластерден жоопторду көрүшпөйт. Ошондуктан, ката кетирүү коркунучтуу эмес.
табылгалары
Ошентип, биз Базар издөөнү кантип курдук?
Баары ойдогудай болушу үчүн, биз функцияларды өзүнчө кызматтарга бөлөбүз. Ушундай жол менен биз керектүү компоненттерди гана масштабдап, компоненттерди жөнөкөйлөтө алабыз. Башка командага өзүнчө компонентти дайындоо жана анын үстүндө иштөө үчүн жоопкерчиликти бөлүшүү оңой. Жана бул ыкма менен темирди олуттуу үнөмдөө - бул ачык плюс.
Көмүскө кластер дагы бизге жардам берет: биз кызматтарды иштеп чыга алабыз, аларды процессте сынай алабыз жана колдонуучунун тынчын албайбыз.
Албетте, өндүрүштө сыноо. Миңдеген серверлердин конфигурациясын өзгөртүү керекпи? Оңой, Stop Tap колдонуңуз. Ушундай жол менен сиз дароо даяр комплекстүү чечимди чыгарып, көйгөйлөр жаралса, кайра туруктуу версияга кайта аласыз.
Барган сайын өсүп жаткан сунуштар базасы менен Базарды кантип тез жана туруктуу кыла аларыбызды көрсөтө алдым деп үмүттөнөм. Биз сервер көйгөйлөрүн кантип чечебиз, көп сандагы суроо-талаптарды чечебиз, кызматтын ийкемдүүлүгүн жакшыртабыз жана муну жумуш процесстерин үзгүлтүккө учуратпай жасайбыз.
Source: www.habr.com