Distributed Systems များတွင် Data ကို စီမံခန့်ခွဲခြင်း

ရည်ရွယ်ချက်

Microservice တစ်ခုစီက ကိုယ်ပိုင် Database ပိုင်ဆိုင်ထားတဲ့အခါ Data စီမံခန့်ခွဲရာမှာ ကြုံတွေ့ရတဲ့ စိန်ခေါ်မှုတွေကို နားလည်ရန်နှင့် ၎င်းတို့ကိုဖြေရှင်းရန် Saga ကဲ့သို့သော အသုံးများသည့် Pattern များကို လေ့လာရန် ဖြစ်ပါတယ်။

“Service တစ်ခု၊ Database တစ်ခု” စိန်ခေါ်မှု

Microservices တွေမှာ Service တစ်ခုစီက သူ့ရဲ့ ကိုယ်ပိုင်သီးသန့် Database ကို ပိုင်ဆိုင်သင့်တယ်လို့ ကျွန်တော်တို့ လေ့လာခဲ့ပါတယ်။ ဒါက လွတ်လပ်မှုအတွက် အရမ်းကောင်းပေမယ့်၊ ပြဿနာအသစ်တစ်ခုကို ဖြစ်ပေါ်စေပါတယ် - Service တွေအများကြီးစီက Data တွေကို လိုအပ်တဲ့အခါ ဘယ်လိုလုပ်မလဲ?

Data Synchronization Patterns (Data များကို တူညီအောင် ထိန်းညှိခြင်း)

Service တစ်ခုက တခြား Service တစ်ခုရဲ့ Data ကို Query လုပ်ချင်တယ်ဆိုရင်၊ ရွေးချယ်စရာ နည်းလမ်းအနည်းငယ်ရှိပါတယ်:

1. Synchronous API Calls (တိုက်ရိုက် API ခေါ်ယူခြင်း) - အရိုးရှင်းဆုံးနည်းလမ်းပါ။ Service A က သူလိုအပ်တဲ့ Data ကိုရဖို့ Service B ရဲ့ API ကို တိုက်ရိုက်ခေါ်ယူလိုက်တာ ဖြစ်ပါတယ်။ အားနည်းချက်ကတော့ Service B သာ ပျက်နေရင်၊ Service A ပါ အလုပ်ဆက်လုပ်လို့မရတော့ပါဘူး။

2. Asynchronous Events (Event များဖြင့် ဆက်သွယ်ခြင်း) - Service B က သူ့ Data ပြောင်းလဲသွားတိုင်း “UserDataUpdated” ဆိုတဲ့ Event တစ်ခု ထုတ်လွှင့်ပေးပါတယ်။ Service A က အဲဒီ Event ကိုနားထောင်ပြီး သူ့ဆီမှာရှိတဲ့ Data Copy ကို Update လုပ်ပါတယ်။ ဒါက ပိုပြီး ခံနိုင်ရည်ရှိပေမယ့်၊ Eventual Consistency (ချက်ချင်း Data မတူပေမယ့်၊ နောက်ဆုံးမှာတော့ တူညီသွားတဲ့အခြေအနေ) ကို ဖြစ်ပေါ်စေပါတယ်။

The Saga Pattern: Service များတစ်လျှောက် Transaction များ ပြုလုပ်ခြင်း

ဒီ Pattern က Service တွေမှာ All or Nothing ဆိုတဲ့ လုပ်ဆောင်ချက်တွေရဲ့ ပြဿနာကို ဖြေရှင်းပေးပါတယ်။

• ပြဿနာ - Order တစ်ခုတင်တာကို မြင်ယောင်ကြည့်ပါ။ ဒါက -
  1. Order Service မှာ Order အသစ်တစ်ခုဖန်တီးရမယ်
  2. Payment Service မှာ ငွေပေးချေရမယ်၊ ပြီးတော့
  3. Inventory Service မှာ ပစ္စည်းအရေအတွက်ကို သီးသန့်ဖယ်ထားရပါမယ်။

အကယ်၍ အဆင့် ၃ က မအောင်မြင်ခဲ့ရင်၊ အဆင့် ၁ နဲ့ ၂ ကို ပြန်ပြီး ဖျက်သိမ်း (Undo) ရပါမယ်။ သမားရိုးကျ Database Transaction တစ်ခုက မတူညီတဲ့ Database တွေပေါ်မှာ ဒီလိုအလုပ်မျိုး မလုပ်နိုင်ပါဘူး။

• Saga ၏ ဖြေရှင်းချက် - Saga ဆိုတာက Local Transaction အဆင့်ဆင့်ကို ဆက်တိုက်လုပ်ဆောင်တာပါ။ Transaction တစ်ခုချင်းစီက Service တစ်ခုကို Update လုပ်ပြီး၊ နောက် Transaction တစ်ဆင့်ကို စတင်ဖို့အတွက် Event ဒါမှမဟုတ် Message တစ်ခု ထုတ်လွှင့်ပေးပါတယ်။

• အလွန်အရေးကြီးသော သဘောတရား - Compensation (ပြန်လည်ပြင်ဆင်ခြင်း) - Saga ထဲက အဆင့်တစ်ခုခု မအောင်မြင်ခဲ့ရင်၊ သူက “Compensating Transactions” (လုပ်ပြီးသားအဆင့်တွေကို ပြန်ပြီးဖျက်သိမ်းတဲ့ လုပ်ဆောင်ချက်) တွေကို ပြောင်းပြန်အစဉ်လိုက် လုပ်ဆောင်ပါတယ်။ ဥပမာ - ပစ္စည်းအရေအတွက်ဖယ်ထားတာ မအောင်မြင်ခဲ့ရင်၊ Saga က Payment Service မှာ “ငွေပြန်အမ်းခြင်း” Transaction ကို စတင်စေပြီး၊ Order Service မှာ “Order ဖျက်သိမ်းခြင်း” Transaction ကို စတင်စေပါလိမ့်မယ်။