ВКонтакте үүсгэн байгуулагдсан түүхийг Википедиа дээр байрлуулсан бөгөөд үүнийг Павел өөрөө хэлсэн. Түүнийг хүн бүр мэддэг болсон бололтой. HighLoad++ Pavel дээрх сайтын дотоод засал, архитектур, бүтцийн тухай . Түүнээс хойш олон серверүүд алдагдсан тул бид мэдээллийг шинэчлэх болно: бид үүнийг задалж, дотор талыг нь гаргаж, жинлэж, VK төхөөрөмжийг техникийн үүднээс авч үзэх болно.
Алексей Акулович () ВКонтакте баг дахь арын програмын хөгжүүлэгч. Энэхүү тайлангийн хуулбар нь платформын ажиллагаа, дэд бүтэц, серверүүд болон тэдгээрийн хоорондын харилцан үйлчлэлийн талаар байнга асуудаг асуултуудын хамтын хариулт бөгөөд хөгжүүлэлтийн талаар биш, тухайлбал төмрийн тухай. Тус тусад нь мэдээллийн сан болон VK-д юу байгаа талаар, бүртгэл цуглуулах, бүхэлд нь төслийг бүхэлд нь хянах талаар. Зүсэлтийн доор дэлгэрэнгүй мэдээлэл.
Дөрвөн жил гаруйн турш би арын хэсэгтэй холбоотой бүх төрлийн ажлыг хийж байна.
- Медиа байршуулах, хадгалах, боловсруулах, түгээх: видео, шууд дамжуулалт, аудио, зураг, баримт бичиг.
- Дэд бүтэц, платформ, хөгжүүлэгчийн хяналт, бүртгэл, бүсийн кэш, CDN, өмчийн RPC протокол.
- Гадаад үйлчилгээтэй нэгтгэх: түлхэх мэдэгдэл, гадаад холбоосыг задлах, RSS тэжээл.
- Хариулт нь үл мэдэгдэх код руу шумбахыг шаарддаг янз бүрийн асуултанд хамт ажиллагсаддаа туслах.
Энэ хугацаанд би сайтын олон бүрэлдэхүүн хэсгүүдэд гар бие оролцсон. Би энэ туршлагаа хуваалцахыг хүсч байна.
Ерөнхий архитектур
Ердийнх шиг бүх зүйл хүсэлтийг хүлээн авдаг сервер эсвэл бүлэг серверээс эхэлдэг.
Урд сервер
Урд сервер нь HTTPS, RTMP болон WSS-ээр дамжуулан хүсэлтийг хүлээн авдаг.
HTTPS - Эдгээр нь сайтын үндсэн болон гар утасны вэб хувилбаруудын хүсэлт юм: vk.com болон m.vk.com, мөн манай API-ийн бусад албан ёсны болон албан бус үйлчлүүлэгчид: гар утасны үйлчлүүлэгчид, мессенжерүүд. Бид хүлээн авалттай RTMP- тусдаа урд серверүүдтэй шууд нэвтрүүлгийн урсгал болон WSS- Streaming API-д зориулсан холболтууд.
Сервер дээрх HTTPS болон WSS-ийн хувьд энэ нь үнэ цэнэтэй юм nginx. RTMP нэвтрүүлгүүдийн хувьд бид саяхан өөрсдийн шийдэл рүү шилжсэн киве, гэхдээ энэ нь тайлангийн хамрах хүрээнээс гадуур байна. Гэмтлийг тэсвэрлэхийн тулд эдгээр серверүүд нийтлэг IP хаягуудыг сурталчилж, бүлгээрээ ажилладаг бөгөөд хэрэв серверүүдийн аль нэгэнд асуудал гарвал хэрэглэгчийн хүсэлт алдагдахгүй. HTTPS болон WSS-ийн хувьд эдгээр серверүүд нь CPU-ийн ачааллын нэг хэсгийг өөрсдөө авахын тулд урсгалыг шифрлэдэг.
Бид WSS болон RTMP-ийн талаар цаашид ярихгүй бөгөөд зөвхөн вэб төсөлтэй холбоотой стандарт HTTPS хүсэлтүүдийн талаар ярих болно.
Арын арын хэсэг
Урд талын ард ихэвчлэн арын серверүүд байдаг. Тэд урд серверийн үйлчлүүлэгчдээс хүлээн авсан хүсэлтийг боловсруулдаг.
энэ kPHP серверүүд, HTTP демон ажиллаж байгаа, учир нь HTTPS аль хэдийн шифрлэгдсэн байна. kPHP нь сервер дээр ажилладаг prefork загварууд: мастер процесс, олон тооны хүүхдийн процессыг эхлүүлж, сонсох залгууруудыг тэдэнд дамжуулж, тэд хүсэлтээ боловсруулдаг. Энэ тохиолдолд хэрэглэгчийн хүсэлт бүрийн хооронд процессуудыг дахин эхлүүлэхгүй, харин дахин эхлүүлэхийн оронд хүсэлтийн дараа хүсэлтийн анхны тэг утгын төлөв рүү буцаах болно.
Ачааллын хуваарилалт
Манай бүх арын хэсэг нь ямар ч хүсэлтийг боловсруулах боломжтой машинуудын асар том сан биш юм. Бид тэд тусдаа бүлэгт хуваагдана: ерөнхий, хөдөлгөөнт, api, видео, үе шат ... Тусдаа бүлэг машин дээрх асуудал бусад бүх хүмүүст нөлөөлөхгүй. Видеотой холбоотой асуудал гарсан тохиолдолд хөгжим сонсдог хэрэглэгч асуудлын талаар мэдэхгүй байх болно. Хүсэлтийг аль backend рүү илгээхийг тохиргооны дагуу урд талын nginx шийддэг.
Метрийн цуглуулга ба дахин тэнцвэржүүлэх
Бүлэг бүрт хэдэн машин байх ёстойг ойлгохын тулд бид QPS-д найдах хэрэггүй. Ар тал нь өөр, өөр өөр хүсэлттэй, хүсэлт бүр нь QPS-ийг тооцоолох өөр өөр төвөгтэй байдаг. Тийм учраас бид Бид бүхэлдээ сервер дээрх ачааллын тухай ойлголттой ажилладаг - CPU болон perf дээр.
Бидэнд олон мянган ийм сервер бий. Физик сервер бүр бүх цөмийг дахин боловсруулахын тулд kPHP бүлгийг ажиллуулдаг (учир нь kPHP нь нэг урсгалтай).
Агуулгын сервер
CS эсвэл Content Server нь хадгалах сан юм. CS нь файлуудыг хадгалдаг сервер бөгөөд мөн байршуулсан файлууд болон үндсэн вэб фронтоос түүнд хуваарилдаг бүх төрлийн дэвсгэр синхрон даалгавруудыг боловсруулдаг.
Бидэнд файл хадгалдаг хэдэн арван мянган физик серверүүд бий. Хэрэглэгчид файл байршуулах дуртай бөгөөд бид тэдгээрийг хадгалах, хуваалцах дуртай. Эдгээр серверүүдийн заримыг тусгай pu/pp серверүүд хаадаг.
pu/pp
Хэрэв та VK дээр сүлжээний табыг нээсэн бол та pu/pp-ийг харсан.
pu/pp гэж юу вэ? Хэрэв бид нэг серверийг хаавал хаасан сервер рүү файл байршуулах, татаж авах хоёр сонголт байна. шууд дамжуулан http://cs100500.userapi.com/path буюу завсрын серверээр дамжуулан - http://pu.vk.com/c100500/path.
Pu нь зураг байршуулах түүхэн нэр бөгөөд pp нь фото прокси юм. Өөрөөр хэлбэл, нэг сервер зураг байршуулах, нөгөө сервер нь байршуулах зориулалттай. Одоо зөвхөн зурагнууд ачаалагдсан төдийгүй нэр нь хадгалагдан үлджээ.
Эдгээр серверүүд HTTPS сешнүүдийг дуусгахпроцессорын ачааллыг хадгалах сангаас арилгах. Мөн хэрэглэгчийн файлуудыг эдгээр серверүүд дээр боловсруулдаг тул эдгээр машинууд дээр нууц мэдээлэл бага байх тусмаа сайн. Жишээлбэл, HTTPS шифрлэлтийн түлхүүрүүд.
Машинуудыг манай бусад машинууд хаадаг тул бид тэдэнд "цагаан" гадаад IP өгөхгүй байх боломжтой. "саарал" өгөх. Ингэснээр бид IP санд хэмнэж, машинуудыг гадны хандалтаас хамгаалах баталгаатай болсон - үүнд нэвтрэх IP байхгүй.
Хуваалцсан IP-д тэсвэртэй байдал. Гэмтлийг тэсвэрлэх чадварын хувьд схем нь адилхан ажилладаг - хэд хэдэн физик серверүүд нийтлэг физик IP-тэй байдаг бөгөөд тэдгээрийн урд байгаа техник хангамж нь хүсэлтийг хаашаа илгээхээ сонгодог. Би бусад сонголтуудын талаар дараа ярих болно.
Маргаантай зүйл бол энэ тохиолдолд Үйлчлүүлэгч цөөн тооны холболтыг хадгалдаг. Хэрэв хэд хэдэн машинд ижил IP байгаа бол - ижил хосттой: pu.vk.com эсвэл pp.vk.com, үйлчлүүлэгчийн хөтөч нь нэг хост руу нэгэн зэрэг хүсэлт гаргахад хязгаарлалт тавьдаг. Гэхдээ хаа сайгүй байдаг HTTP/2-ийн үед энэ нь тийм ч их хамааралтай байхаа больсон гэдэгт би итгэж байна.
Схемийн илэрхий сул тал бол үүнийг хийх ёстой явдал юм бүх урсгалыг шахах, өөр серверээр дамжуулан хадгалах сан руу ордог. Бид машинуудаар траффик шахдаг тул ижил схемийг ашиглан видео гэх мэт хүнд ачааллыг шахаж чадахгүй байна. Бид үүнийг шууд дамжуулдаг - тусгайлан видеонд зориулж тусдаа хадгалах зориулалттай тусдаа шууд холболт. Бид проксигоор дамжуулан илүү хөнгөн контентыг дамжуулдаг.
Саяхан бид прокси-ийн сайжруулсан хувилбартай болсон. Тэд жирийн хүмүүсээс юугаараа ялгаатай, яагаад энэ нь хэрэгтэй байгааг би одоо танд хэлэх болно.
Sun
2017 оны XNUMX-р сард өмнө нь Sun-ийг худалдаж авсан Oracle, . Энэ мөчид компани оршин тогтнохоо больсон гэж бид хэлж чадна. Шинэ системийн нэрийг сонгохдоо манай администраторууд энэ компанийн дурсгалд хүндэтгэл үзүүлэхээр шийдэж, шинэ системийг Sun гэж нэрлэсэн. Бид түүнийг зүгээр л "нар" гэж нэрлэдэг.
pp хэд хэдэн асуудалтай байсан. Бүлэг бүрт нэг IP - үр дүнгүй кэш. Хэд хэдэн физик серверүүд нийтлэг IP хаягтай бөгөөд хүсэлт аль сервер рүү очихыг хянах ямар ч арга байхгүй. Тиймээс, хэрэв өөр өөр хэрэглэгчид нэг файлын төлөө ирдэг бол эдгээр серверүүд дээр кэш байгаа бол файл нь сервер бүрийн кэшэд дуусдаг. Энэ бол маш үр ашиггүй схем боловч юу ч хийж чадахгүй.
Үүний үр дүнд - Бид агуулгыг хувааж чадахгүй, учир нь бид энэ бүлэгт тусгай сервер сонгох боломжгүй - тэд нийтлэг IP-тэй. Мөн зарим дотоод шалтгааны улмаас бидэнд бий бүс нутагт ийм сервер суулгах боломжгүй байсан. Тэд зөвхөн Санкт-Петербургт зогсож байсан.
Нартай хамт бид сонгон шалгаруулах системийг өөрчилсөн. Одоо бидэнд байна anycast чиглүүлэлт: динамик чиглүүлэлт, дурын дамжуулалт, өөрийгөө шалгах демон. Сервер бүр өөрийн гэсэн IP-тэй боловч нийтлэг дэд сүлжээтэй. Бүх зүйл нэг сервер ажиллахаа больсон тохиолдолд траффик нь ижил бүлгийн бусад серверүүдэд автоматаар тархах байдлаар тохируулагдсан байдаг. Одоо тодорхой сервер сонгох боломжтой. нэмэлт кэш хийхгүй, найдвартай байдалд нөлөөлөөгүй.
Жингийн дэмжлэг. Одоо бид шаардлагатай бол өөр өөр чадалтай машин суурилуулах, мөн түр зуурын асуудал гарсан тохиолдолд ачааллыг багасгахын тулд ажиллаж буй "нар" -ын жинг өөрчлөх, ингэснээр тэд "амарч" дахин ажиллаж эхэлнэ.
Агуулгын id-ээр хуваах. Хуваалцах тухай инээдтэй зүйл: бид ихэвчлэн агуулгыг хуваадаг бөгөөд ингэснээр өөр өөр хэрэглэгчид ижил "нараар" нэг файл руу ордог бөгөөд ингэснээр тэд нийтлэг кэштэй болно.
Бид саяхан “Хошоонгор” аппликейшнийг гаргасан. Энэ бол шууд нэвтрүүлгийн онлайн асуулт хариулт бөгөөд хөтлөгч асуулт асууж, хэрэглэгчид бодит цаг хугацаанд хариулт өгч, сонголтуудыг сонгох явдал юм. Энэхүү програм нь хэрэглэгчид чатлах боломжтой чаттай. Нэвтрүүлэгт нэгэн зэрэг холбогдох боломжтой 100 мянга гаруй хүн. Тэд бүгд бүх оролцогчдод илгээсэн мессеж бичдэг бөгөөд мессежийн хамт аватар ирдэг. Нэг "нар"-д 100 мянган хүн нэг аватар авах гэж ирдэг бол заримдаа үүлний ард эргэлдэж болно.
Ижил файлын хүсэлтийг тэсвэрлэхийн тулд бид тодорхой төрлийн контентод зориулж тухайн бүс нутагт байгаа бүх "нар"-д файлуудыг тараах тэнэг схемийг асаадаг.
Дотор талаас нь нар
Nginx дээрх урвуу прокси, RAM эсвэл хурдан Optane/NVMe диск дээр кэш хийх. Жишээ: http://sun4-2.userapi.com/c100500/path - дөрөв дэх бүс нутаг, хоёр дахь серверийн бүлэгт байрлах "нар"-ын холбоос. Энэ нь 100500 сервер дээр байрладаг замын файлыг хаадаг.
хамгаалах
Бид архитектурын схемд дахин нэг зангилаа нэмж оруулав - кэш орчин.
Байршлын диаграммыг доор харуулав бүс нутгийн кэш, тэдгээрийн 20 орчим нь байдаг. Эдгээр нь кэш болон "нар" байрладаг газрууд бөгөөд тэдгээр нь урсгалыг өөрсдөө дамжуулан кэш болгож чаддаг.
Энэ бол мультимедиа контентыг кэшлэх явдал бөгөөд энд хэрэглэгчийн мэдээлэл хадгалагдахгүй - зөвхөн хөгжим, видео, зураг.
Хэрэглэгчийн бүсийг тодорхойлохын тулд бид Бид бүс нутагт зарласан BGP сүлжээний угтваруудыг цуглуулдаг. Буцах тохиолдолд бид IP-г угтвараар олж чадаагүй бол geoip мэдээллийн санг задлан шинжлэх хэрэгтэй. Бид тухайн бүсийг хэрэглэгчийн IP-ээр тодорхойлдог. Кодоор бид хэрэглэгчийн нэг буюу хэд хэдэн бүсийг буюу газарзүйн хувьд хамгийн ойр байгаа цэгүүдийг харж болно.
энэ нь хэрхэн ажилладаг вэ?
Бид файлуудын алдар нэрийг бүс нутгаар нь тооцдог. Хэрэглэгчийн байрладаг бүс нутгийн кэшийн дугаар, файлын танигч байдаг - бид энэ хосыг авч, татаж авах бүрт үнэлгээг нэмэгдүүлдэг.
Үүний зэрэгцээ, чөтгөрүүд - бүс нутгийн үйлчилгээнүүд - үе үе API руу ирж: "Би ийм ийм кэш байна, миний бүс нутагт байгаа хамгийн алдартай файлуудын жагсаалтыг надад хараахан өгөөгүй байна. ” API нь олон тооны файлуудыг үнэлгээгээр эрэмбэлсэн бөгөөд демон нь татаж аваад, бүс нутгууд руу аваачиж, тэндээс файлуудыг хүргэдэг. Энэ нь pu/pp болон Sun хоёрын кэшээс үндсэн ялгаа юм: тэдгээр нь кэшэд байхгүй байсан ч файлыг шууд өөрсдөө дамжуулдаг бөгөөд кэш эхлээд файлыг өөртөө татаж аваад дараа нь буцааж өгч эхэлдэг.
Энэ тохиолдолд бид авдаг хэрэглэгчдэд илүү ойр контент болон сүлжээний ачааллыг түгээх. Жишээлбэл, зөвхөн Москвагийн кэшээс бид оргил ачааллын үед 1 Tbit / s-ээс илүү түгээдэг.
Гэхдээ асуудал байна - кэш серверүүд нь резин биш. Маш алдартай контентын хувьд заримдаа тусдаа серверт хангалттай сүлжээ байдаггүй. Манай кэш серверүүд 40-50 Гбит/с хурдтай байдаг ч ийм сувгийг бүрмөсөн хаадаг контент байдаг. Бид бүс нутагт алдартай файлуудын нэгээс илүү хувийг хадгалахыг хэрэгжүүлэхээр ажиллаж байна. Оны эцэс гэхэд хэрэгжүүлнэ гэж найдаж байна.
Бид ерөнхий архитектурыг харлаа.
- Хүсэлтийг хүлээн авдаг урд серверүүд.
- Хүсэлтийг боловсруулдаг backends.
- Хоёр төрлийн проксигээр хаагдсан хадгалалтууд.
- Бүс нутгийн кэш.
Энэ диаграмд юу дутагдаж байна вэ? Мэдээжийн хэрэг, бидний өгөгдөл хадгалдаг мэдээллийн сан.
Өгөгдлийн сан эсвэл хөдөлгүүр
Бид тэдгээрийг мэдээллийн сан биш, харин хөдөлгүүр гэж нэрлэдэг - Хөдөлгүүр, учир нь бидэнд нийтээр хүлээн зөвшөөрөгдсөн утгаараа мэдээллийн сан бараг байдаггүй.
Энэ бол зайлшгүй шаардлагатай арга хэмжээ юм. Энэ нь 2008-2009 онд VK-ийн нэр хүнд огцом өсч байх үед уг төсөл бүхэлдээ MySQL болон Memcache дээр ажиллаж, асуудал гарсантай холбоотой юм. MySQL файлуудыг сүйрүүлж, гэмтээх дуртай байсан бөгөөд дараа нь сэргээгдэхгүй байсан тул Memcache-ийн гүйцэтгэл аажмаар буурч, дахин эхлүүлэх шаардлагатай болсон.
Энэ нь улам бүр түгээмэл болж байгаа төсөл нь өгөгдлийг гэмтээдэг байнгын хадгалалт, удаашруулдаг кэштэй байсан нь харагдаж байна. Ийм нөхцөлд өсөн нэмэгдэж буй төсөл боловсруулахад хэцүү байдаг. Төслийн гол анхаарлаа хандуулсан чухал зүйлсийг өөрсдийн дугуйн дээр дахин бичихээр шийдсэн.
Шийдэл амжилттай болсон. Үүнийг хийх боломж байсан бөгөөд нэн шаардлагатай байсан, учир нь тэр үед масштаблах өөр арга байхгүй байсан. Цөөн тооны мэдээллийн сан байгаагүй, NoSQL хараахан байгаагүй, зөвхөн MySQL, Memcache, PostrgreSQL л байсан - тэгээд л болоо.
Бүх нийтийн ажиллагаа. Энэхүү хөгжүүлэлтийг манай С хөгжүүлэгчдийн баг удирдсан бөгөөд бүх зүйл тууштай хийгдсэн. Хөдөлгүүрээс үл хамааран тэд бүгд дискэнд бичигдсэн файлын форматтай, ижил эхлүүлэх параметрүүдтэй, дохиог ижил аргаар боловсруулж, захын нөхцөл байдал, асуудал гарсан тохиолдолд ойролцоогоор ижил үйлдэл хийдэг. Хөдөлгүүрүүд нэмэгдэж байгаа тул администраторуудад системийг ажиллуулах нь тохиромжтой болсон - засвар үйлчилгээ хийх шаардлагатай амьтны хүрээлэн байхгүй бөгөөд тэд гуравдагч талын шинэ мэдээллийн сан бүрийг хэрхэн ажиллуулах талаар дахин суралцах шаардлагатай болсон нь хурдан бөгөөд хурдан ажиллах боломжтой болсон. тэдний тоог хялбархан нэмэгдүүлэх.
Хөдөлгүүрийн төрлүүд
Баг нь нэлээд хэдэн хөдөлгүүр бичсэн. Тэдгээрийн заримыг нь дурдвал: найз, зөвлөмж, зураг, ipdb, захидал, жагсаалт, бүртгэл, memcached, meowdb, мэдээ, nostradamus, гэрэл зураг, тоглуулах жагсаалт, pmemcached, хамгаалагдсан хязгаарлагдмал орчин, хайлт, хадгалалт, дуртай зүйлс, даалгавар, ...
Тодорхой өгөгдлийн бүтэц шаарддаг эсвэл ердийн бус хүсэлтийг боловсруулах ажил бүрийн хувьд C баг шинэ хөдөлгүүр бичдэг. Яагаад үгүй гэж.
Бид тусдаа хөдөлгүүртэй memcached, энэ нь ердийнхтэй төстэй, гэхдээ олон сайхан зүйлстэй, хурдаа сааруулдаггүй. ClickHouse биш, гэхдээ бас ажилладаг. Тус тусад нь авах боломжтой pmemcached Байна уу байнгын санах ойд хадгалагдсан, энэ нь RAM-д багтахаас гадна өгөгдлийг дискэн дээр хадгалах боломжтой бөгөөд ингэснээр дахин эхлүүлэх үед өгөгдлийг алдахгүй байх болно. Хувь хүний даалгаврын хувьд янз бүрийн хөдөлгүүрүүд байдаг: дараалал, жагсаалт, багц - бидний төсөлд шаардагдах бүх зүйл.
Кластерууд
Кодын үүднээс авч үзвэл хөдөлгүүр эсвэл мэдээллийн санг процесс, аж ахуйн нэгж эсвэл инстанц гэж үзэх шаардлагагүй. Код нь кластерууд, бүлэг хөдөлгүүрүүдтэй тусгайлан ажилладаг. кластер бүрт нэг төрөл. Memcached кластер байна гэж бодъё - энэ бол зүгээр л нэг бүлэг машин юм.
Код нь серверийн физик байршил, хэмжээ, тоог огт мэдэх шаардлагагүй. Тэрээр тодорхой танигч ашиглан кластерт очдог.
Үүнийг ажиллуулахын тулд та код болон хөдөлгүүрүүдийн хооронд байрлах өөр нэг нэгжийг нэмэх хэрэгтэй - прокси.
RPC прокси
Прокси холбосон автобус, үүн дээр бараг бүх сайт ажилладаг. Үүний зэрэгцээ бидэнд байна үйлчилгээний нээлт байхгүй — үүний оронд энэ проксид зориулсан тохиргоо байдаг бөгөөд энэ нь кластерын бүх кластер болон бүх хэлтэрхийнүүдийн байршлыг мэддэг. Үүнийг админууд хийдэг.
Программистууд хэр их, хаана, ямар үнэтэй байх нь огт хамаагүй - тэд зүгээр л кластер руу явдаг. Энэ нь бидэнд маш их боломжийг олгодог. Хүсэлтийг хүлээн авахдаа прокси нь хүсэлтийг хаана байгааг мэдэж, хүсэлтийг дахин чиглүүлдэг - энэ нь өөрөө үүнийг тодорхойлдог.
Энэ тохиолдолд прокси нь үйлчилгээний доголдлоос хамгаалах цэг юм. Хэрэв зарим хөдөлгүүр удаашрах эсвэл гацах тохиолдолд прокси үүнийг ойлгож, үйлчлүүлэгчийн талд хариу үйлдэл үзүүлдэг. Энэ нь танд завсарлага арилгах боломжийг олгодог - код нь хөдөлгүүр хариу өгөхийг хүлээхгүй, гэхдээ энэ нь ажиллахгүй байгаа бөгөөд ямар нэгэн байдлаар өөрөөр ажиллах шаардлагатай гэдгийг ойлгодог. Мэдээллийн сан үргэлж ажилладаггүй тул кодыг бэлтгэх ёстой.
Тодорхой хэрэгжилт
Заримдаа бид хөдөлгүүрийн хувьд ямар нэгэн стандарт бус шийдэлтэй байхыг үнэхээр хүсч байна. Үүний зэрэгцээ, манай хөдөлгүүрт тусгайлан бүтээсэн бэлэн rpc-proxy-г ашиглахгүй байхаар шийдсэн, харин даалгаварт тусдаа прокси хийхээр шийдсэн.
Энд тэнд байсаар байгаа MySQL-ийн хувьд бид db-proxy ашигладаг бол ClickHouse-д - Зулзангийн байшин.
Энэ нь ерөнхийдөө ийм байдлаар ажилладаг. Тодорхой сервер байдаг, энэ нь kPHP, Go, Python ажилладаг - ерөнхийдөө манай RPC протоколыг ашиглаж болох аливаа код. Код нь RPC прокси дээр локал байдлаар ажилладаг - код байрладаг сервер бүр өөрийн локал прокси ажиллуулдаг. Хүсэлтийн дагуу прокси хаашаа явахаа ойлгодог.
Хэрвээ нэг хөдөлгүүр нөгөө рүүгээ шилжихийг хүсвэл хөрш байсан ч энэ нь проксигоор дамждаг, учир нь хөрш нь өөр мэдээллийн төвд байж болно. Хөдөлгүүр нь өөрөөсөө өөр зүйлийн байршлыг мэдэхэд найдах ёсгүй - энэ бол бидний стандарт шийдэл юм. Гэхдээ мэдээжийн хэрэг үл хамаарах зүйлүүд байдаг :)
Бүх хөдөлгүүрүүд ажилладаг TL схемийн жишээ.
memcache.not_found = memcache.Value;
memcache.strvalue value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;
tasks.task
fields_mask:#
flags:int
tag:%(Vector int)
data:string
id:fields_mask.0?long
retries:fields_mask.1?int
scheduled_time:fields_mask.2?int
deadline:fields_mask.3?int
= tasks.Task;
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;Энэ бол хоёртын протокол бөгөөд хамгийн ойрын аналог нь юм протобуф. Уг схем нь нэмэлт талбарууд, цогц төрлүүд - суурилуулсан скалярын өргөтгөлүүд, асуулга зэргийг урьдчилан тодорхойлсон. Бүх зүйл энэ протоколын дагуу ажилладаг.
RPC TCP/UDP дээр TL гаруй... UDP?
Бид TL схем дээр ажилладаг хөдөлгүүрийн хүсэлтийг гүйцэтгэх RPC протоколтой. Энэ бүхэн TCP/UDP холболтоор ажилладаг. TCP нь ойлгомжтой, гэхдээ бидэнд UDP яагаад байнга хэрэгтэй байдаг вэ?
UDP тусалдаг серверүүдийн хооронд асар олон тооны холболтын асуудлаас зайлсхийх. Хэрэв сервер бүр RPC прокситэй бөгөөд ерөнхийдөө ямар ч хөдөлгүүрт очиж чаддаг бол сервер бүрт хэдэн арван мянган TCP холболт байдаг. Ачаалал байгаа ч нэмэргүй. UDP-ийн хувьд энэ асуудал байхгүй.
Илүүдэл TCP гар барихгүй. Энэ бол ердийн асуудал юм: шинэ хөдөлгүүр эсвэл шинэ сервер ажиллуулахад олон TCP холболтууд нэг дор үүсдэг. Жижиг хэмжээний хүсэлтийн хувьд, жишээлбэл, UDP ачааллын хувьд код болон хөдөлгүүрийн хоорондох бүх харилцаа холбоо байдаг хоёр UDP пакет: нэг нь нэг чиглэлд нисдэг, хоёр дахь нь нөгөө талдаа. Нэг дугуй аялал - код нь гар барихгүйгээр хөдөлгүүрээс хариу хүлээн авсан.
Тийм ээ, энэ бүхэн зүгээр л ажилладаг пакет алдагдлын маш бага хувьтай. Протокол нь дахин дамжуулалт, хугацаа дуусахад дэмжлэг үзүүлдэг боловч хэрэв бид маш их алдвал бид бараг TCP авах болно, энэ нь ашиггүй юм. Бид далай дээгүүр UDP жолооддоггүй.
Бидэнд олон мянган ийм серверүүд байгаа бөгөөд схем нь адилхан: физик сервер бүр дээр багц хөдөлгүүр суулгасан. Тэдгээрийг блоклохгүйгээр аль болох хурдан ажиллуулахын тулд ихэвчлэн нэг урсгалтай байдаг бөгөөд нэг урсгалтай шийдэл болгон хуваасан байдаг. Үүний зэрэгцээ, бидэнд эдгээр хөдөлгүүрээс илүү найдвартай зүйл байхгүй бөгөөд өгөгдөл хадгалахад ихээхэн анхаарал хандуулдаг.
Байнгын өгөгдөл хадгалах
Хөдөлгүүрүүд бинлог бичдэг. Бинлог нь төлөв эсвэл өгөгдлийн өөрчлөлтийн үйл явдлыг төгсгөлд нь нэмдэг файл юм. Өөр өөр шийдлүүдэд үүнийг өөрөөр нэрлэдэг: хоёртын бүртгэл, , , гэхдээ зарчим нь адилхан.
Хөдөлгүүрийг дахин асаахад олон жилийн турш бүхэл бүтэн бинлогийг дахин уншихаас сэргийлэхийн тулд хөдөлгүүрүүд бичдэг агшин зуурын зураг - одоогийн байдал. Шаардлагатай бол тэд эхлээд түүнээс уншиж, дараа нь бинлогоос уншиж дуусгадаг. Бүх бинлогууд нь TL схемийн дагуу ижил хоёртын форматаар бичигдсэн байдаг бөгөөд ингэснээр админууд өөрсдийн хэрэглүүрүүдийг ашиглан тэдгээрийг адилхан удирдах боломжтой болно. Ийм агшин зуурын зураг авах шаардлагагүй. Хэний хормын хувилбар int, хөдөлгүүрийн ид шид, аль бие нь хэнд ч чухал биш гэдгийг харуулсан ерөнхий толгой хэсэг байдаг. Энэ нь агшин зуурын зургийг бичсэн хөдөлгүүртэй холбоотой асуудал юм.
Би үйл ажиллагааны зарчмыг хурдан тайлбарлах болно. Хөдөлгүүр ажилладаг сервер байдаг. Тэрээр бичихийн тулд шинэ хоосон бинлог нээж, түүнийг өөрчлөх үйл явдал бичдэг.
Хэзээ нэгэн цагт тэр өөрөө агшин зуурын зураг авахаар шийддэг, эсвэл дохио хүлээн авдаг. Сервер нь шинэ файл үүсгэж, түүний төлөвийг бүхэлд нь бичиж, файлын төгсгөлд одоогийн бинлог хэмжээг - офсет - хавсаргаж, цааш үргэлжлүүлэн бичнэ. Шинэ бинлог үүсгэгдээгүй байна.
Хэзээ нэгэн цагт хөдөлгүүр дахин асах үед диск дээр бинлог болон хормын хувилбар хоёулаа байх болно. Хөдөлгүүр нь агшин зуурын зургийг бүхэлд нь уншиж, тодорхой цэг дээр төлөвөө өсгөдөг.
Хормын хувилбарыг үүсгэх үед байсан байрлал болон бинлогын хэмжээг уншина.
Одоогийн төлөвийг авахын тулд бинлогийн төгсгөлийг уншиж, цаашдын үйл явдлуудыг үргэлжлүүлэн бичнэ. Энэ бол энгийн схем бөгөөд бидний бүх хөдөлгүүрүүд үүний дагуу ажилладаг.
Өгөгдлийн хуулбар
Үүний үр дүнд манай дахь өгөгдлийг хуулбарлах мэдэгдэлд суурилсан - бид бинлог дээр хуудасны өөрчлөлтийг бичдэггүй, гэхдээ тухайлбал хүсэлтийг өөрчлөх. Сүлжээгээр дамждаг зүйлтэй маш төстэй, зөвхөн бага зэрэг өөрчлөгдсөн.
Үүнтэй ижил схемийг зөвхөн хуулбарлахад төдийгүй бас ашигладаг нөөцлөлт үүсгэх. Бидэнд хөдөлгүүр бий - бинлог руу бичдэг бичгийн мастер. Админууд үүнийг тохируулсан өөр аль ч газарт энэ бинлогийг хуулж авдаг, тэгээд л болоо - бидэнд нөөцлөлт бий.
Хэрэв шаардлагатай бол хуулбарыг уншихCPU-ийн унших ачааллыг багасгахын тулд унших хөдөлгүүрийг зүгээр л ажиллуулдаг бөгөөд энэ нь бинлогийн төгсгөлийг уншиж, эдгээр командуудыг дотооддоо гүйцэтгэдэг.
Энд байгаа хоцролт нь маш бага бөгөөд хуулбар нь мастераас хэр хоцорч байгааг олж мэдэх боломжтой.
RPC прокси дахь өгөгдөл хуваах
Sharding хэрхэн ажилладаг вэ? Прокси нь аль кластерын хэлтэрхий рүү илгээхийг яаж ойлгох вэ? Код нь: "15 хэлтэрхий илгээ!" гэж бичээгүй байна. - Үгүй ээ, үүнийг прокси хийдэг.
Хамгийн энгийн схем бол firstint юм - хүсэлтийн эхний дугаар.
get(photo100_500) => 100 % N.
Энэ бол энгийн memcached текст протоколын жишээ боловч мэдээжийн хэрэг асуулга нь нарийн төвөгтэй, бүтэцтэй байж болно. Жишээ нь асуулгын эхний тоог, кластерын хэмжээгээр хуваах үед үлдсэн тоог авна.
Энэ нь бид нэг аж ахуйн нэгжийн өгөгдлийн байршилтай байхыг хүссэн үед хэрэг болно. 100 нь хэрэглэгч эсвэл бүлгийн ID гэж бодъё, бид нэг аж ахуйн нэгжийн бүх өгөгдлийг нарийн төвөгтэй асуулгад зориулж нэг хэсэг дээр байлгахыг хүсч байна.
Хүсэлтүүд кластер даяар хэрхэн тархах нь бидэнд хамаагүй бол өөр сонголт бий - хэлтэрхийг бүхэлд нь хэшлэх.
hash(photo100_500) => 3539886280 % N
Мөн бид хэш, хуваалтын үлдэгдэл, хэлтэрхий дугаарыг авдаг.
Хэрэв бид кластерын хэмжээг нэмэгдүүлэхдээ үүнийг хуваах эсвэл хэд хэдэн удаа нэмэгдүүлэхэд бэлэн байгаа тохиолдолд л эдгээр хоёр сонголт ажиллах болно. Жишээлбэл, бидэнд 16 хэлтэрхий байсан, бидэнд хангалттай биш, бид илүү ихийг хүсч байна - бид 32-ыг зогсолтгүй авах боломжтой. Хэрэв бид үржүүлэх биш нэмэгдүүлэхийг хүсвэл сул зогсолт гарах болно, учир нь бид бүх зүйлийг алдагдалгүйгээр нарийвчлан хувааж чадахгүй. Эдгээр сонголтууд нь ашигтай боловч үргэлж биш юм.
Хэрэв бид дурын тооны сервер нэмэх эсвэл хасах шаардлагатай бол бид ашигладаг Ла Кетама бөгж дээр тууштай хэш хийх. Гэхдээ үүнтэй зэрэгцэн бид өгөгдлийн байршлыг бүрэн алддаг; бид хүсэлтийг кластерт нэгтгэх ёстой бөгөөд ингэснээр хэсэг бүр өөрийн гэсэн жижиг хариултыг буцаана, дараа нь прокси руу хариултуудыг нэгтгэнэ.
Маш тодорхой хүсэлтүүд байдаг. Энэ нь иймэрхүү харагдаж байна: RPC прокси нь хүсэлтийг хүлээн авч, аль кластер руу очихыг тодорхойлж, хэлтэрхийг тодорхойлно. Дараа нь бичих мастерууд байдаг, эсвэл кластер нь хуулбарлах дэмжлэгтэй бол хүсэлтээр хуулбар руу илгээдэг. Прокси энэ бүгдийг хийдэг.
Бүртгэл
Бид бүртгэлийг хэд хэдэн аргаар бичдэг. Хамгийн ойлгомжтой бөгөөд энгийн нь memcache руу бүртгэл бичих.
ring-buffer: prefix.idx = line
Түлхүүр угтвар байдаг - бүртгэлийн нэр, мөр, энэ бүртгэлийн хэмжээ байдаг - мөрийн тоо. Бид 0-ээс 1-ийг хассан мөрүүдийн тоог санамсаргүй тоогоор авдаг. Memcache дахь түлхүүр нь энэ санамсаргүй тоотой холбосон угтвар юм. Бид бүртгэлийн мөр болон одоогийн цагийг утгад хадгалдаг.
Бүртгэлийг унших шаардлагатай бол бид үүнийг хийдэг Олон авах бүх түлхүүрүүдийг цаг хугацаагаар нь ангилж, бодит цаг хугацаанд үйлдвэрлэлийн бүртгэлийг авах. Энэ схемийг та бодит цаг хугацаанд үйлдвэрлэлд ямар нэгэн зүйлийг дибаг хийх шаардлагатай үед юу ч эвдэхгүй, зогсолтгүй эсвэл бусад машин руу урсгалыг зөвшөөрөхгүй бол ашигладаг боловч энэ бүртгэл удаан үргэлжлэхгүй.
Бүртгэлийг найдвартай хадгалахын тулд бид хөдөлгүүртэй лог-хөдөлгүүр. Чухам ийм учраас үүнийг бүтээсэн бөгөөд асар олон тооны кластерт өргөн хэрэглэгддэг. Миний мэдэх хамгийн том кластер нь 600 TB савласан гуалин хадгалдаг.
Хөдөлгүүр нь маш хуучин, аль хэдийн 6-7 настай кластерууд байдаг. Үүнтэй холбоотой асуудлууд байгаа бөгөөд бид үүнийг шийдвэрлэх гэж оролдож байна, жишээлбэл, бид лог хадгалахын тулд ClickHouse-г идэвхтэй ашиглаж эхэлсэн.
ClickHouse-д бүртгэл цуглуулж байна
Энэ диаграм нь бидний хөдөлгүүрт хэрхэн орж байгааг харуулж байна.
Орон нутагт RPC-ээр дамжуулан RPC-прокси руу шилжих код байдаг бөгөөд энэ нь хөдөлгүүр рүү хаашаа орохыг ойлгодог. Хэрэв бид ClickHouse дээр лог бичихийг хүсвэл энэ схемийн хоёр хэсгийг өөрчлөх шаардлагатай.
- зарим хөдөлгүүрийг ClickHouse-ээр солих;
- ClickHouse-д хандаж чадахгүй байгаа RPC прокси-г RPC-ээр дамжуулан боломжтой шийдлээр солих.
Хөдөлгүүр нь энгийн - бид үүнийг сервер эсвэл ClickHouse-тэй серверийн кластераар сольдог.
ClickHouse руу очихын тулд бид хийсэн KittenHouse. Хэрэв бид KittenHouse-аас ClickHouse руу шууд очвол үүнийг даван туулахгүй. Хүсэлтгүйгээр ч гэсэн энэ нь маш олон тооны машинуудын HTTP холболтоос нэмэгддэг. Схемийг ClickHouse бүхий сервер дээр ажиллуулахын тулд орон нутгийн урвуу прокси нэмэгдсэн байна, энэ нь шаардлагатай хэмжээний холболтыг тэсвэрлэхуйц байдлаар бичигдсэн байдаг. Энэ нь мөн өөрийн доторх өгөгдлийг харьцангуй найдвартай буфер болгож чадна.
Заримдаа бид RPC схемийг стандарт бус шийдлүүдэд, жишээлбэл, nginx дээр хэрэгжүүлэхийг хүсдэггүй. Тиймээс KittenHouse нь UDP-ээр дамжуулан лог хүлээн авах чадвартай.
Хэрэв лог илгээгч болон хүлээн авагч нь нэг машин дээр ажилладаг бол локал хост доторх UDP пакетийг алдах магадлал маш бага байна. Гуравдагч этгээдийн шийдэлд RPC-ийг хэрэгжүүлэх хэрэгцээ болон найдвартай байдлын хооронд буулт хийх үүднээс бид зүгээр л UDP илгээхийг ашигладаг. Бид дараа нь энэ схемд буцаж очих болно.
Хяналт шинжилгээ
Бидэнд хоёр төрлийн лог байдаг: администраторууд сервер дээрээ цуглуулдаг болон хөгжүүлэгчдийн кодоор бичсэн бүртгэлүүд. Эдгээр нь хоёр төрлийн хэмжигдэхүүнтэй тохирч байна: систем ба бүтээгдэхүүн.
Системийн хэмжүүрүүд
Энэ нь манай бүх сервер дээр ажилладаг , статистик мэдээллийг цуглуулж, илгээдэг Графит нүүрстөрөгч. Тиймээс ClickHouse-г жишээлбэл Whisper биш, харин хадгалах систем болгон ашигладаг. Шаардлагатай бол ClickHouse-аас шууд уншиж болно, эсвэл ашиглаж болно Графана хэмжигдэхүүн, график, тайлангийн хувьд. Хөгжүүлэгчийн хувьд бид Netdata болон Grafana-д хангалттай нэвтрэх боломжтой.
Бүтээгдэхүүний хэмжүүр
Тохиромжтой болгох үүднээс бид маш олон зүйлийг бичсэн. Жишээлбэл, Counts, UniqueCounts утгуудыг статистик болгон бичих боломжийг олгодог энгийн функцуудын багц байдаг бөгөөд тэдгээрийг хаа нэг газар илгээдэг.
statlogsCountEvent ( ‘stat_name’, $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid, $key1, $key2, …)
statlogsValuetEvent ( ‘stat_name’, $value, $key1, $key2, …)
$stats = statlogsStatData($params)
Дараа нь бид ангилах, бүлэглэх шүүлтүүрийг ашиглаж, статистик мэдээллээс хүссэн бүх зүйлээ хийх боломжтой - график бүтээх, Watchdogs-ийг тохируулах.
Бид маш их бичдэг олон хэмжүүр үйл явдлын тоо өдөрт 600 тэрбумаас 1 их наяд хүртэл байдаг. Гэсэн хэдий ч бид тэдгээрийг хадгалахыг хүсч байна дор хаяж хоёр жилхэмжигдэхүүн дэх чиг хандлагыг ойлгох. Бүгдийг нь нийлүүлнэ гэдэг одоо болтол шийдэж амжаагүй том асуудал. Сүүлийн хэдэн жил хэрхэн ажиллаж байгааг би танд хэлье.
Бидэнд эдгээр хэмжигдэхүүнийг бичих функцүүд бий орон нутгийн memcache рууоруулгуудын тоог багасгах. Богино хугацаанд нэг удаа орон нутагт эхлүүлсэн статистик-демон бүх бүртгэлийг цуглуулдаг. Дараа нь чөтгөр хэмжүүрүүдийг серверийн хоёр давхаргад нэгтгэдэг гуалин цуглуулагчид, энэ нь манай хэд хэдэн машинуудын статистикийг нэгтгэж, тэдгээрийн ард байгаа давхарга нь үхэхгүй.
Шаардлагатай бол бид бүртгэл цуглуулагчдад шууд бичиж болно.
Гэхдээ stas-daemom-ыг алгасаж коллектор руу кодоос шууд бичих нь коллекторын ачааллыг ихэсгэдэг тул өргөтгөх боломжгүй шийдэл юм. Ямар нэг шалтгаанаар бид memcache stats-demon-г машин дээр суулгаж чадахгүй, эсвэл энэ нь эвдэрч, бид шууд явсан тохиолдолд л шийдэл тохиромжтой.
Дараа нь бүртгэл цуглуулагчид статистикийг нэгтгэдэг meowDB - Энэ бол хэмжигдэхүүнийг хадгалах боломжтой манай мэдээллийн сан юм.
Дараа нь бид кодоос хоёртын "ойролцоо SQL" сонголтыг хийж болно.
Туршилт
2018 оны зун бид дотоод хакатон зохион байгуулж, диаграмын улаан хэсгийг ClickHouse-д хэмжүүр хадгалах боломжтой зүйлээр солих санаа төрсөн. Бидэнд ClickHouse дээр бүртгэлүүд байгаа - яагаад үүнийг туршиж болохгүй гэж?
Бид KittenHouse-ээр дамжуулан лог бичдэг схемтэй байсан.
Бид шийдсэн диаграммд өөр "*House" нэмнэ, энэ нь хэмжүүрүүдийг яг форматаар нь хүлээн авах бөгөөд бидний код нь тэдгээрийг UDP-ээр бичдэг. Дараа нь энэ *House тэдгээрийг лог шиг оруулга болгон хувиргадаг бөгөөд үүнийг KittenHouse ойлгодог. Тэрээр эдгээр бүртгэлийг унших боломжтой ClickHouse-д төгс хүргэж чадна.
Memcache, stats-demon, logs-collectors мэдээллийн сан бүхий схемийг үүнтэй сольсон.
Memcache, stats-demon, logs-collectors мэдээллийн сан бүхий схемийг үүнтэй сольсон.
- Эндээс StatsHouse-д орон нутгийн хэмжээнд бичигдсэн кодын илгээлт байна.
- StatsHouse нь SQL оруулга болгон хувиргасан UDP хэмжигдэхүүнийг KittenHouse руу багцаар нь бичдэг.
- KittenHouse тэднийг ClickHouse руу илгээдэг.
- Хэрэв бид тэдгээрийг уншихыг хүсвэл StatsHouse-ийг алгасаж, ердийн SQL ашиглан ClickHouse-аас шууд уншина.
Одоо ч хэвээрээ юу туршилт, гэхдээ энэ нь хэрхэн эргэх нь бидэнд таалагддаг. Хэрэв бид схемтэй холбоотой асуудлуудыг засах юм бол бид үүн рүү бүрэн шилжих болно. Би хувьдаа тэгнэ гэж найдаж байна.
Энэ схем төмрийг хэмнэдэггүй. Цөөн сервер шаардлагатай, локал статистик-демонууд болон бүртгэл цуглуулагч шаардлагагүй, гэхдээ ClickHouse нь одоогийн схемд байгаа серверүүдээс илүү том сервер шаарддаг. Цөөн сервер хэрэгтэй, гэхдээ тэдгээр нь илүү үнэтэй, илүү хүчирхэг байх ёстой.
Байрлуулах
Эхлээд PHP-ийн байршуулалтыг харцгаая. Бид хөгжиж байна Go: ашиглах GitLab и TeamCity байршуулах зориулалттай. Хөгжлийн салбаруудыг мастер салбар болгон нэгтгэж, туршилтын мастераас эхлээд үе шатыг нэгтгэж, тайзнаас үйлдвэрлэлд нэгтгэдэг.
Байршуулахын өмнө одоогийн үйлдвэрлэлийн салбар болон өмнөхийг нь авч, тэдгээрийн дотор ялгаатай файлуудыг авч үздэг - өөрчлөлтүүд: үүсгэсэн, устгасан, өөрчлөгдсөн. Энэхүү өөрчлөлт нь манай серверийн бүх флотын өөрчлөлтийг хурдан хуулбарлах тусгай copyfast хөдөлгүүрийн бинлогт бичигдсэн байдаг. Энд ашигласан зүйл бол шууд хуулбарлах биш, харин хов живийн хуулбар, нэг сервер хамгийн ойрын хөрш рүүгээ өөрчлөлтийг илгээх үед, хөрш рүүгээ гэх мэт. Энэ нь бүх флотын хэмжээнд хэдэн арван секундын дотор кодыг шинэчлэх боломжийг танд олгоно. Өөрчлөлт нь орон нутгийн хуулбарт хүрэхэд эдгээр засваруудыг өөрийнх нь дээр хэрэглэнэ локал файлын систем. Буцах ажлыг мөн ижил схемийн дагуу гүйцэтгэдэг.
Бид мөн kPHP-г маш ихээр ашигладаг бөгөөд энэ нь бас өөрийн гэсэн хөгжүүлэлттэй байдаг Go дээрх диаграмын дагуу. Үүнээс хойш HTTP серверийн хоёртын хувилбар, тэгвэл бид ялгаа гаргаж чадахгүй - хувилбарын хоёртын файл нь хэдэн зуун МБ жинтэй. Тиймээс энд өөр сонголт бий - хувилбар нь бичигдсэн байдаг binlog copyfast. Барилга бүрд энэ нь нэмэгдэж, буцаах үед мөн нэмэгддэг. Хувилбар серверүүд рүү хуулбарласан. Орон нутгийн copyfast-ууд бинлогт шинэ хувилбар орж ирснийг харж, ижил хов жив хуулбарлах замаар тэд хоёртын хувилбарын хамгийн сүүлийн хувилбарыг өөрсдөө авч, манай мастер серверийг ядраахгүйгээр ачааллыг сүлжээгээр болгоомжтой тарааж өгдөг. Дараа нь юу сайхан дахин эхлүүлэх шинэ хувилбарын хувьд.
Үндсэндээ хоёртын систем болох манай хөдөлгүүрүүдийн хувьд схем нь маш төстэй юм.
- git мастер салбар;
- хоёртын дотор .deb;
- хувилбар нь binlog copyfast дээр бичигдсэн;
- серверт хуулбарласан;
- сервер нь шинэ .dep-г гаргаж авдаг;
- dpkg -i;
- шинэ хувилбар руу сайхан дахин эхлүүлэх.
Ялгаа нь манай хоёртын файл архивт савлагдсан байдаг .deb, мөн тэдгээрийг шахах үед dpkg -i систем дээр байрлуулсан байна. Яагаад kPHP-г хоёртын хувилбараар, харин хөдөлгүүрүүдийг dpkg хэлбэрээр байрлуулдаг вэ? Ийм байдлаар болсон. Энэ нь ажилладаг - бүү хүр.
Хэрэгтэй холбоосууд:
- Антон Кирюшкиний илтгэл copyfast болон хов живийн талаарх дэлгэрэнгүй мэдээлэлтэй.
- Юрий Насретдиновын илтгэл .
- Миний тайлан , гэхдээ техник хангамжийн үүднээс биш харин хөгжүүлэлтийн үүднээс.
Алексей Акулович бол хөтөлбөрийн хорооны нэг хэсэг болгон тусалдаг хүмүүсийн нэг юм 17-р сарын XNUMX-ны өдөр PHP хөгжүүлэгчдийн хувьд сүүлийн үеийн хамгийн том арга хэмжээ болно. Бидэнд ямар гайхалтай компьютер байгааг хараарай (тэдгээрийн хоёр нь PHP цөмийг хөгжүүлж байна!) - Хэрэв та PHP бичвэл алдаж болохгүй зүйл мэт санагдаж байна.
Эх сурвалж: www.habr.com