Shopify ຍ້າຍການຈອງສິນຄ້າຄົງຄັງເຂົ້າໄປໃນ MySQL

ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

• ຮູບແບບເຄື່ອງນັບປະລິມານ Redis ເກົ່າໄດ້ຈັດການການພ້ອມກັນ, ແຕ່ການລ້າງການຈອງ ແລະ ການອັບເດດບັນຊີລາຍການ MySQL ບໍ່ສາມາດແບ່ງປັນທຸລະກຳປະລໍາມະນູທ້ອງຖິ່ນດຽວໄດ້.
• ການທົດແທນໃຊ້ຫນຶ່ງແຖວຕໍ່ຫນຶ່ງຫົວໜ່ວຍທີ່ມີຢູ່ໃນກຸ່ມທີ່ຈຳກັດຢູ່ທີ່ 1,000 ຕໍ່ການປະສົມປະສານຂອງສິນຄ້າ/ສະຖານທີ່. ກຸ່ມຂໍ້ມູນທີ່ຫວ່າງເປົ່າສາມາດກະຕຸ້ນການເຕີມເຕັມແບບ inline ດ້ວຍຄຳຮ້ອງຂໍທີ່ພ້ອມກັນລໍຖ້າຢູ່ເບື້ອງຫຼັງການລັອກການເຕີມເຕັມ.
• ລະຫັດຫຼັກປະກອບແມ່ນ (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 ກຸ່ມຂໍ້ມູນນັ້ນຖືກຈຳກັດຢູ່ທີ່ໜຶ່ງພັນແຖວຕໍ່ລາຍການ ແລະສະຖານທີ່. ການເຕີມເຕັມດຶງມາຈາກບັນຊີລາຍການ. ຖ້າມັນຫວ່າງເປົ່າ, ເສັ້ນທາງ ການຈອງຈະເຕີມເຕັມແບບ inline, ດ້ວຍຄຳຮ້ອງຂໍທີ່ແຂ່ງຂັນກັນ ລໍຖ້າຢູ່ເບື້ອງຫຼັງການລັອກການເຕີມເຕັມ. ກຸ່ມຂໍ້ມູນທີ່ຫວ່າງເປົ່າບໍ່ໄດ້ໝາຍເຖິງສາງທີ່ຫວ່າງເປົ່າ. ການຈອງລຶບແຖວຂໍ້ມູນທີ່ເລືອກ, ຈາກນັ້ນໃສ່ບັນທຶກການຈອງໃນ ທຸລະກໍາ. ການຢືນຢັນຈະປ່ອຍການລັອກຖານຂໍ້ມູນ.

1:35 ການຍົກເລີກການປ່ຽນແປງ. ການຈອງຍັງຄົງຢູ່ຕໍ່ການປະມວນຜົນການຈ່າຍເງິນເປັນສະຖານະທີ່ເກັບໄວ້. ການຈ່າຍເງິນທີ່ສໍາເລັດຈະຮຽກຮ້ອງບັນຊີລາຍການແລະລຶບການຈອງແບບປະລໍາມະນູ. ການລັອກຖານຂໍ້ມູນບໍ່ຈໍາເປັນຕ້ອງເຝົ້າແບບຟອມການຈ່າຍເງິນ. ລະຫັດຫຼັກປະກອບຂອງພວກເຂົາເລີ່ມຕົ້ນດ້ວຍຮ້ານຄ້າ, ສິນຄ້າ, ກຸ່ມ, ຫຼັງຈາກນັ້ນລະຫັດຫົວໜ່ວຍ. ການຈັບຄູ່ການຄົ້ນຫາຫຼຸດຜ່ອນການລັອກດັດສະນີໃນຕົວແບບຂອງພວກເຂົາ. ພວກເຂົາຍັງໃຊ້ການອ່ານທີ່ຖືກຢືນຢັນເພື່ອຫຼີກເວັ້ນການລັອກຊ່ອງຫວ່າງທີ່ຂັດຂວາງການເຕີມເຕັມກຸ່ມຂໍ້ມູນ,

1:57 ແລະຄໍາສັ່ງຕາຕະລາງທີ່ສອດຄ່ອງກັນເພື່ອປ້ອງກັນການລໍຖ້າແບບວົງຈອນ. ຕົວຢ່າງທີ່ເຜີຍແຜ່ບັນທຶກເວລາໝົດອາຍຸ. ການຈ່າຍເງິນທີ່ຖືກປະຖິ້ມຕ້ອງການການປ່ອຍສິນຄ້າຄົງຄັງໃນທີ່ສຸດ, ຖ້າບໍ່ດັ່ງນັ້ນກະຕ່າສິນຄ້າຈະກາຍເປັນ ເຈົ້າຂອງເຮືອນ. ຂໍ້ຄວາມຂອງ Shopify ປະຖິ້ມສູດການຄິດໄລ່ການລຶບລ້າງນັ້ນບໍ່ໄດ້ລະບຸ, ດັ່ງນັ້ນແຜນວາດນີ້ສະແດງໃຫ້ເຫັນຂໍ້ກຳນົດວົງຈອນຊີວິດ. ນີ້ແມ່ນບັນຫາ.

SKIP LOCKED ປະໄວ້ຫຍັງແດ່?

2:14 Skip locked ຍົກເວັ້ນແຖວທີ່ຖືກລັອກ, ດັ່ງນັ້ນຄູ່ມືຈຶ່ງເອີ້ນຜົນໄດ້ຮັບຂອງມັນວ່າເປັນມຸມມອງທີ່ບໍ່ສອດຄ່ອງກັນ. ມັນບໍ່ໄດ້ໃຫ້ຈໍານວນຫຼັກຊັບທີ່ສົມບູນຫຼືການປ່ຽນແປງທີ່ຍຸດຕິທໍາ. ຮັກສາການຕັດສິນໃຈທີ່ມີຢູ່ແລະກົດລະບຽບການເຕີມເຕັມຢູ່ອ້ອມຮອບມັນ.

ເພດານທີ່ແທ້ຈິງຢູ່ໃສ?

2:26 ແລະເພດານນັ້ນ? ລະຫັດການສັ່ງຊື້ອື່ນໆກໍາລັງຖືການເຊື່ອມຕໍ່ຖານຂໍ້ມູນດົນເກີນໄປ. Shopify ໄດ້ຕິດປ້າຍຜູ້ໂທ ແລະວັດແທກເວລາການຖືຄອງການເຊື່ອມຕໍ່, ຈາກນັ້ນໄດ້ລ້າງເສັ້ນທາງການສັ່ງຊື້ ແລະທົບທວນຄືນການພ້ອມກັນຂອງ thread. ການສອບຖາມໄວສາມາດຍັງຖືກຈັດລຽງຢູ່ນອກການສອບຖາມໄດ້.

ເປັນຫຍັງຂ້ອຍຈຶ່ງຈະສົ່ງການອອກແບບນີ້?

2:38 ພວກເຂົາໄດ້ຂຽນເງົາທັງສອງລະບົບດ້ວຍ Redis ທີ່ເປັນທາງການ, ປຽບທຽບຜົນໄດ້ຮັບ, ຈາກນັ້ນປ່ຽນແປງເທື່ອລະກ້າວດ້ວຍປຸ່ມປິດ. ຄໍາຕັດສິນຂອງຂ້ອຍຄື SHIP IT. ຂ້ອຍຈະຈັດສົ່ງຂອບເຂດທຸລະກໍາທີ່ແບ່ງປັນແລະການນໍາໃຊ້ທີ່ສາມາດຍົກເລີກໄດ້ນັ້ນ, ໂດຍມີເສັ້ນທາງການສັ່ງຊື້ທັງໝົດຖືກກວດສອບ. ມີຄໍາຖາມກ່ຽວກັບເລື່ອງນີ້ບໍ? ໃສ່ໄວ້ໃນຄໍາເຫັນ. ແລະນັ້ນຄື diff ສໍາລັບມື້ນີ້.

2:54 ຂ້ອຍຄື Niko ຈາກ 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