Дараагийн HighLoad++ бага хурал 6 оны 7-р сарын 2020, XNUMX-ны өдрүүдэд Санкт-Петербург хотод болно.
Дэлгэрэнгүй мэдээлэл, тасалбар . HighLoad++ Сибирь 2019. "Красноярск" танхим. 25-р сарын 12, 00:XNUMX. Дипломууд болон .
Практик шаардлага нь онолтой зөрчилддөг тул арилжааны бүтээгдэхүүнд чухал ач холбогдолтой талуудыг харгалзан үздэггүй. Энэхүү илтгэл нь арилжааны бүтээгдэхүүний шаардлагад тулгуурлан эрдэм шинжилгээний судалгаанд үндэслэн учир шалтгааны уялдаа холбоог бий болгох янз бүрийн арга барилыг сонгох, нэгтгэх үйл явцыг танилцуулж байна. Сонсогчид логик цаг, хамаарлыг хянах, системийн аюулгүй байдал, цагны синхрончлол, MongoDB яагаад тодорхой шийдэлд хүрсэн талаар одоо байгаа онолын арга барилын талаар мэдэх болно.
Михаил Тюленев (цаашид МТ гэх): – Би учир шалтгааны нийцлийн талаар ярих болно - энэ бол бидний MongoDB дээр ажилласан онцлог юм. Би хуваарилагдсан системүүдийн бүлэгт ажилладаг, бид үүнийг хоёр жилийн өмнө хийсэн.
Энэ үйл явцад би энэ шинж чанарыг нэлээд сайн судалсан тул олон эрдэм шинжилгээний судалгаатай танилцах шаардлагатай болсон. Үйлдвэрлэлийн мэдээллийн санд шаардагдах зүйлд нэг ч нийтлэл тохирохгүй нь тодорхой болсон бөгөөд энэ нь аливаа үйлдвэрлэлийн хэрэглээнд байж магадгүй юм.
Эрдмийн судалгааны хэрэглэгчдийн хувьд бид үүнээс ямар нэгэн зүйл бэлтгэж, хэрэглэгчдэдээ хэрэглэхэд тохиромжтой, аюулгүй бэлэн хоол болгон танилцуулах талаар би ярих болно.
Шалтгаан уялдаа холбоо. Үзэл баримтлалыг тодорхойлъё
Эхлэхийн тулд би учир шалтгааны уялдаа холбоо гэж юу болохыг ерөнхийд нь хэлмээр байна. Леонард, Пенни гэсэн хоёр дүр байдаг ("Том тэсрэлтийн онол" телевизийн цуврал):
Пенни Европт байгаа бөгөөд Леонард түүнд гэнэтийн үдэшлэг зохион байгуулахыг хүсч байна гэж бодъё. Түүнийг найзуудын жагсаалтаас хасаж, бүх найзууддаа "Пенниг баярлуулцгаая!" (тэр Европт байгаа, унтаж байхдаа тэр энэ бүхнийг хараагүй, харж чадахгүй, учир нь тэр байхгүй). Эцэст нь тэр энэ нийтлэлийг устгаж, хангамжаас устгаж, юу ч анзаарахгүй, ямар ч шуугиан гарахгүйн тулд хандалтыг сэргээдэг.
Энэ бүхэн сайн, гэхдээ систем нь тараагдсан, бүх зүйл бага зэрэг буруу болсон гэж бодъё. Жишээлбэл, хэрэв үйл явдал нь шалтгаан, үр дагавартай холбоогүй бол энэ нийтлэл гарсны дараа Пеннигийн хандалтын хязгаарлалт үүссэн байж магадгүй юм. Үнэн хэрэгтээ энэ нь бизнесийн үйл ажиллагааг гүйцэтгэхийн тулд учир шалтгааны уялдаа холбоог шаарддаг жишээ юм (энэ тохиолдолд).
Үнэн хэрэгтээ эдгээр нь өгөгдлийн сангийн нэлээд ач холбогдолгүй шинж чанарууд юм - маш цөөхөн хүн тэднийг дэмждэг. Загварууд руугаа явцгаая.
Тогтвортой байдлын загварууд
Өгөгдлийн сан дахь тууштай байдлын загвар гэж яг юу вэ? Эдгээр нь үйлчлүүлэгч ямар өгөгдөл, ямар дарааллаар хүлээн авч болох талаар түгээсэн систем өгдөг баталгааны зарим хэсэг юм.
Зарчмын хувьд, бүх тууштай загварууд нь тархсан систем нь жишээлбэл, зөөврийн компьютер дээрх нэг зангилаа дээр ажилладаг системтэй хэр төстэй болохыг тодорхойлдог. Олон мянган гео тархсан "Зангилаа" дээр ажилладаг систем нь эдгээр бүх шинж чанаруудыг зарчмын хувьд автоматаар гүйцэтгэдэг зөөврийн компьютертэй яг адилхан юм.
Тиймээс тууштай байдлын загварыг зөвхөн тархсан системд ашигладаг. Өмнө нь нэг босоо масштабаар ажиллаж байсан бүх системүүд ийм асуудалтай тулгараагүй. Нэг буфер кэш байсан бөгөөд бүх зүйлийг үргэлж тэндээс уншдаг байв.
Хүчтэй загвар өмсөгч
Үнэн хэрэгтээ хамгийн анхны загвар нь Хүчтэй (эсвэл өсөлтийн чадварын шугамыг ихэвчлэн нэрлэдэг) юм. Энэ нь өөрчлөлт гарсан нь батлагдсаны дараа системийн бүх хэрэглэгчдэд харагдахуйц байдлыг баталгаажуулдаг тууштай загвар юм.
Энэ нь мэдээллийн сан дахь бүх үйл явдлын дэлхийн дарааллыг бий болгодог. Энэ бол маш хүчтэй тууштай шинж чанар бөгөөд энэ нь ерөнхийдөө маш үнэтэй байдаг. Гэсэн хэдий ч үүнийг маш сайн дэмждэг. Энэ нь маш үнэтэй бөгөөд удаан байдаг - энэ нь маш ховор хэрэглэгддэг. Үүнийг өсөх чадвар гэж нэрлэдэг.
Spanner-д дэмжигдсэн өөр нэг илүү хүчтэй өмч байдаг бөгөөд үүнийг Гадаад тууштай байдал гэж нэрлэдэг. Бид энэ талаар бага зэрэг дараа ярих болно.
Шалтгаан
Дараагийнх нь Causal, яг миний яриад байсан зүйл. Хүчтэй ба Шалтгаан хоёрын хооронд би ярихгүй өөр хэд хэдэн дэд түвшин байгаа ч тэдгээр нь бүгд Шалтгаан руу буцна. Энэ нь бүх загваруудаас хамгийн бат бөх, сүлжээ эсвэл хуваалттай байх үед хамгийн бат бөх тогтвортой байдал учраас чухал загвар юм.
Шалтгаан гэдэг нь үнэндээ үйл явдлууд нь шалтгаан, үр дагаврын холбоогоор холбогддог нөхцөл байдал юм. Маш олон удаа тэд үйлчлүүлэгчийн байр сууринаас таны эрхийг уншаарай гэж ойлгогддог. Хэрэв үйлчлүүлэгч зарим үнэт зүйлсийг ажигласан бол тэр урьд өмнө байсан үнэт зүйлсийг харж чадахгүй. Тэр аль хэдийн угтвар уншлагыг харж эхэлсэн. Энэ бүхэн нэг л зүйл дээр ирдэг.
Тогтвортой байдлын загвар болох учир шалтгаан нь сервер дээрх үйл явдлуудын хэсэгчилсэн дараалал бөгөөд бүх үйлчлүүлэгчдийн үйл явдлууд ижил дарааллаар ажиглагддаг. Энэ тохиолдолд Леонард, Пенни нар.
Үйл явдал
Гурав дахь загвар нь Eventual Consistency юм. Энэ бол бүх тархсан системүүдийн дэмждэг зүйл бөгөөд хамгийн бага загвар нь утга учиртай юм. Энэ нь дараахь зүйлийг илэрхийлнэ: өгөгдөлд зарим өөрчлөлт орсон үед тэдгээр нь тогтмол болж хувирдаг.
Ийм үед тэр юу ч хэлдэггүй, эс тэгвээс тэр гадаад тууштай болж хувирах болно - энэ нь огт өөр түүх байх болно. Гэсэн хэдий ч энэ бол маш алдартай загвар бөгөөд хамгийн түгээмэл юм. Анхдагч байдлаар, тархсан системийн бүх хэрэглэгчид Eventual Consistency-ийг ашигладаг.
Би зарим харьцуулсан жишээ өгөхийг хүсч байна:
Эдгээр сумнууд юу гэсэн үг вэ?
- Хоцролт. Тогтвортой байдлын хүч нэмэгдэхийн хэрээр тодорхой шалтгааны улмаас томрох болно: та илүү их бичлэг хийх, өгөгдөл аль хэдийн байгаа гэдгийг кластерт оролцдог бүх хост болон зангилаанаас баталгаажуулах хэрэгтэй. Үүний дагуу, эцсийн тууштай байдал нь хамгийн хурдан хариулт юм, учир нь тэнд, дүрмээр бол та үүнийг санах ойд багтааж болно, энэ нь зарчмын хувьд хангалттай байх болно.
- Бэлэн байдал. Хэрэв бид үүнийг сүлжээний тасалдал, хуваалт эсвэл зарим төрлийн бүтэлгүйтлийн үед системийн хариу үйлдэл үзүүлэх чадвар гэж ойлговол тууштай загвар буурах тусам алдааны тэсвэрлэх чадвар нэмэгддэг, учир нь нэг хост амьдрахад хангалттай. цаг хугацаа зарим өгөгдлийг үүсгэдэг. Эцсийн тууштай байдал нь өгөгдлийн талаар ямар ч баталгаа өгөхгүй - энэ нь юу ч байж болно.
- Аномали. Үүний зэрэгцээ гажиг үүсэх нь мэдээжийн хэрэг. Strong Consistency-д тэдгээр нь бараг огт байх ёсгүй, харин Эцсийн тууштай байдалд тэд юу ч байж болно. Асуулт гарч ирнэ: хэрэв хүмүүс гажуудал агуулсан бол яагаад Eventual Consistency-ийг сонгодог вэ? Хариулт нь эцсийн тууштай байдлын загваруудыг ашиглах боломжтой бөгөөд гажуудал, тухайлбал, богино хугацаанд; Тогтвортой өгөгдлийг уншиж, бага багаар уншихын тулд шидтэнг ашиглах боломжтой; Ихэнхдээ хүчтэй тууштай загваруудыг ашиглах боломжтой байдаг. Практикт энэ нь ажилладаг бөгөөд ихэвчлэн гажигуудын тоо цаг хугацаагаар хязгаарлагддаг.
CAP теорем
Тогтвортой байдал, хүртээмжтэй байдал гэсэн үгсийг хараад таны санаанд юу орж ирдэг вэ? Энэ нь зөв - CAP теорем! Одоо би домгийг арилгахыг хүсч байна ... Энэ бол би биш - Мартин Клепманн, гайхалтай нийтлэл, гайхалтай ном бичсэн.
CAP теорем нь 2000-аад онд томъёолсон зарчим юм. Тогтвортой байдал, олдоц, хуваалтууд: дурын хоёрыг авбал гурвыг сонгох боломжгүй. Энэ нь тодорхой зарчим байсан. Хэдэн жилийн дараа Гилберт, Линч нар үүнийг теорем болгон баталсан. Дараа нь үүнийг тарни болгон ашиглаж эхэлсэн - системүүд нь CA, CP, AP гэх мэт хуваагдаж эхлэв.
Энэ теорем нь дараах тохиолдлуудад үнэн хэрэгтээ батлагдсан... Нэгд, Хүртээмжийг тэгээс зуу хүртэлх тасралтгүй утга гэж үзээгүй (0 - систем "үхсэн", 100 - хурдан хариу өгдөг; бид үүнийг ингэж авч үздэг байсан) , гэхдээ алгоритмын өмчийн хувьд бүх гүйцэтгэлийн хувьд өгөгдөл буцаана гэдгийг баталгаажуулдаг.
Хариулах хугацааны талаар нэг ч үг алга! 100 жилийн дараа өгөгдлийг буцаадаг алгоритм байдаг бөгөөд энэ нь CAP теоремын нэг хэсэг болох үнэхээр гайхалтай боломжтой алгоритм юм.
Хоёрдугаарт: эдгээр өөрчлөлтүүдийн хэмжээг өөрчлөх боломжтой хэдий ч ижил түлхүүрийн утгын өөрчлөлтийг теоремоор нотолсон. Энэ нь бодит байдал дээр тэдгээрийг бараг ашигладаггүй гэсэн үг юм, учир нь загварууд нь эцсийн тууштай байдал, хүчтэй тууштай байдал (магадгүй) өөр өөр байдаг.
Энэ бүхэн юуны төлөө вэ? Түүгээр ч барахгүй CAP теорем нь батлагдсан хэлбэрээрээ бараг хэрэглэгдэхгүй бөгөөд бараг ашиглагддаггүй. Онолын хувьд энэ нь ямар нэгэн байдлаар бүх зүйлийг хязгаарладаг. Энэ нь зөн совингийн хувьд зөв боловч ерөнхийдөө нотлогдоогүй тодорхой зарчим болж байна.
Шалтгаан уялдаа холбоо нь хамгийн хүчтэй загвар юм
Одоо юу болж байна вэ гэвэл та хуваалтуудыг ашиглан тууштай байдал, хүртээмжтэй байдал гэсэн гурван зүйлийг авах боломжтой. Ялангуяа, Шалтгаан уялдаа холбоо нь Хуваалтууд (сүлжээний эвдрэл) байгаа үед ажилладаг хэвээр байгаа хамгийн хүчтэй тууштай загвар юм. Тийм ч учраас энэ нь маш их сонирхол татаж байгаа тул бид үүнийг авч үзсэн.
Нэгдүгээрт, энэ нь програм хөгжүүлэгчдийн ажлыг хялбаршуулдаг. Ялангуяа серверээс маш сайн дэмжлэг байгаа нь: нэг клиент доторх бүх бичлэгүүд өөр клиент дээр ижил дарааллаар ирэх баталгаатай байдаг. Хоёрдугаарт, энэ нь хуваалтыг тэсвэрлэдэг.
MongoDB дотоод гал тогоо
Үдийн хоол гэдгийг санаад бид гал тогооны өрөө рүү явлаа. Би танд системийн загвар, тухайлбал ийм мэдээллийн сангийн талаар анх удаа сонсож байгаа хүмүүст MongoDB гэж юу болохыг хэлэх болно.
MongoDB (цаашид "MongoDB" гэх) нь хэвтээ масштаблах, өөрөөр хэлбэл хуваахыг дэмждэг тархсан систем юм; мөн хэлтэрхий бүрийн дотор энэ нь өгөгдлийн нөөцийг, өөрөөр хэлбэл хуулбарлахыг дэмждэг.
MongoDB дахь Sharding (харилцааны өгөгдлийн сан биш) автомат тэнцвэржүүлэлтийг гүйцэтгэдэг, өөрөөр хэлбэл баримт бичгийн цуглуулга бүрийг (эсвэл харилцааны өгөгдлийн хувьд "хүснэгт") хэсэг болгон хуваах ба сервер тэдгээрийг хэсгүүдийн хооронд автоматаар шилжүүлдэг.
Үйлчлүүлэгчийн хувьд хүсэлтийг түгээдэг Query Router нь түүний ажилладаг зарим үйлчлүүлэгч юм. Энэ нь хаана, ямар өгөгдөл байгааг аль хэдийн мэддэг бөгөөд бүх хүсэлтийг зөв хэлтэрхий рүү чиглүүлдэг.
Өөр нэг чухал зүйл: MongoDB бол ганц мастер юм. Нэг Анхдагч байдаг - энэ нь түүнд агуулагдах түлхүүрүүдийг дэмждэг бичлэгүүдийг авч болно. Та Multi-master бичих боломжгүй.
Бид 4.2 хувилбарыг гаргасан - тэнд шинэ сонирхолтой зүйлс гарч ирэв. Ялангуяа тэд Lucene - хайлт - гүйцэтгэх боломжтой java-г шууд Mongo-д оруулсан бөгөөд тэнд Elastica-тай адил Lucene-ээр дамжуулан хайлт хийх боломжтой болсон.
Мөн тэд шинэ бүтээгдэхүүн хийсэн - Charts, энэ нь Атлас (Mongo-ийн өөрийн Cloud) дээр бас байдаг. Тэд үнэ төлбөргүй шаттай - та түүгээр тоглож болно. Надад Charts маш их таалагдсан - өгөгдлийн дүрслэл, маш ойлгомжтой.
Найрлага Шалтгаануудын тууштай байдал
Би энэ сэдвээр нийтлэгдсэн 230 орчим нийтлэлийг тоолсон - Лесли Ламперт. Одоо би эдгээр материалын зарим хэсгийг санах ойгоос танд хүргэх болно.
Энэ бүхэн 1970-аад онд бичсэн Лесли Лампертын нийтлэлээс эхэлсэн юм. Таны харж байгаагаар энэ сэдвээр зарим судалгаа үргэлжилж байна. Одоо учир шалтгааны уялдаа холбоо нь тархсан системийг хөгжүүлэхтэй холбоотойгоор сонирхол татаж байна.
Хязгаарлалтууд
Ямар хязгаарлалтууд байдаг вэ? Энэ нь үнэндээ гол санаануудын нэг юм, учир нь үйлдвэрлэлийн тогтолцооны хязгаарлалт нь эрдэм шинжилгээний өгүүлэлд байдаг хязгаарлалтаас тэс өөр байдаг. Тэд ихэвчлэн нэлээд хиймэл байдаг.
- Нэгдүгээрт, "MongoDB" бол миний хэлсэнчлэн ганц мастер (энэ нь маш хялбаршуулсан).
- Систем нь ойролцоогоор 10 мянган ширхэгийг дэмжих ёстой гэж бид үзэж байна. Бид энэ үнэ цэнийг тодорхой хязгаарлах ямар ч архитектурын шийдвэр гаргаж чадахгүй.
- Бидэнд үүл бий, гэхдээ хүн хоёртын файлыг татаж аваад, зөөврийн компьютер дээрээ ажиллуулж, бүх зүйл маш сайн ажилладаг байх ёстой гэж бид үздэг.
- Судалгааны ховор таамагладаг зүйлийг бид гадны үйлчлүүлэгчид хүссэн бүхнээ хийж чадна гэж үздэг. MongoDB нь нээлттэй эх сурвалж юм. Үүний дагуу үйлчлүүлэгчид маш ухаалаг, ууртай байж чаддаг - тэд бүгдийг эвдэхийг хүсч болно. Византийн феилорууд үүссэн байж магадгүй гэж бид таамаглаж байна.
- Периметрээс гадуур байгаа гадаад үйлчлүүлэгчдийн хувьд чухал хязгаарлалт байдаг: хэрэв энэ функц идэвхгүй бол гүйцэтгэлийн бууралт ажиглагдахгүй байх ёстой.
- Өөр нэг зүйл бол ерөнхийдөө академийн эсрэг байдаг: өмнөх болон ирээдүйн хувилбаруудын нийцтэй байдал. Хуучин драйверууд шинэ шинэчлэлтийг дэмжих ёстой бөгөөд мэдээллийн сан нь хуучин драйверуудыг дэмжих ёстой.
Ерөнхийдөө энэ бүхэн хязгаарлалт тавьдаг.
Шалтгаан тууштай байдлын бүрэлдэхүүн хэсгүүд
Одоо би зарим бүрэлдэхүүн хэсгүүдийн талаар ярих болно. Хэрэв бид учир шалтгааны уялдаа холбоог ерөнхийд нь авч үзвэл блокуудыг сонгож болно. Бид тодорхой блокт хамаарах бүтээлүүдээс сонгосон: Хамааралтай байдлыг хянах, цагийг сонгох, эдгээр цагийг бие биетэйгээ хэрхэн синхрончлох, аюулгүй байдлыг хэрхэн хангах талаар - энэ бол миний ярих зүйлийн тойм юм.
Бүрэн хараат байдлыг хянах
Яагаад хэрэгтэй байна вэ? Өгөгдлийг хуулбарлах үед бичлэг бүр, өгөгдлийн өөрчлөлт бүр нь ямар өөрчлөлтөөс хамаарах тухай мэдээллийг агуулна. Хамгийн анхны бөгөөд гэнэн өөрчлөлт бол бичлэг агуулсан мессеж бүр өмнөх мессежүүдийн мэдээллийг агуулсан байх явдал юм.
Энэ жишээнд буржгар хаалтанд байгаа тоо нь бичлэгийн тоо юм. Заримдаа эдгээр утгууд бүхий бүртгэлийг бүхэлд нь шилжүүлж, заримдаа зарим хувилбаруудыг шилжүүлдэг. Хамгийн гол нь өөрчлөлт бүр нь өмнөх өөрчлөлтийн талаархи мэдээллийг агуулдаг (мэдээж энэ бүгдийг өөртөө агуулдаг).
Бид яагаад энэ аргыг (бүрэн хянах) ашиглахгүй гэж шийдсэн бэ? Мэдээжийн хэрэг, энэ арга нь боломжгүй тул: нийгмийн сүлжээнд гарсан аливаа өөрчлөлт нь тухайн нийгмийн сүлжээнд өмнөх бүх өөрчлөлтөөс хамаарна, тухайлбал, Facebook эсвэл VKontakte шинэчлэлт болгонд шилжүүлэх. Гэсэн хэдий ч бүрэн хараат байдлыг хянах талаар маш их судалгаа хийдэг - эдгээр нь нийгмийн өмнөх сүлжээнүүд юм; зарим тохиолдолд энэ нь үнэхээр ажилладаг.
Илэрхий хараат байдлыг хянах
Дараагийнх нь илүү хязгаарлагдмал. Мэдээллийн дамжуулалтыг энд авч үзэх болно, гэхдээ зөвхөн тодорхой хамааралтай зүйлийг л авч үзнэ. Юунаас шалтгаалах нь дүрмээр бол програмаар тодорхойлогддог. Өгөгдлийг хуулбарлах үед асуулга нь өмнөх хамаарал хангагдсан, өөрөөр хэлбэл харуулсан үед л хариултуудыг буцаана. Энэ бол учир шалтгааны уялдаа холбоо хэрхэн ажилладагийн мөн чанар юм.
Тэр 5-р бичлэг нь 1, 2, 3, 4-р бүртгэлээс хамаардаг болохыг тэр харж байна - үүний дагуу өмнөх бүх өөрчлөлтүүд мэдээллийн баазаар дамжсан байх үед Пеннигийн хандалтын шийдвэрээр хийсэн өөрчлөлтөд үйлчлүүлэгч хандахаас өмнө хүлээж байна.
Энэ нь бидэнд тохирохгүй, учир нь хэтэрхий их мэдээлэл байгаа бөгөөд энэ нь ажлыг удаашруулна. Өөр нэг арга бий ...
Лампортын цаг
Тэд маш өндөр настай. Lamport Clock гэдэг нь эдгээр хамаарлыг скаляр функц болгон нугалж, үүнийг Лампорт цаг гэж нэрлэдэг гэсэн үг юм.
Скаляр функц нь хийсвэр тоо юм. Үүнийг ихэвчлэн логик цаг гэж нэрлэдэг. Үйл явдал бүрт энэ тоолуур нэмэгддэг. Процессод одоогоор мэдэгдэж байгаа тоолуур нь мессеж бүрийг илгээдэг. Процессууд нь синхрончлолгүй болох нь тодорхой бөгөөд тэдгээр нь огт өөр цаг хугацаатай байж болно. Гэсэн хэдий ч систем нь ийм мессежээр цагийг ямар нэгэн байдлаар тэнцвэржүүлдэг. Энэ тохиолдолд юу болох вэ?
Тодорхой болгохын тулд би тэр том хэлтэрхийг хоёр хуваасан: Найзууд цуглуулгын нэг хэсгийг агуулсан нэг зангилаа, Feed нь энэ цуглуулгын нэг хэсгийг агуулсан өөр зангилаа дотор амьдарч болно. Тэд хэрхэн шугамнаас гарах нь тодорхой байна уу? Эхлээд Feed: "Хуулбарласан", дараа нь Найзууд гэж хэлэх болно. Хэрэв систем нь "Найзуудын" цуглуулга дахь Найзуудын хамаарлыг хүргэх хүртэл тэжээлийг харуулахгүй гэсэн баталгааг өгөхгүй бол бид яг миний хэлсэн нөхцөл байдалд орох болно.
Feed дээрх тоолуурын хугацаа хэрхэн логикоор нэмэгдэж байгааг та харж байна:
Иймээс энэхүү Лампортын цаг ба учир шалтгааны уялдаа холбоо (Лампорт цагаар тайлбарласан) нь дараах байдалтай байна: хэрвээ бидэнд А ба В үйл явдлууд байгаа бөгөөд В үйл явдал А* үйл явдлаас хамаардаг бол А үйл явдлын логик цаг нь дараахаас бага байна гэсэн үг. Б үйл явдлын логик цаг.
* Заримдаа тэд А нь В-ээс өмнө тохиолдсон, өөрөөр хэлбэл А нь В-ээс өмнө тохиолдсон гэж хэлдэг - энэ нь ерөнхийдөө болсон бүх үйл явдлын багцыг хэсэгчлэн зохицуулдаг тодорхой харилцаа юм.
Харин эсрэгээрээ буруу байна. Энэ нь үнэндээ Lamport Clock-ийн гол сул талуудын нэг юм - хэсэгчилсэн захиалга. Нэгэн зэрэг тохиолдох үйл явдлуудын тухай ойлголт байдаг, өөрөөр хэлбэл (А-аас өмнө тохиолдсон) эсвэл (А нь Б-ээс өмнө тохиолдсон) аль нь ч байгаагүй. Жишээ нь Леонард өөр хэн нэгнийг найзаар нэмсэн (жишээ нь Леонард биш, харин Шелдон гэх мэт).
Энэ нь Lamport цагтай ажиллахад ихэвчлэн ашиглагддаг шинж чанар юм: тэд функцийг тусгайлан авч үздэг бөгөөд үүнээс тэд эдгээр үйл явдлууд хамааралтай байж магадгүй гэж дүгнэдэг. Учир нь нэг арга нь үнэн: хэрвээ LogicalTime A LogicalTime B-ээс бага бол B A-аас өмнө тохиолдох боломжгүй; хэрэв илүү бол магадгүй.
Вектор цаг
Lamport цагны логик хөгжил нь Вектор цаг юм. Эдгээр нь энд байгаа зангилаа бүр өөрийн гэсэн тусдаа цагийг агуулж байгаагаараа ялгаатай бөгөөд тэдгээрийг вектор хэлбэрээр дамжуулдаг.
Энэ тохиолдолд векторын тэг индекс нь Feed-ийг хариуцдаг бөгөөд векторын эхний индекс нь Найзуудад (эдгээр зангилаа бүр) зориулагдсан болохыг та харж байна. Одоо тэд нэмэгдэх болно: бичих үед "Тэжээлийн" тэг индекс нэмэгддэг - 1, 2, 3:
Вектор цаг яагаад илүү дээр вэ? Учир нь тэдгээр нь аль үйл явдал нэгэн зэрэг, өөр өөр зангилаанууд дээр хэзээ тохиолдохыг олж мэдэх боломжийг олгодог. Энэ нь MongoDB шиг sharding системийн хувьд маш чухал юм. Гэсэн хэдий ч бид үүнийг сонгоогүй, гэхдээ энэ нь гайхалтай зүйл бөгөөд энэ нь маш сайн ажилладаг бөгөөд энэ нь бидэнд тохирох байх ...
Хэрэв бид 10 мянган хэлтэрхийтэй бол бид үүнийг шахаж эсвэл өөр зүйл гаргасан ч 10 мянган бүрэлдэхүүн хэсгийг шилжүүлж чадахгүй - ачаалал нь энэ векторын хэмжээнээс хэд дахин бага байх болно. Тиймээс бид зүрх сэтгэл, шүдээ хавиран энэ аргыг орхиж, өөр арга руу шилжсэн.
TrueTime түлхүүр. Атомын цаг
Спаннерын тухай түүх байх болно гэж би хэлсэн. Энэ бол XNUMX-р зууны үеийн гайхалтай зүйл: атомын цаг, GPS-ийн синхрончлол.
Ямар санаа байна? "Spanner" бол саяхан хүмүүст ашиглах боломжтой болсон Google систем юм (тэд SQL-г нэмсэн). Тэнд байгаа гүйлгээ бүр тодорхой хугацааны тэмдэгтэй байдаг. Цаг синхрончлогдсон тул үйл явдал бүрийг тодорхой цаг хугацаатай болгож болно - атомын цаг нь хүлээх хугацаатай бөгөөд үүний дараа өөр цаг "болно".
Тиймээс мэдээллийн санд зүгээр л бичиж, хэсэг хугацаанд хүлээснээр үйл явдлын цуваа автоматаар баталгааждаг. Тэд зарчмын хувьд төсөөлж болох хамгийн хүчтэй тууштай байдлын загвартай байдаг - энэ бол Гадаад тууштай байдал юм.
* Энэ бол Lampart цагны гол асуудал бөгөөд тэдгээр нь тархсан систем дээр хэзээ ч синхрон байдаггүй. Тэд зөрөх боломжтой; NTP-тэй байсан ч тэд тийм ч сайн ажиллахгүй байна. "Spanner" нь атомын цагтай бөгөөд синхрончлол нь микросекунд юм шиг санагддаг.
Бид яагаад сонгоогүй юм бэ? Манай хэрэглэгчид атомын цагтай гэж бид таамаглаагүй. Тэд гарч ирэхэд зөөврийн компьютер болгонд суурилуулсан байх үед ямар нэгэн гайхалтай GPS-ийн синхрончлол бий болно - тэгвэл тийм... Гэхдээ одоохондоо хамгийн шилдэг нь Amazon, Base Stations - фанатуудад зориулагдсан ... Тиймээс бид бусад цагнуудыг ашигласан. .
Гибрид цаг
Энэ нь үнэндээ MongoDB-д учир шалтгааны уялдаа холбоог хангахад чухал ач холбогдолтой зүйл юм. Тэд ямар эрлийз вэ? Гибрид нь скаляр утга боловч хоёр бүрэлдэхүүн хэсэгтэй:
- Эхнийх нь Юниксийн эрин үе ("компьютерийн ертөнц эхэлснээс хойш хэдэн секунд өнгөрөв").
- Хоёр дахь нь зарим нэг өсөлт, мөн 32 битийн тэмдэггүй int.
Энэ бол үнэндээ. Ийм хандлага байдаг: цагийг хариуцдаг хэсэг нь цагтай байнга синхрончлогддог; Шинэчлэлт хийх болгонд энэ хэсэг нь цагтай синхрончлогддог бөгөөд цаг үргэлж их бага зөв байдаг бөгөөд өсөлт нь тухайн цаг үед болсон үйл явдлуудыг ялгах боломжийг олгодог.
Энэ нь яагаад MongoDB-д чухал вэ? Учир нь энэ нь тодорхой цаг хугацаанд ямар нэгэн нөөц ресторан хийх боломжийг олгодог, өөрөөр хэлбэл үйл явдлыг цаг хугацаагаар нь индексжүүлдэг. Энэ нь тодорхой үйл явдал шаардлагатай үед чухал юм; Өгөгдлийн сангийн хувьд үйл явдлууд нь тодорхой хугацааны интервалаар мэдээллийн санд гарсан өөрчлөлтүүд юм.
Би чамд хамгийн чухал шалтгааныг хэлэх болно (хэнд ч битгий хэлээрэй)! MongoDB OpLog дээр эмх цэгцтэй, индексжүүлсэн өгөгдөл ийм харагддаг тул бид үүнийг хийсэн. OpLog нь мэдээллийн сан дахь бүх өөрчлөлтийг агуулсан өгөгдлийн бүтэц юм: тэдгээр нь эхлээд OpLog руу очдог бөгөөд дараа нь хуулбарласан огноо эсвэл хэлтэрхий байх тохиолдолд хадгалах санд хэрэглэгдэх болно.
Энэ бол гол шалтгаан байсан. Гэсэн хэдий ч мэдээллийн санг боловсруулахад практик шаардлагууд байдаг бөгөөд энэ нь энгийн байх ёстой гэсэн үг юм - бага код, аль болох цөөн эвдэрсэн зүйлийг дахин бичиж, туршиж үзэх хэрэгтэй. Манай оплогуудыг эрлийз цагаар индексжүүлсэн нь маш их тус болж, зөв сонголт хийх боломжийг олгосон. Энэ нь үнэхээр үр өгөөжөө өгсөн бөгөөд анхны загвар дээр ямар нэгэн байдлаар ид шидтэй ажилласан. Энэ нь маш сайхан байсан!
Цагийн синхрончлол
Шинжлэх ухааны уран зохиолд тайлбарласан хэд хэдэн синхрончлолын аргууд байдаг. Бид хоёр өөр хэлтэрхийтэй байхад би синхрончлолын тухай ярьж байна. Хэрэв нэг хуулбарын багц байгаа бол синхрончлол хийх шаардлагагүй: энэ бол "ганц мастер"; Бидэнд бүх өөрчлөлтүүд багтдаг OpLog байгаа - энэ тохиолдолд бүх зүйл "Oplog" дотор аль хэдийн дараалсан байна. Гэхдээ хэрэв бид хоёр өөр хэлтэрхийтэй бол энд цагийн синхрончлол чухал юм. Энд вектор цаг илүү тусалсан! Гэхдээ бидэнд тэд байхгүй.
Хоёр дахь нь тохиромжтой - энэ бол "Зүрхний цохилт" юм. Цаг хугацааны нэгж бүрт тохиолддог зарим дохиог солилцох боломжтой. Гэхдээ зүрхний цохилт хэтэрхий удаан тул бид үйлчлүүлэгчдээ хоцролт өгөх боломжгүй.
Жинхэнэ цаг бол мэдээж гайхалтай зүйл. Гэхдээ дахин хэлэхэд энэ нь магадгүй ирээдүй юм ... Хэдийгээр үүнийг Атлас дээр аль хэдийн хийж болох ч хурдан "Amazon" цаг синхрончлогч аль хэдийн байдаг. Гэхдээ энэ нь хүн бүрт боломжгүй байх болно.
Хов жив гэдэг нь бүх зурваст цаг хугацаа багтсан байх явдал юм. Энэ нь ойролцоогоор бидний ашигладаг зүйл юм. Зангилаа хоорондын мессеж бүр, драйвер, өгөгдлийн зангилаа чиглүүлэгч, MongoDB-д зориулсан бүх зүйл бол ямар нэгэн төрлийн элемент, ажилладаг цагийг агуулсан мэдээллийн сангийн бүрэлдэхүүн хэсэг юм. Тэд хаа сайгүй эрлийз цагийн утга учиртай, энэ нь дамждаг. 64 бит үү? Энэ нь зөвшөөрдөг, энэ нь боломжтой.
Энэ бүхэн хэрхэн хамт ажилладаг вэ?
Энд би үүнийг арай хялбар болгохын тулд нэг хуулбарыг харж байна. Анхан болон хоёрдогч гэж байдаг. Хоёрдогч нь хуулбарлах үйлдэл хийдэг бөгөөд анхдагчтай үргэлж бүрэн синхрончлогддоггүй.
"Анхдагч" хэсэгт тодорхой хугацааны утга бүхий оруулга хийгдэнэ. Хэрэв энэ нь дээд тал нь бол энэ оруулга нь дотоод тоог 11-ээр нэмэгдүүлдэг. Эсвэл цагны утгыг шалгаж, илүү их байвал цагтай синк хийнэ. Энэ нь цаг хугацаагаар зохион байгуулах боломжийг танд олгоно.
Тэр бичлэг хийсний дараа чухал мөч тохиолддог. Цаг нь "MongoDB"-д байгаа бөгөөд зөвхөн "Oplog" руу бичих тохиолдолд нэмэгддэг. Энэ бол системийн төлөв байдлыг өөрчилдөг үйл явдал юм. Бүх сонгодог нийтлэлүүдэд мессеж зангилаа хүрэх үед үйл явдал гэж тооцогддог: мессеж ирсэн бөгөөд энэ нь систем төлөвөө өөрчилсөн гэсэн үг юм.
Энэ нь судалгааны явцад энэ мессежийг хэрхэн тайлбарлах нь бүрэн тодорхойгүй байгаатай холбоотой юм. Хэрэв энэ нь "Оплог" -д тусгагдаагүй бол үүнийг ямар ч байдлаар тайлбарлахгүй бөгөөд системийн төлөв байдлын өөрчлөлт нь зөвхөн "Оплог" -д оруулсан зүйл гэдгийг бид баттай мэдэж байна. Энэ нь бидний хувьд бүх зүйлийг хялбаршуулдаг: загвар нь үүнийг хялбаршуулж, нэг хуулбарын багц болон бусад олон ашигтай зүйлсийг зохион байгуулах боломжийг бидэнд олгодог.
"Oplog"-д аль хэдийн бичигдсэн утгыг буцаана - "Oplog"-д энэ утгыг аль хэдийн агуулж байгаа бөгөөд түүний хугацаа 12 гэдгийг бид мэднэ. Одоо унших нь өөр зангилаанаас (хоёрдогч) эхэлж, дараа нь ClusterTime-г дамжуулдаг гэж хэлье. мессеж. Тэрээр: "Надад 12-оос хойш эсвэл арван хоёрын хооронд болсон бүх зүйл надад хэрэгтэй байна" гэж хэлсэн (дээрх зургийг үз).
Үүнийг Causal a consistent (CAT) гэж нэрлэдэг. Онолын хувьд энэ бол өөрөө өөртөө нийцсэн хэсэг хугацааны хэсэг гэсэн ойлголт байдаг. Энэ тохиолдолд бид 12-р үед ажиглагдсан системийн төлөв байдал гэж хэлж болно.
Одоохондоо энд юу ч алга, учир нь энэ төрлийн зүйл нь анхдагчаас өгөгдлийг хуулбарлахын тулд Хоёрдогч хэрэгтэй үед нөхцөл байдлыг дуурайдаг. Тэр хүлээж байна ... Тэгээд одоо өгөгдөл ирсэн - тэр эдгээр утгыг буцааж өгдөг.
Энэ бүхэн бараг л ингэж ажилладаг. Бараг л.
"Бараг" гэж юу гэсэн үг вэ? Энэ бүхэн хэрхэн ажилладагийг уншиж, ойлгосон хүн байна гэж бодъё. ClusterTime тохиолдох бүрт дотоод логик цагийг шинэчилж, дараа нь дараагийн оруулга нэгээр нэмэгддэг гэдгийг би ойлгосон. Энэ функц нь 20 мөр авдаг. Энэ хүн нэгийг хассан 64 битийн хамгийн том тоог дамжуулдаг гэж бодъё.
Яагаад "хасах нэг" гэж? Дотоод цагийг энэ утгад орлуулах тул (энэ нь одоогийнхоос хамгийн их бөгөөд хамгийн их байх нь ойлгомжтой) дараа нь "Oplog" -д оруулга гарч ирэх бөгөөд цаг өөр нэгжээр нэмэгдэх болно - мөн аль хэдийн байх болно. хамгийн их утга байх (зүгээр л бүх нэгжүүд байдаг, өөр явах газар байхгүй) , unsaint ints).
Үүний дараа систем ямар ч зүйлд бүрэн нэвтрэх боломжгүй болох нь тодорхой байна. Үүнийг зөвхөн буулгаж, цэвэрлэж болно - маш их гарын авлагын ажил. Бүрэн боломжтой:
Түүнээс гадна, хэрэв энэ нь өөр газар давтагдсан бол кластер бүхэлдээ унана. Хэн ч маш хурдан бөгөөд амархан зохион байгуулж болох туйлын хүлээн зөвшөөрөгдөхгүй нөхцөл байдал! Тиймээс бид энэ мөчийг хамгийн чухал мөчүүдийн нэг гэж үзсэн. Үүнээс хэрхэн сэргийлэх вэ?
Бидний арга бол clusterTime-д гарын үсэг зурах явдал юм
Энэ нь зурваст (цэнхэр бичвэрийн өмнө) ийм байдлаар дамждаг. Гэхдээ бид бас гарын үсэг зурж эхэлсэн (цэнхэр текст):
Гарын үсэг нь мэдээллийн санд, аюулгүй периметр дотор хадгалагдсан түлхүүрээр үүсгэгддэг; өөрөө үүсгэж, шинэчлэгддэг (хэрэглэгчид энэ талаар юу ч харахгүй байна). Хэш үүсгэгддэг бөгөөд мессеж бүрийг үүсгэх үед гарын үсэг зурж, хүлээн авах үед баталгаажуулдаг.
Хүмүүсийн толгойд “Энэ нь үйл ажиллагааг хэр удаашруулж байна вэ?” гэсэн асуулт гарч ирж магадгүй юм. Ялангуяа энэ функц байхгүй үед хурдан ажиллах ёстой гэж би хэлсэн.
Энэ тохиолдолд учир шалтгааны уялдаа холбоог ашиглах нь юу гэсэн үг вэ? Энэ нь afterClusterTime параметрийг харуулах зорилготой юм. Үүнгүйгээр энэ нь ямар ч байсан үнэ цэнийг дамжуулах болно. Хов жив 3.6 хувилбараас эхлэн үргэлж ажилладаг.
Хэрэв бид байнгын гарын үсгийг үлдээх юм бол энэ нь бидний хандлага, шаардлагад нийцэхгүй байгаа онцлог шинж чанаргүй байсан ч системийг удаашруулна. Тэгэхээр бид юу хийсэн бэ?
Үүнийг хурдан хий!
Энэ бол маш энгийн зүйл, гэхдээ заль мэх нь сонирхолтой юм - би үүнийг хуваалцах болно, магадгүй хэн нэгэн сонирхож магадгүй юм.
Бид гарын үсэг зурсан өгөгдлийг хадгалдаг хэштэй. Бүх өгөгдөл кэшээр дамждаг. Кэш нь тодорхой цагийг биш, харин Range-д гарын үсэг зурдаг. Зарим утга ирэхэд бид Range үүсгэж, сүүлийн 16 битийг нууж, энэ утгыг гарын үсэг зурна:
Ийм гарын үсгийг хүлээн авснаар бид системийг (харьцангуй) 65 мянган удаа хурдасгадаг. Энэ нь маш сайн ажилладаг: туршилт хийх үед бид дараалсан шинэчлэлт хийх үед цаг хугацаа үнэндээ 10 мянга дахин багассан. Тэд хоорондоо зөрчилдсөн үед энэ нь ажиллахгүй нь ойлгомжтой. Гэхдээ ихэнх практик тохиолдолд энэ нь ажилладаг. Range гарын үсгийг гарын үсэгтэй хослуулснаар аюулгүй байдлын асуудлыг шийдсэн.
Бид юу сурсан бэ?
Үүнээс бидний авсан сургамж:
- Бидэнд маш олон сонирхолтой зүйл байгаа тул материал, өгүүллэг, нийтлэл унших хэрэгтэй. Бид зарим функц дээр ажиллахдаа (ялангуяа одоо бид гүйлгээ хийсэн гэх мэт) уншиж, ойлгох хэрэгтэй. Энэ нь цаг хугацаа шаарддаг, гэхдээ энэ нь бидний хаана байгааг тодорхой харуулдаг учраас энэ нь үнэхээр хэрэгтэй юм. Бид шинэ зүйл гаргаагүй бололтой - бид зүгээр л найрлагыг нь авлаа.
Ерөнхийдөө эрдэм шинжилгээний бага хурал болоход сэтгэлгээний тодорхой ялгаа байдаг (жишээ нь Сигмон) - хүн бүр шинэ санаа руу анхаарлаа хандуулдаг. Манай алгоритмын шинэ зүйл юу вэ? Энд онцгой шинэ зүйл алга. Шинэлэг тал нь бид одоо байгаа арга барилыг хослуулсанд оршдог. Тиймээс хамгийн түрүүнд Лампартаас эхлээд сонгодог зохиолуудыг унших хэрэгтэй.
- Үйлдвэрлэлийн хувьд шаардлага нь огт өөр юм. Та нарын олонхи нь хийсвэр вакуум дахь "бөмбөрцөг" мэдээллийн сантай биш, харин бэлэн байдал, хоцрогдол, алдааг тэсвэрлэх зэрэг асуудалтай байдаг ердийн, бодит зүйлүүдтэй тулгарсан гэдэгт би итгэлтэй байна.
- Сүүлчийн зүйл бол бид өөр өөр санаануудыг харж, хэд хэдэн огт өөр нийтлэлийг нэг хандлагад нэгтгэх ёстой байв. Жишээлбэл, гарын үсэг зурах тухай санаа нь ерөнхийдөө Византийн бус хүмүүсийн хувьд зөвшөөрлийн протокол дотор, Византийн хувьд зөвшөөрлийн протоколоос гадуур байдаг Паксосын протоколыг авч үзсэн нийтлэлээс гаралтай ... Ерөнхийдөө бид яг ийм зүйл юм. хийж дуусгалаа.
Энд үнэхээр шинэ зүйл байхгүй! Гэхдээ бид бүгдийг хольсон даруйдаа... Өндөг, майонез, өргөст хэмхийг аль хэдийн зохион бүтээсэн учраас Оливье салатны жорыг утгагүй гэж хэлж байгаатай адил... Энэ бол нэг түүхийн тухай юм.
Би үүгээр дуусгая. Баярлалаа!
Асуултууд
Үзэгчдийн асуулт (цаашид Б гэх): - Тайлан өгсөнд баярлалаа, Михаил! Цагийн тухай сэдэв сонирхолтой. Та хов жив хэрэглэж байна. Хүн бүр өөрийн гэсэн цагтай, хүн бүр орон нутгийнхаа цагийг мэддэг гэж тэд хэлэв. Миний ойлгож байгаагаар манайд жолооч байгаа - жолоочтой олон үйлчлүүлэгч, асуулга төлөвлөгч, хэлтэрхий ч байж болно ... Хэрэв бид гэнэт зөрүү гарвал систем юунд хүргэдэг вэ: хэн нэгэн үүнийг хэн нэгэнд зориулагдсан гэж шийддэг. минутын өмнө, хэн нэгэн минутын дараа? Бид хаана дуусах вэ?
МТ: - Үнэхээр гайхалтай асуулт! Би зүгээр л хэлтэрхийний тухай ярихыг хүссэн юм. Хэрэв би асуултыг зөв ойлгосон бол бидэнд дараах нөхцөл байдал бий: хэлтэрхий 1 ба хэлтэрхий 2 байна, энэ хоёр хэлтэрхийнээс уншлага гардаг - тэдгээр нь хоорондоо зөрчилддөг, хоорондоо харьцдаггүй, учир нь тэдний мэддэг цаг хугацаа өөр, ялангуяа тэд oplogs-д байдаг цаг.
Shard 1 сая бичлэг хийсэн, shard 2 нь огтхон ч хийгээгүй, хүсэлт хоёр ширхэг ирсэн гэж бодъё. Эхнийх нь нэг сая гаруй дараалсан кластерийн цагтай. Ийм нөхцөлд миний тайлбарласнаар shard 2 хэзээ ч хариу өгөхгүй.
Дотор нь: – Тэд хэрхэн синхрончлогддог, нэг логик цагийг сонгохыг мэдэхийг хүссэн үү?
МТ: - Синхрончлоход маш хялбар. Shard, afterClusterTime түүн дээр ирж, тэр "Oplog"-д цаг олохгүй байх үед, ямар ч батлагдсан санаачилга. Энэ нь тэр цагаа гараараа энэ үнэ цэнэд өсгөдөг. Энэ нь энэ хүсэлтэд тохирох үйл явдал байхгүй гэсэн үг юм. Тэрээр энэ үйл явдлыг зохиомлоор бий болгож, улмаар Шалтгаан Тогтвортой болдог.
Дотор нь: – Үүний дараа сүлжээнд хаа нэгтээ алга болсон өөр үйл явдал түүнд тохиолдвол яах вэ?
МТ: – Шард нь ганц эзэн тул дахиж ирэхгүй байхаар зохион бүтээгдсэн. Хэрэв тэр аль хэдийн бүртгүүлсэн бол тэд ирэхгүй, харин дараа нь ирнэ. Ямар нэг зүйл хаа нэгтээ гацаж, дараа нь тэр бичихгүй, дараа нь эдгээр үйл явдал тохиолдох боломжгүй - учир шалтгааны уялдаа холбоо эвдэрсэн. Тэр бичихгүй бол тэд бүгд дараа нь ирэх ёстой (тэр тэднийг хүлээх болно).
Дотор нь: -Надад дараалалтай холбоотой хэд хэдэн асуулт байна. Шалтгаан уялдаа холбоо нь гүйцэтгэх шаардлагатай үйлдлүүдийн тодорхой дараалал байдаг гэж үздэг. Манай багцуудын аль нэг нь алга болвол яах вэ? Энд 10, 11 ... 12 алга болсон, бусад нь биелэхийг хүлээж байна. Бидний машин гэнэт үхсэн, бид юу ч хийж чадахгүй. Гүйцэтгэхээс өмнө хуримтлагдах дарааллын хамгийн дээд хэмжээ бий юу? Аль нэг төлөв алдагдсан тохиолдолд ямар үхлийн бүтэлгүйтэл тохиолддог вэ? Түүгээр ч зогсохгүй өмнөх төлөв байсаар байна гэж бичвэл ямар нэгэн байдлаар үүнээс эхлэх ёстой юм болов уу? Гэхдээ тэд түүнийг холдуулсангүй!
МТ: - Бас сайхан асуулт байна! Бид юу хийж байна вэ? MongoDB нь чуулга бичдэг, чуулга уншдаг гэсэн ойлголттой. Ямар тохиолдолд мессеж алга болох вэ? Бичих нь чуулга биш эсвэл уншсан нь чуулгагүй үед (ямар нэг төрлийн хог хаягдал наалдаж болно).
Шалтгаан уялдаатай байдлын тухайд томоохон туршилтын туршилт явуулсан бөгөөд үүний үр дүнд бичих, унших нь чуулга байхгүй тохиолдолд Шалтгаан уялдаа холбоог зөрчсөн тохиолдол гардаг. Чиний хэлсэн зүйл яг!
Бидний зөвлөгөө: Шалтгаан уялдаа холбоог ашиглахдаа хамгийн багадаа чуулгын уншлагыг ашигла. Энэ тохиолдолд чуулгын бүртгэл алдагдсан ч юу ч алдагдахгүй... Энэ нь ортогональ нөхцөл байдал юм: хэрэв хэрэглэгч өгөгдөл алдагдахыг хүсэхгүй байгаа бол тэр чуулгын бүртгэлийг ашиглах хэрэгтэй. Шалтгаан тууштай байдал нь бат бөх чанарыг баталгаажуулдаггүй. Бат бөх чанарыг хуулбарлах болон хуулбарлахтай холбоотой машин механизмаар баталгаажуулдаг.
Дотор нь: – Бидэнд зориулж хуваалт хийдэг (мастер биш, харин боол) жишээ үүсгэх үед энэ нь өөрийн машины Unix цаг эсвэл “мастер”-ын цаг дээр тулгуурладаг; Энэ нь анх удаагаа эсвэл үе үе синхрончлогддог уу?
МТ: -Би одоо тодруулъя. Shard (жишээ нь, хэвтээ хуваалт) - тэнд үргэлж анхдагч байдаг. Мөн хэлтэрхий нь "мастер"-тай байж болно, хуулбар байж болно. Гэхдээ хэлтэрхий нь ямар нэг домэйныг дэмжих ёстой (хэсэг нь Үндсэн хэсэгтэй) учраас бичлэгийг үргэлж дэмждэг.
Дотор нь: – Тэгэхээр бүх зүйл зөвхөн “эзэн”-ээс шалтгаална гэж үү? Мастер цаг үргэлж ашиглагддаг уу?
МТ: - Тийм ээ. Та "мастер", "Оплог" руу ороход цагийн зүү цохиж байна гэж дүрслэн хэлж болно.
Дотор нь: – Бидэнд холбогддог үйлчлүүлэгч байгаа бөгөөд цаг хугацааны талаар юу ч мэдэх шаардлагагүй юу?
МТ: - Та юу ч мэдэх шаардлагагүй! Хэрэв бид энэ нь үйлчлүүлэгч дээр хэрхэн ажилладаг талаар ярих юм бол: үйлчлүүлэгч Шалтгаан уялдаа холбоог ашиглахыг хүсвэл сесс нээх хэрэгтэй. Одоо бүх зүйл тэнд байна: сесс доторх гүйлгээ, эрх олж авах... Сесс гэдэг нь үйлчлүүлэгчтэй тохиолдох логик үйл явдлуудын дараалал юм.
Хэрэв тэр энэ сессийг нээж, тэнд учир шалтгааны уялдаа холбоог хүсч байгаагаа хэлвэл (хэрэв сесс анхдагчаар Causal нийцтэй байхыг дэмждэг бол) бүх зүйл автоматаар ажиллана. Жолооч энэ цагийг санаж, шинэ мессеж хүлээн авахдаа үүнийг нэмэгдүүлнэ. Өмнөх нь өгөгдөл буцааж өгсөн серверээс ямар хариу ирснийг санаж байна. Дараагийн хүсэлт нь afterCluster("үүнээс их хугацаа") агуулна.
Үйлчлүүлэгч юу ч мэдэх шаардлагагүй! Энэ нь түүний хувьд бүрэн ойлгомжгүй юм. Хэрэв хүмүүс эдгээр функцийг ашиглавал тэд юу хийж чадах вэ? Нэгдүгээрт, та хоёрдогч хувилбаруудыг аюулгүйгээр уншиж болно: та анхдагч руу бичиж, газарзүйн хувьд хуулбарлагдсан хоёрдогч хувилбараас уншиж, ажиллаж байгаа эсэхийг шалгаарай. Үүний зэрэгцээ, анхдагч дээр бичигдсэн сешнүүдийг хоёрдогч руу шилжүүлж болно, өөрөөр хэлбэл та нэг сешн биш, хэд хэдэн сешн ашиглаж болно.
Дотор нь: – Тооцоолох шинжлэх ухааны шинэ давхарга – CRDT (Зөрчилгүй хуулбарласан өгөгдлийн төрлүүд) нь “Эцсийн тууштай байдал” сэдэвтэй хүчтэй холбоотой. Та эдгээр төрлийн өгөгдлийг мэдээллийн санд нэгтгэх талаар бодож үзсэн үү, энэ талаар юу хэлэх вэ?
МТ: - Сайн асуулт! CRDT нь бичих зөрчилдөөнийг ойлгодог: MongoDB-д ганц мастер.
Дотор нь: -Дэвопуудаас асуух зүйл байна. Бодит ертөнцөд Византийн бүтэлгүйтэл тохиолдож, хамгаалагдсан периметрийн доторх хорон муу хүмүүс протокол руу орж, гар урлалын багцыг тусгай аргаар илгээж эхлэхэд ийм иезуитийн нөхцөл байдал байдаг уу?
МТ: - Периметрийн доторх муу хүмүүс Трояны морьтой адил юм! Периметрийн доторх бузар муу хүмүүс олон муу зүйлийг хийж чадна.
Дотор нь: – Бүдүүнчлэн хэлэхэд, серверт нүх үлдээх нь зааны амьтны хүрээлэнг байрлуулж, бүхэл бүтэн бөөгнөрөлийг үүрд сүйрүүлэх нь тодорхой байна ... Гараар сэргээхэд цаг хугацаа шаардагдана... Үүнийг зөөлөн хэлэхэд, буруу. Нөгөөтэйгүүр, энэ нь сонирхолтой юм: бодит амьдрал дээр, практик дээр байгалиасаа ижил төстэй дотоод халдлагууд тохиолдох нөхцөл байдал байдаг уу?
МТ: – Би аюулгүй байдлын зөрчилтэй бодит амьдрал дээр ховор тулгардаг тул ийм зөрчил гарсан эсэхийг би хэлж чадахгүй. Гэхдээ хэрэв бид хөгжлийн философийн талаар ярих юм бол бид ингэж боддог: аюулгүй байдлыг хангадаг залуусыг хангадаг периметртэй - энэ бол цайз, хана; мөн периметрийн дотор та хүссэн бүхнээ хийж болно. Зөвхөн үзэх чадвартай хэрэглэгчид байгаа нь ойлгомжтой бөгөөд лавлахыг устгах чадвартай хэрэглэгчид байдаг.
Эрхээсээ шалтгаалаад хэрэглэгчдийн учруулсан хохирол нь хулгана, заан ч байж болно. Бүрэн эрхтэй хэрэглэгч юу ч хийж чадах нь ойлгомжтой. Хязгаарлагдмал эрхтэй хэрэглэгч нь хамаагүй бага хохирол учруулж болзошгүй. Ялангуяа энэ нь системийг эвдэж чадахгүй.
Дотор нь: – Хамгаалагдсан периметрт хэн нэгэн серверийг бүрэн устгахын тулд серверт гэнэтийн протокол үүсгэхийг оролдсон бөгөөд хэрэв та азтай бол бүхэл бүтэн кластер ... Энэ нь хэзээ нэгэн цагт "сайн" болж байна уу?
МТ: "Би ийм зүйлийн талаар хэзээ ч сонсож байгаагүй." Та ийм байдлаар серверийг сүйрүүлж болно гэдэг нь нууц биш юм. Дотроо бүтэлгүйтэх, протоколд харьяалагдах, зурваст ийм зүйл бичиж чадах эрх бүхий хэрэглэгч байх ... Үнэндээ энэ нь боломжгүй, учир нь үүнийг баталгаажуулах болно. Хүсээгүй хэрэглэгчдэд энэ баталгаажуулалтыг идэвхгүй болгох боломжтой - тэгвэл энэ нь тэдний асуудал юм; Тэд барагцаагаар ханыг өөрсдөө сүйтгэж, тэнд заан гишгүүлэхээр түлхэж болно... Гэхдээ ер нь чи засварчин хувцаслаж, ирээд сугалж болно!
Дотор нь: - Мэдээлэл өгсөнд баярлалаа. Сергей (Яндекс). Mong-д Replica Set дэх санал өгөх гишүүдийн тоог хязгаарласан тогтмол байдаг бөгөөд энэ тогтмол нь 7 (долоо) юм. Энэ яагаад тогтмол байдаг вэ? Энэ нь яагаад нэг төрлийн параметр биш юм бэ?
МТ: – Бидэнд 40 зангилаа бүхий Replica Sets бий. Дандаа олонхи байдаг. Аль хувилбарыг нь мэдэхгүй...
Дотор нь: – Replica Set дээр та санал өгөх эрхгүй гишүүдийг ажиллуулж болох ч хамгийн ихдээ 7 санал өгөх эрхтэй гишүүн байна. Хэрэв манай Replica Set 3 дата төвд тархсан бол энэ тохиолдолд бид хэрхэн хаагдахыг даван туулах вэ? Нэг дата төв амархан унтарч, өөр машин унаж болно.
МТ: - Энэ нь тайлангийн хамрах хүрээнээс арай хэтэрсэн байна. Энэ бол ерөнхий асуулт юм. Магадгүй би чамд дараа нь энэ тухай хэлэх байх.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com