Shopify memindahkan tempahan inventori ke MySQL

Apa yang diliputi video ini

• Model pembilang kuantiti Redis lama mengendalikan kekerapan, tetapi pembersihan tempahan dan kemas kini lejar MySQL tidak dapat berkongsi satu transaksi atomik tempatan tunggal.
• Penggantian menggunakan satu baris bagi setiap unit yang tersedia dalam kolam yang dihadkan pada 1,000 setiap kombinasi item/lokasi. Kolam kosong boleh mencetuskan pengisian semula sebaris dengan permintaan serentak menunggu di belakang kunci pengisian semula.
• Kunci utama komposit ialah (shop_id, inventory_item_id, inventory_group_id, id). Shopify mengurangkan overhed kunci dalam prototaipnya dan menggunakan READ COMMITTED untuk mengelakkan kunci jurang yang menyekat pengisian semula.
• Tempahan memadamkan baris kolam sebelum memasukkan rekod tempahan. Komit melepaskan kunci pangkalan data sementara pegangan yang disimpan kekal merentasi pembayaran; pembayaran yang berjaya menuntut lejar dan mengalih keluar tempahan dalam transaksi atomik kemudian.
• Dokumen MySQL SKIP LOCKED sebagai pandangan tidak konsisten yang tidak termasuk baris yang dikunci. Ia tidak mewujudkan kiraan stok yang lengkap atau giliran yang adil, hanya terpakai pada kunci peringkat baris dan tidak selamat untuk replikasi berasaskan pernyataan.
• Contoh sumber termasuk expires_at, tetapi Shopify tidak mendokumenkan algoritma pembersihan tamat tempoh MySQL. Cawangan pelepasan/tamat tempoh video adalah keperluan kitaran hayat penjelasan.
• Masa pegangan sambungan dalam kod pembayaran lain adalah kesesakan daya pemprosesan terakhir. Shopify menulis bayangan kedua-dua sistem, membandingkan hasil dan beralih secara beransur-ansur dengan pemulihan suis pembunuh Redis.

Transkrip terjemahan

Diterjemahkan daripada penceritaan asal Bahasa Inggeris. Audio dan kapsyen yang tersedia dikawal oleh YouTube.

Mengapa memindahkan tempahan ke MySQL?

0:00 Pembayaran memerlukan Redis untuk kekal pantas. Shopify memindahkan tempahan inventori ke MySQL menggunakan satu baris bagi setiap unit dalam kolam terhad. Mengapa memilih MySQL? Bagaimana anda melangkau kunci dengan selamat? Ini ialah The Daily Diff, di sebalik tabir. Dan mengapa pertanyaan pantas masih mencapai hadnya? Shopify ialah platform perdagangan untuk menjual secara dalam talian dan secara peribadi. Redis ialah stor data dalam memori.

0:21 MySQL ialah pangkalan data hubungan, dan Shopify sudah menyimpan lejar inventorinya di sana. Tempahan memegang stok secara ringkas semasa pembeli membayar.

Mengapa dua stor berisiko?

0:29 Model Redis mereka mengurangkan pembilang item. Menuntut pesanan berbayar bermakna mengemas kini lejar MySQL dan membersihkan Redis. Penulisan berasingan itu boleh menyebabkan stok dijual dua kali atau tidak tersedia apabila ia sepatutnya boleh dijual. Model lama juga tidak mempunyai kesedaran lokasi. Penggantian mesti memilih stok dari suatu tempat yang boleh memenuhi pesanan. Gudang di benua yang salah menjadikan entri pangkalan data yang sangat baik dan janji penghantaran yang teruk. Percubaan MySQL sebelum ini menggunakan baris kuantiti, jadi pembayaran yang bersaing beratur di

Apa yang menjadi unit boleh dikunci?

0:56 kunci yang sama. Bayangkan tali baldu di sekeliling sel hamparan. Menambah lebih banyak pekerja hanya memanjangkan barisan. Shopify menukar objek boleh dikunci. Setiap unit yang tersedia mendapat barisnya sendiri. Bacaan kunci melangkau unit yang lain transaksi pegang dan memilih unit layak yang lain. Pekerja yang berbeza boleh memperoleh baris yang berbeza, sementara pembilang panas kekal tidak mengganggu mereka.

Apa yang berlaku apabila kolam kosong?

1:15 Kolam itu dihadkan pada seribu baris bagi setiap item dan lokasi. Pengisian semula diambil dari lejar. Jika ia kosong, laluan tempahan mengisi semula secara sebaris, dengan permintaan yang bersaing menunggu di belakang kunci pengisian semula. Kolam kosong tidak bermakna gudang kosong. Tempahan memadamkan baris kolam yang dipilih, kemudian memasukkan rekod tempahan dalam transaksi. Komit melepaskan kunci pangkalan data.

1:35 Rollback membatalkan perubahan. Tempahan kekal selepas pemprosesan pembayaran sebagai keadaan yang disimpan. Pembayaran yang berjaya menuntut lejar dan mengalih keluar tempahan secara atomik. Kunci pangkalan data tidak perlu menjaga borang pembayaran. Kunci utama komposit mereka bermula dengan kedai, item, kumpulan, kemudian identiti unit. Memadankan carian mengurangkan penguncian indeks dalam prototaip mereka. Mereka juga menggunakan "read committed" untuk mengelakkan kunci jurang yang menyekat

1:57 pengisian semula kolam, dan susunan jadual yang konsisten untuk mencegah menunggu bulat. Contoh yang diterbitkan merekodkan masa tamat tempoh. Pembayaran yang ditinggalkan memerlukan stok dilepaskan akhirnya, atau troli beli-belah menjadi tuan tanah. Catatan Shopify membiarkan algoritma pembersihan itu tidak dinyatakan, jadi rajah ini menunjukkan keperluan kitaran hayat. Inilah masalahnya.

Apa yang SKIP LOCKED tinggalkan?

2:14 Langkau terkunci mengecualikan baris terkunci, jadi manual memanggil hasilnya sebagai pandangan tidak konsisten. Ia tidak menyediakan kiraan stok yang lengkap mahupun giliran yang adil. Kekalkan keputusan ketersediaan dan peraturan pengisian semula di sekelilingnya.

Di mana siling sebenar?

2:26 Dan siling itu? Kod pembayaran lain memegang sambungan pangkalan data terlalu lama. Shopify menandai pemanggil dan mengukur masa pegangan sambungan, kemudian membersihkan laluan pembayaran dan meninjau semula kekerapan benang. Pertanyaan pantas masih boleh beratur di luar pertanyaan.

Mengapa saya menghantar reka bentuk ini?

2:38 Mereka menulis bayangan kedua-dua sistem dengan Redis yang berkuasa, membandingkan hasil, kemudian beralih secara beransur-ansur dengan suis pembunuh. Keputusan saya ialah SHIP IT. Saya akan menghantar had transaksi yang dikongsi dan pelancaran yang boleh digulir balik itu, dengan keseluruhan laluan pembayaran diinstrumentasikan. Ada soalan tentang ini? Letakkan di dalam komen. Dan itulah perbezaan untuk hari ini.

2:54 Saya Niko dari Axrisi. Gabungkan dengan bertanggungjawab.

Sumber

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