Shopify бараа материалын нөөцлөлтийг MySQL руу шилжүүлсэн

Энэ видео юуг хамардаг

• Хуучин Redis тоон тоолуурын загвар нь нэгэн зэрэг ажиллах боломжийг хангаж байсан ч нөөцлөлтийг цэвэрлэх, MySQL-ийн бүртгэлийг шинэчлэх нь нэг дотоод атомын гүйлгээг хуваалцах боломжгүй байв.
• Орлуулагч нь бараа/байршлын хослолд 1,000-аар хязгаарлагдсан санд байгаа нэг нэгжид нэг мөр ашигладаг. Хоосон сан нь нөхөн хангалтын түгжээний ард хүлээж буй нэгэн зэрэг хүсэлтүүдийн хамт шууд нөхөн хангалтыг өдөөж болно.
• Нийлмэл үндсэн түлхүүр нь (shop_id, inventory_item_id, inventory_group_id, id) юм. Shopify өөрийн прототип дэх түгжээний нэмэлт зардлыг бууруулж, нөхөн хангалтыг хаасан завсрын түгжээнээс зайлсхийхийн тулд READ COMMITTED-г ашигласан.
• Нөөцлөлт нь нөөцлөлтийн бүртгэлийг оруулахаас өмнө сангийн мөрүүдийг устгадаг. Баталгаажуулалт нь мэдээллийн сангийн түгжээг сулладаг бол хадгалагдсан барьцаа нь төлбөрийн хугацаанд хадгалагдана; амжилттай төлбөр нь бүртгэлийг баталгаажуулж, дараагийн атомын гүйлгээнд нөөцлөлтийг устгадаг.
• MySQL нь SKIP LOCKED-г түгжигдсэн мөрүүдийг орхигдуулдаг, тууштай бус харагдац гэж баримтжуулсан байдаг. Энэ нь бүрэн нөөцийн тоо эсвэл шударга ээлж дарааллыг тогтоодоггүй, зөвхөн мөрийн түвшний түгжээнд хамаардаг бөгөөд мэдэгдэлд суурилсан давхардуулалтад аюулгүй биш юм.
• Эх сурвалжийн жишээнд expires_at орсон боловч Shopify MySQL-ийн хугацаа дуусахыг цэвэрлэх алгоритмыг баримтжуулаагүй байна. Видеоны хувилбар/хугацаа дуусах салаа нь тайлбарлах амьдралын мөчлөгийн шаардлага юм.
• Бусад шалгах кодын холболтын барих хугацаа нь эцсийн гүйцэтгэлийн саад байсан. Shopify хоёр системийг зэрэг бичиж, үр дүнг харьцуулж, Redis-ийн унтраалгын нөөцтэйгээр аажмаар шилжүүлсэн.

Орчуулсан бичлэг

Англи хэл дээрх эх хувилбараас орчуулсан. Боломжтой дуу болон хадмал орчуулгыг YouTube хянадаг.

Нөөцлөлтийг яагаад MySQL руу шилжүүлэв?

0:00 Гүйлгээ хурдан байхын тулд Redis хэрэгтэй. Shopify бараа материалын нөөцлөлтийг MySQL руу шилжүүлж, нэг нэгжид нэг мөр ашигласан хязгаарлагдмал сан. Яагаад MySQL-г сонгосон бэ? Түгжээг хэрхэн аюулгүйгээр алгасах вэ? Энэ бол The Daily Diff, доторх нууц. Тэгээд яагаад хурдан асуултууд таазанд тулсаар байсан бэ? Shopify бол онлайн болон биечлэн худалдаа хийх худалдааны платформ. Redis бол санах ойн өгөгдлийн сан юм.

0:21 MySQL бол харилцааны мэдээллийн сан бөгөөд Shopify аль хэдийн бараа материалын бүртгэлээ тэнд хадгалж байсан. Нөөцлөлт нь худалдан авагч төлбөрөө төлж байх хооронд барааг түр хугацаанд барьж байдаг.

Яагаад хоёр дэлгүүр эрсдэлтэй байсан бэ?

0:29 Тэдний Redis загвар нь барааны тоолуурыг бууруулдаг байсан. Төлбөр төлөгдсөн захиалгыг баталгаажуулах нь MySQL-ийн бүртгэлийг шинэчилж, Redis-г цэвэрлэхийг хэлнэ. Тусдаа бичилтүүд нь барааг хоёр удаа борлуулсан эсвэл худалдаалагдах ёстой байхад боломжгүй болгож орхиж болно. Хуучин загварт байршлын мэдээлэл дутагдаж байсан. Орлуулагч нь захиалгыг гүйцэтгэх боломжтой газраас барааг сонгох ёстой. Буруу тивд байрлах агуулах нь маш сайн мэдээллийн сангийн бичилт болдог ч аймшигтай хүргэлтийн амлалт болдог. Өмнөх MySQL-ийн оролдлогууд нь тоо хэмжээний мөрийг ашигласан тул өрсөлдөгч шалгах үйл явцууд

Түгжих боломжтой нэгж юу болох вэ?

0:56 нэг түгжээнд дараалал үүсгэсэн. Хүснэгтийн нүдний эргэн тойрон дахь хилэн олс гэж бод. Илүү олон ажилтан нэмэх нь зүгээр л дарааллыг уртасгана. Shopify түгжих боломжтой объектыг өөрчилсөн. Боломжтой нэгж бүр өөрийн гэсэн мөртэй болдог. Түгжих уншилт нь өөр гүйлгээний барьж буй нэгжүүдийг алгасаж, бусад зохих нэгжүүдийг сонгодог. Өөр өөр ажилчид өөр өөр мөрүүдийг эзэмшиж чаддаг. халуун тоолуур нь тэдний замд саад болохгүй.

Сан хоосорвол юу болдог вэ?

1:15 Уг сан нь бараа, байршил тус бүрт мянган мөрөөр хязгаарлагдсан. Нөхөн хангалтыг бүртгэлээс авдаг. Хэрэв хоосорвол нөөцлөлтийн зам нь нөхөн хангалтын түгжээний ард хүлээж буй өрсөлдөгч хүсэлтүүдийн хамт шууд нөхөн хангана. Хоосон сан гэдэг нь хоосон агуулах гэсэн үг биш. Нөөцлөлт нь сонгогдсон сангийн мөрүүдийг устгаж, дараа нь гүйлгээнд нөөцлөлтийн бүртгэлүүдийг оруулдаг. Баталгаажуулалт нь мэдээллийн сангийн түгжээг сулладаг.

1:35 Буцаах нь өөрчлөлтүүдийг буцаадаг. Нөөцлөлт нь төлбөрийн боловсруулалтыг хадгалагдсан төлөв байдлаар давдаг. Амжилттай төлбөр нь бүртгэлийг баталгаажуулж, нөөцлөлтийг атомоор устгадаг. Мэдээллийн сангийн түгжээ нь төлбөрийн маягтыг хэзээ ч хянах шаардлагагүй. Тэдний нийлмэл үндсэн түлхүүр нь дэлгүүр, бараа, бүлэг, дараа нь нэгжийн таних тэмдгээр эхэлдэг. Хайлтанд тааруулах нь тэдний прототип дэх индексийн түгжээг бууруулсан. Тэд мөн уншсан өгөгдлөө баталгаажуулахын тулд READ COMMITTED-г ашигладаг бөгөөд энэ нь сангийн

1:57 нөхөн хангалтыг хаасан завсрын түгжээнээс зайлсхийх, мөн тойрог хүлээлтээс сэргийлэхийн тулд тогтвортой хүснэгтийн дарааллыг ашигладаг. Нийтлэгдсэн жишээ нь хугацаа дуусах хугацааг бүртгэсэн. Орхигдсон төлбөрүүд эцэст нь барааг суллах шаардлагатай, эс тэгвээс худалдааны сагс түрээслэгч болдог. Shopify-ийн бичлэгт тэр цэвэрлэгээний алгоритм тодорхойлогдоогүй. Тиймээс энэ диаграм нь амьдралын мөчлөгийн шаардлагыг харуулсан. Энд гол асуудал байна.

SKIP LOCKED юуг орхидог вэ?

2:14 Skip locked нь түгжигдсэн мөрүүдийг хасдаг тул гарын авлага нь үр дүнгээ тууштай бус харагдац гэж нэрлэдэг. Энэ нь бүрэн нөөцийн тоо эсвэл шударга ээлж дарааллыг аль алиныг нь өгдөггүй. Боломжтой байдлын шийдвэр болон нөхөн хангалтын дүрмүүдийг түүний эргэн тойронд хадгал.

Жинхэнэ тааз хаана байсан бэ?

2:26 Тэр таазны тухайд? Бусад шалгах код нь мэдээллийн сангийн холболтуудыг хэт удаан барьж байсан. Shopify дуудагчдыг тэмдэглэж, холболтын барих хугацааг хэмжиж, дараа нь шалгах замыг цэвэрлэж, нэгэн зэрэг ажиллах боломжийг эргэн харсан. Хурдан асуултууд асуултын гадна дараалал үүсгэж болно.

Би яагаад энэ загварыг хэрэгжүүлэх ёстой вэ?

2:38 Тэд Redis-ийг эрх мэдэлтэй байлгаж хоёр системийг зэрэг бичиж, үр дүнг харьцуулж, дараа нь унтраалгын товчлууртайгаар аажмаар шилжсэн. Миний шийдвэр бол SHIP IT. Би хуваалцсан гүйлгээний хил хязгаар болон буцаах боломжтой хэрэгжүүлэлтийг бүх шалгах замыг хэрэгсэл болгон ашиглах байсан. Энэ талаар асуулт байна уу? Сэтгэгдэл хэсэгт бичээрэй. Энэ бол өнөөдрийн "The Daily Diff" байлаа.

2:54 Би Axrisi-ийн Нико. Хариуцлагатай нэгтгээрэй.

Эх сурвалжууд

1. We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
2. Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
3. MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
4. MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
5. What Is Shopify and How Does It Work?Shopify
6. Redis quick startsRedis documentation
7. What is MySQL?Oracle / MySQL Reference Manual