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 kill-switch។

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

បកប្រែចេញពីការនិទានដើមជាភាសាអង់គ្លេស។ សំឡេង និងចំណងជើងរងដែលមានគឺស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់ 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។ បញ្ចូលដោយការទទួលខុសត្រូវ។

ប្រភព

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