Consistency Models

နားလည်ထားရမယ့် အချက်

Distributed system တစ်ခုမှာ data တစ်ခုတည်းကို replica အများကြီးပေါ်မှာ ထားလေ့ရှိတယ် — availability နဲ့ fault tolerance အတွက်ပါ။ ဒါပေမဲ့ ချက်ချင်းပေါ်လာတဲ့ မေးခွန်းက replica တစ်ခုကို update လုပ်လိုက်ရင် ကျန် replica တွေက ဘယ်အချိန်မှာ value အသစ်ကို မြင်ရမလဲဆိုတာပါ။ Strong consistency ဆိုတာက replica ဘယ်ကနေ ဖတ်ဖတ် (read) ချင်း, အနောက်ဆုံး write ကို ချက်ချင်း ပြန်ပြရမယ်ဆိုတဲ့ အာမခံချက်ဖြစ်ပါတယ် — ဒါပေမဲ့ ဒီလို အာမခံနိုင်ဖို့ write တိုင်းမှာ replica တွေအချင်းချင်း coordinate လုပ်ဖို့ (ဥပမာ quorum ရဲ့ acknowledgment ကို စောင့်ခြင်း) လိုအပ်ပြီး latency ကို တိုးစေပြီး network ပြဿနာဖြစ်နေတဲ့အချိန်မှာ request တွေကို block ဖြစ်စေနိုင်ပါတယ်။ Eventual consistency ကတော့ ဒီအာမခံချက်ကို ပေါ့ပါးအောင်လုပ်ထားတယ် — write ပြီးချက်ချင်း read လုပ်ရင် stale value ကို ပြန်ရနိုင်ပေမယ့် write အသစ်များ မရှိတော့ရင် အချိန်လုံလောက်စွာနဲ့ replica အားလုံး တန်ဖိုးတူညီအောင် converge ဖြစ်လာမှာပါ။ Trade-off ကတော့ speed နဲ့ availability ကို recency နဲ့ လဲယူခြင်းပါပဲ။ ဒါက abstract ရွေးချယ်မှုမဟုတ်ဘဲ use case အလိုက် ဆုံးဖြတ်ရပါတယ်။ Social post တစ်ခုရဲ့ 'likes' counter ဟာ replica တစ်ခုက 1,205 အစား 1,204 ကို ခဏပြသနေရင် လက်ခံနိုင်ပါတယ် — ဘယ်သူမှ မသိသလို ထိခိုက်မှုလည်း မရှိပါဘူး။ ဒါပေမဲ့ ငွေထုတ်ခွင့်ပေးခင် bank balance ကို စစ်ဆေးတာမျိုးမှာတော့ staleness ကို လက်ခံလို့မရပါဘူး — balance အဟောင်းကို ဖတ်ပြီး တခြားနေရာမှာ ကုန်သွားပြီးသား ငွေကို ထပ်ထုတ်ခွင့်ပြုလိုက်ရင် ဒါက အလှတရား မှားယွင်းချက်မဟုတ်ဘဲ ငွေကြေးဆိုင်ရာ bug အစစ်အမှန်ပါပဲ။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ကြီးထွားလာတာနဲ့အမျှ lesson-completion counter တွေနဲ့ 'X students enrolled' badge တွေကို ကမ္ဘာတစ်ဝှမ်း read မြန်ဆန်အောင် region များစွာမှာ replicate လုပ်ထားပါတယ် — ဒါတွေက badge က စက္ကန့်အနည်းငယ် နောက်ကျနေရင်တောင် ဘာမှမထိခိုက်လို့ eventual consistency ကို လုံခြုံစွာ သုံးနိုင်ပါတယ်။ ဒါပေမဲ့ user တစ်ဦးက ဝယ်ယူထားတဲ့ course bundle ကို redeem လုပ်တဲ့အခါ 'payment ဒီတစ်ခါ apply ဖြစ်ပြီးသားလား' စစ်ဆေးတဲ့ system ကတော့ strong consistency ကို သုံးရမှာပါ — region replica နှစ်ခုက payment ရှင်းလင်းပြီးမပြီး သဘောထားကွဲလွင့်နေရင် student တစ်ဦးက course credit နှစ်ဆ ရနိုင်ပြီး ဒါမှမဟုတ် payment လုံးဝ ပျောက်ကွယ်သွားနိုင်ပါတယ်။ Tutorial Platform ရဲ့ engineer တွေက site တစ်ခုလုံးအတွက် consistency model တစ်ခုတည်း မရွေးဘဲ data အမျိုးအစားအလိုက် ရွေးကြပါတယ် — staleness ဘာမှမထိခိုက်တဲ့ နေရာတိုင်းမှာ eventual consistency (နဲ့ ၎င်းရဲ့ speed) ကို လက်ခံပြီး correctness တကယ် မှီခိုနေရာမှာသာ strong consistency ရဲ့ coordination cost ကို ပေးဆောင်ကြပါတယ်။

• Strong consistency က read တိုင်း အနောက်ဆုံး write ကို ဖော်ပြပေးပေမဲ့ coordination latency ကုန်ကျပါတယ်။
• Eventual consistency က ခဏတာ staleness ကို ခွင့်ပြုပေမယ့် အချိန်နဲ့အမျှ replica အားလုံး converge ဖြစ်ပြီး speed နဲ့ availability ကို ဦးစားပေးပါတယ်။
• မှန်ကန်တဲ့ model ကို use case အလိုက် ရွေးရပါတယ် — ထိခိုက်မှုမရှိတဲ့ data (like count) အတွက် eventual, မှန်ကန်မှု အရေးကြီးတဲ့ data (balance) အတွက် strong consistency လိုအပ်ပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

BEFORE write (t=0):
  Replica A: likes = 1204
  Replica B: likes = 1204

[Client writes likes = 1205 to Replica A]

STRONG CONSISTENCY (e.g. bank balance):
  t=0   Client -> Replica A: write likes=1205
  t=0   Replica A <-> Replica B: synchronous sync (coordination)
  t=1ms Replica A: ACK to client (write confirmed on all replicas)
  t=1ms Client -> Replica B: read likes -> 1205  (always fresh, but write was slower)

EVENTUAL CONSISTENCY (e.g. like count):
  t=0   Client -> Replica A: write likes=1205
  t=0   Replica A: ACK to client immediately (fast!)
  t=0   Client -> Replica B: read likes -> 1204  (STALE! B hasn't synced yet)
  t=50ms Replica A --async replication--> Replica B
  t=50ms Client -> Replica B: read likes -> 1205  (caught up / converged)

Diagram က strong consistency ဟာ ရှေ့ကတည်းက coordination cost ကို ပေးဆောင်ထားလို့ နောက်ပိုင်း read တိုင်း ချက်ချင်း မှန်ကန်နေတာနဲ့ eventual consistency ကတော့ ပိုမြန်စွာ တုံ့ပြန်ပေမယ့် replication ဆက်မလိုက်သေးလို့ ခဏတာ stale value ပြန်ပေးနိုင်တာကို ပြသထားပါတယ်။

Wikipedia — Consistency model — System Design