# Shopify បានផ្លាស់ប្តូរការកក់ទុកសារពើភ័ណ្ឌទៅក្នុង MySQL

Published: 2026-10-10

Shopify បានផ្លាស់ប្តូរប្រព័ន្ធកក់ទុកសារពើភ័ណ្ឌរបស់ខ្លួនពី Redis ទៅក្នុងមូលដ្ឋានទិន្នន័យ MySQL ដែលបានរក្សាសៀវភៅបញ្ជីសារពើភ័ណ្ឌរួចហើយ។ អាងដែលកំណត់ដោយជួរដេកឯកតានីមួយៗដែលអាចចាក់សោបាន អនុញ្ញាតឱ្យការទូទាត់ប្រាក់ដំណាលគ្នាប្រើ SKIP LOCKED ដើម្បីជ្រើសរើសឯកតាដែលមានសិទ្ធិផ្សេងៗគ្នា។ ការរចនានេះក៏ពឹងផ្អែកលើព្រំដែនប្រតិបត្តិការ ប្លង់គន្លឹះបឋម វិធានបំពេញបន្ថែម និងការសង្កេតមើលពេលវេលាកាន់កាប់ការតភ្ជាប់នៅទូទាំងការទូទាត់ប្រាក់។

Canonical: https://thedailydiff.dev/km/video/shopify-reservation-locks/

## អ្វីដែលវីដេអូនេះគ្របដណ្ដប់

- ម៉ូដែលរាប់ចំនួនចាស់របស់ 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 kill-switch។

## ជំពូក

- 0:00 ហេតុអ្វីត្រូវផ្លាស់ប្តូរការកក់ទុកទៅក្នុង MySQL?
- 0:29 ហេតុអ្វីបានជាហាងពីរប្រថុយប្រថាន?
- 0:52 តើអ្វីទៅជាឯកតាដែលអាចចាក់សោបាន?
- 1:15 តើមានអ្វីកើតឡើងនៅពេលដែលអាងទទេ?
- 2:14 តើ SKIP LOCKED ទុកអ្វីខ្លះ?
- 2:26 តើពិដានពិតប្រាកដនៅឯណា?
- 2:38 ហេតុអ្វីខ្ញុំត្រូវ SHIP IT ការរចនានេះ?

## កំណត់ត្រាដែលបានបកប្រែ

បកប្រែចេញពីការនិទានដើមជាភាសាអង់គ្លេស។ សំឡេង និងចំណងជើងរងដែលមានគឺស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់ 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 Rollback លុបចោលការផ្លាស់ប្តូរ។ ការកក់ទុកនៅតែបន្តដំណើរការទូទាត់ជាស្ថានភាពដែលបានរក្សាទុក។ ការទូទាត់ជោគជ័យទាមទារសៀវភៅបញ្ជី និងលុបការកក់ទុកដោយស្វ័យប្រវត្តិ។ សោមូលដ្ឋានទិន្នន័យមិនចាំបាច់មើលទម្រង់ការទូទាត់ទេ។ គន្លឹះបឋមផ្សំរបស់ពួកគេចាប់ផ្តើមដោយហាង ធាតុ ក្រុម បន្ទាប់មកអត្តសញ្ញាណឯកតា។ ការផ្គូផ្គងការស្វែងរកបានកាត់បន្ថយការចាក់សោលិបិក្រមនៅក្នុងគំរូដើមរបស់ពួកគេ។ ពួកគេក៏ប្រើ Read Committed ដើម្បីជៀសវាងការចាក់សោចន្លោះដែលរារាំងអាង

1:57 ការបំពេញបន្ថែម និងលំដាប់តារាងស៊ីសង្វាក់គ្នាដើម្បីការពារការរង់ចាំជារង្វង់។ ឧទាហរណ៍ដែលបានបោះពុម្ពកត់ត្រាពេលវេលាផុតកំណត់។ ការទូទាត់ដែលបោះបង់ចោលត្រូវការស្តុកត្រូវបានចេញផ្សាយនៅទីបំផុត ឬរទេះទិញទំនិញក្លាយជា ម្ចាស់ដី។ ប្រកាសរបស់ Shopify ទុកក្បួនដោះស្រាយការសម្អាតនោះមិនបានបញ្ជាក់ ដូច្នេះដ្យាក្រាមនេះបង្ហាញពីតម្រូវការវដ្តជីវិត។ នេះជាបញ្ហា។

### តើ SKIP LOCKED ទុកអ្វីខ្លះ?

2:14 Skip Locked មិនរាប់បញ្ចូលជួរដេកដែលបានចាក់សោ ដូច្នេះសៀវភៅណែនាំហៅលទ្ធផលរបស់វាថាជាការមិនស៊ីសង្វាក់គ្នា ទិដ្ឋភាព។ វាមិនផ្តល់ទាំងការរាប់ស្តុកពេញលេញ ឬការផ្លាស់ប្តូរវេនដោយយុត្តិធម៌ទេ។ រក្សាការសម្រេចចិត្តភាពអាចរកបាន និងវិធានបំពេញបន្ថែមនៅជុំវិញវា។

### តើពិដានពិតប្រាកដនៅឯណា?

2:26 ហើយពិដាននោះ? កូដទូទាត់ផ្សេងទៀតកំពុងកាន់កាប់ការតភ្ជាប់មូលដ្ឋានទិន្នន័យយូរពេក។ Shopify បានដាក់ស្លាកអ្នកហៅ និងវាស់ពេលវេលាកាន់កាប់ការតភ្ជាប់ បន្ទាប់មកសម្អាតផ្លូវទូទាត់ និងពិនិត្យមើលភាពដំណាលគ្នានៃខ្សែស្រឡាយឡើងវិញ។ សំណួររហ័សនៅតែអាចតម្រង់ជួរនៅខាងក្រៅសំណួរ។

### ហេតុអ្វីខ្ញុំត្រូវ SHIP IT ការរចនានេះ?

2:38 ពួកគេបានសរសេរស្រមោលប្រព័ន្ធទាំងពីរជាមួយនឹង Redis ដែលមានសិទ្ធិអំណាច ប្រៀបធៀបលទ្ធផល បន្ទាប់មកប្តូរបន្តិចម្តងៗជាមួយនឹងកុងតាក់សម្លាប់។ សាលក្រមរបស់ខ្ញុំគឺ SHIP IT។ ខ្ញុំនឹង SHIP IT ព្រំដែនប្រតិបត្តិការដែលបានចែករំលែក និងការចេញផ្សាយដែលអាចបញ្ច្រាសបាននោះ ជាមួយនឹងផ្លូវទូទាត់ទាំងមូលត្រូវបានបំពាក់ឧបករណ៍។ មានសំណួរអំពីនេះទេ? ដាក់វានៅក្នុងមតិយោបល់។ ហើយនោះជាភាពខុសគ្នានាពេលបច្ចុប្បន្ននេះ។

2:54 ខ្ញុំ Niko មកពី Axrisi។ បញ្ចូលដោយការទទួលខុសត្រូវ។

## ប្រភព

- [We replaced Redis with MySQL for inventory reservations—and it scaled](https://shopify.engineering/scaling-inventory-reservations) — Shopify Engineering — Emilie Noel
- [Simplified reservation SQL embedded in Shopify's article](https://gist.github.com/CourtneySymons/cb5ecbe86331047aae166d5b1f1d555c) — Shopify Engineering / CourtneySymons on GitHub Gist
- [MySQL 8.0 — Locking Reads](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) — Oracle / MySQL Reference Manual
- [MySQL 8.0 — Transaction Isolation Levels](https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html) — Oracle / MySQL Reference Manual
- [What Is Shopify and How Does It Work?](https://www.shopify.com/blog/what-is-shopify) — Shopify
- [Redis quick starts](https://redis.io/docs/latest/develop/get-started/) — Redis documentation
- [What is MySQL?](https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.html) — Oracle / MySQL Reference Manual