# Shopify විසින් ඉන්වෙන්ටරි වෙන්කිරීම් MySQL වෙත ගෙන යන ලදී

Published: 2026-10-10

Shopify සිය ඉන්වෙන්ටරි වෙන්කිරීමේ පද්ධතිය Redis සිට දැනටමත් ඉන්වෙන්ටරි ලෙජරය තිබූ MySQL දත්ත ගබඩාව වෙත ගෙන යන ලදී. තනි තනිව අගුළු දැමිය හැකි ඒකක පේළිවල සීමා සහිත තටාකයක් සමගාමී පිරික්සුම් සඳහා විවිධ සුදුසු ඒකක තේරීමට SKIP LOCKED භාවිතා කිරීමට ඉඩ සලසයි. සැලසුම ගනුදෙනු සීමාවන්, ප්‍රාථමික-යතුරු පිරිසැලසුම, නැවත පිරවීමේ නීති සහ පිරික්සීම හරහා සම්බන්ධතා රඳවා ගැනීමේ කාලය නිරීක්ෂණය කිරීම මත ද රඳා පවතී.

Canonical: https://thedailydiff.dev/si/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 මම මෙම සැලසුම යවන්නේ ඇයි?

## පරිවර්තනය කරන ලද පිටපත

මුල් ඉංග්‍රීසි නිරූපණයෙන් පරිවර්තනය කරන ලදී. පවතින ශ්‍රව්‍ය සහ ශීර්ෂ පාඨ 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 එම තටාකය එක් එක් අයිතමය සහ ස්ථානය සඳහා පේළි දහසකට සීමා වේ. නැවත පිරවීම ලෙජරයෙන් ලබා ගනී. එය හිස් වුවහොත්, වෙන්කිරීමේ මාර්ගය අභ්‍යන්තරව නැවත පුරවයි, තරඟකාරී ඉල්ලීම් නැවත පිරවීමේ අගුලක් පිටුපස බලා සිටී. හිස් තටාකය හිස් ගබඩාවක් අදහස් නොවේ. වෙන්කිරීම තෝරාගත් තටාක පේළි මකා දමයි, පසුව වෙන්කිරීම් වාර්තා ඇතුළු කරයි ගනුදෙනුවක් තුළ. Commit දත්ත සමුදා අගුලු නිකුත් කරයි.

1:35 Rollback වෙනස්කම් අවලංගු කරයි. ගෙවීම් සැකසීම හරහා වෙන්කිරීම ගබඩා කර ඇති තත්වයක් ලෙස පවතී. සාර්ථක ගෙවීමකින් ලෙජරය ඉල්ලා සිටින අතර පරමාණුකව වෙන්කිරීම ඉවත් කරයි. දත්ත සමුදා අගුලු කිසි විටෙකත් ගෙවීම් පෝරමය නිරීක්ෂණය කිරීමට අවශ්‍ය නොවේ. ඔවුන්ගේ සංයුක්ත ප්‍රාථමික යතුර ආරම්භ වන්නේ සාප්පුව, අයිතමය, කණ්ඩායම, පසුව ඒකක අනන්‍යතාවයෙනි. සොයාගැනීම ගැලපීම ඔවුන්ගේ මූලාකෘතියේ දර්ශක අගුළු දැමීම අඩු කළේය. ඔවුන් පරතර අගුලු වළක්වා ගැනීමට read committed ද භාවිතා කරයි, එය තටාක

1:57 නැවත පිරවීම අවහිර කළ අතර, චක්‍රීය රැඳී සිටීම් වැළැක්වීමට ස්ථාවර වගු අනුපිළිවෙලක් ද භාවිතා කරයි. ප්‍රකාශිත උදාහරණය කල් ඉකුත් වීමේ වේලාවක් සටහන් කරයි. අතහැර දැමූ ගෙවීම් සඳහා අවසානයේ තොග නිකුත් කළ යුතුය, නැතහොවිට සාප්පු කරත්තය ඉඩම් හිමියෙකු බවට පත් වේ. Shopify හි සටහන එම පිරිසිදු කිරීමේ ඇල්ගොරිතම නිශ්චිත නොකරයි, එබැවින් මෙම රූප සටහන ජීවන චක්‍ර අවශ්‍යතාවය පෙන්වයි. මෙන්න අල්ලා ගැනීම.

### SKIP LOCKED මඟහරින්නේ කුමක්ද?

2:14 Skip locked, අගුළු දැමූ පේළි හැර, එබැවින් අත්පොත එහි ප්‍රතිඵලය නොගැලපෙන දසුනක් ලෙස හඳුන්වයි. එය සම්පූර්ණ තොග ගණනක් හෝ සාධාරණ වාර-ගැනීමක් සපයන්නේ නැත. ලබා ගැනීමේ තීරණය සහ නැවත පිරවීමේ නීති එය වටා තබා ගන්න.

### සැබෑ සීමාව කොහිද?

2:26 සහ එම සීමාව? වෙනත් පිරික්සුම් කේතය දත්ත සමුදා සම්බන්ධතා වැඩි කාලයක් රඳවා තබාගෙන සිටියේය. Shopify ඇමතුම්කරුවන් ටැග් කර සම්බන්ධතා රඳවා ගැනීමේ කාලය මැන බැලුවේය, පසුව පිරික්සුම් මාර්ගය පිරිසිදු කර නූල් සමගාමීත්වය නැවත පරීක්ෂා කළේය. වේගවත් විමසුම් තවමත් විමසුමෙන් පිටත පෝලිම් විය හැකිය.

### මම මෙම සැලසුම යවන්නේ ඇයි?

2:38 ඔවුන් Redis අධිකාරීත්වය සහිත පද්ධති දෙකම සෙවනැලි ලෙස ලියා, ප්‍රතිඵල සංසන්දනය කර, පසුව kill switch එකක් සමඟ ක්‍රමයෙන් මාරු විය. මගේ තීන්දුව SHIP IT. මම බෙදාගත් ගනුදෙනු සීමාව සහ එම rollbackable rollout, සමඟ සම්පූර්ණ පිරික්සුම් මාර්ගය උපකරණගත කර යවනු ඇත. මේ ගැන ප්‍රශ්නයක් තිබේද? එය අදහස් වලට දමන්න. ඒ අද දවසේ වෙනසයි.

2:54 මම Axrisi වෙතින් Niko. වගකීමෙන් යුතුව ඒකාබ්‍රව කරන්න.

## මූලාශ්‍ර

- [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