მოწინავე
სისტემური დიზაინი —
თანმიმდევრულობა ავარიების პირობებში.

ლინეარიზებადობა, ზუსტად

სესიის გარანტიები — იაფი მოგება

გლობალური წესრიგი იშვიათად გჭირდებათ; გჭირდებათ, რომ თქვენივე ხედვა იყოს აზრიანი. ეს სესიის დონის დაპირებები eventual საცავის თავზე ზის და სწორედ იმ სიმპტომებს კურნავს, რომლებსაც მომხმარებლები ამჩნევენ — ჩვეულებრივ სესიის ერთ რეპლიკაზე მიწებებით ან ვერსიის ტოკენის თვალყურის დევნებით.

პრაქტიკული წესი: ნაგულისხმევად აირჩიეთ eventual + სესიის გარანტიები, ლინეარიზებადობა კი მხოლოდ იმ რამდენიმე ინვარიანტზე დახარჯეთ, რომელიც არასდროს უნდა მოიხაროს — ბალანსები, მარაგის რაოდენობა, უნიკალური მომხმარებლის სახელები, ლიდერის ვინაობა.

Raft — კონსენსუსი, შექმნილი იმისთვის, რომ გასაგები იყოს

Raft ამოცანას ორ ამბად ყოფს: აირჩიე ერთი ლიდერი, შემდეგ კი ამ ლიდერს მიაცემინე მხოლოდ-დამატებადი ლოგის რეპლიკაცია. ყოველი გადაწყვეტილება უმრავლესობის ქვორუმზე დგას — 2f+1 კვანძით f ავარიას გადაიტანთ, რადგან ნებისმიერი ორი უმრავლესობა ერთმანეთს გადაფარავს.

// leader-only write path; followers just append
function onClientWrite(cmd: Command): void {
  log.append({ term, cmd })          // 1 · append locally
  sendAppendEntries(followers, log)  // 2 · replicate (RPC)
  if (acks >= majority()) {          // 3 · quorum = N/2 + 1
    commitIndex = log.lastIndex      //     durable once a majority has it
    applyToStateMachine(cmd)         // 4 · apply IN LOG ORDER
  }
}

ინსტრუმენტების ლანდშაფტი — კონსენსუსი & კოორდინაცია

Raft-ს თითქმის არასდროს ახორციელებთ თავად. ის იჯარით აიღება: პატარა, ძლიერად თანმიმდევრული საცავი, რომელიც ყველა დანარჩენისთვის ლიდერის იჯარებს, კონფიგურაციას, ბლოკირებებსა და სერვისების რეესტრებს ინახავს.

როგორ ავირჩიო: Kubernetes-ზე etcd უკვე გაშვებული გაქვთ — გამოიყენეთ ის. Consul აირჩიეთ მაშინ, როცა სერვისების აღმოჩენა და მრავალ-DC გჭირდებათ, და არა მხოლოდ კოორდინაცია. ZooKeeper-ს ძირითადად მაშინ მიმართეთ, როცა ძველ JVM სისტემებთან ინტეგრაცია გჭირდებათ, რომლებიც მას კვლავ ელოდებიან.

// each step pairs a forward action with its undo
const saga = [
  { do: reserveStock, undo: releaseStock },
  { do: chargeCard,   undo: refundCard },
  { do: bookCourier,  undo: cancelCourier },
]
// fail at step i → run undo for i-1 … 0, newest first

Outbox პატერნი — მოკალით ორმაგი ჩაწერა

საგები და მოვლენები გულისხმობს, რომ საიმედოდ შეგიძლიათ "განაახლოთ DB და გამოაქვეყნოთ შეტყობინება". ორივეს ატომურად ორ სისტემაში ვერ გააკეთებთ — მათ შორის ავარია და ისინი ერთმანეთს დაშორდება. ტრანზაქციული outbox მოვლენას იმავე მონაცემთა ბაზის ტრანზაქციაში წერს, რომელშიც მდგომარეობის ცვლილებაა, შემდეგ კი რელეი მას აგზავნის.

// ONE local transaction writes BOTH rows — atomic
await db.tx(async (t) => {
  await t.insert("orders", order)        // business state
  await t.insert("outbox", {            // event, same tx
    topic: "order.placed", payload: order,
  })
})
// a relay tails the outbox (poll or WAL/CDC) → broker → marks sent

იდემპოტენტურობის გასაღებები მასშტაბზე

სულ მცირე ერთხელ მიწოდება და კლიენტის ხელახალი მცდელობები ნიშნავს, რომ ყოველი ჩაწერა შეიძლება ორჯერ მოვიდეს. იდემპოტენტურობის გასაღები — კლიენტის მიერ მოწოდებული უნიკალური id თითო ლოგიკურ ოპერაციაზე — სერვერს საშუალებას აძლევს, გამეორება ამოიცნოს და იგივე შედეგი დააბრუნოს, ბარათის ხელახლა დახარჯვის ნაცვლად.

// client sends  Idempotency-Key: <uuid>  with the request
async function charge(key: string, amount: number) {
  const ok = await store.setNX(key, { status: "pending" }) // claim it
  if (!ok) return await store.wait(key)   // replay → saved result
  const result = await gateway.charge(amount)
  await store.set(key, { status: "done", result }, { ttl: "24h" })
  return result
}

• ხრიკი ატომური მითვისებაა (setNX / უნიკალურობის შეზღუდვა) — ის პარალელურ ხელახალ მცდელობებს ალაგებს, ისე რომ ზუსტად ერთი სრულდება.
• შეინახეთ პასუხი, და არა მხოლოდ ალამი, რომ გამეორებებმა რეალური შედეგი დააბრუნონ. გასაღებები თითო ენდპოინტზე შემოსაზღვრეთ და TTL მიეცით.
• სადაც შეგიძლიათ, ქვედა სისტემაც იდემპოტენტური გახადეთ — გეითვეი, რომელიც იმავე id-ს ეყრდნობა, ორმაგი დაზღვევაა.

როცა ორი რეგიონი ერთსა და იმავე გასაღებში წერს

ლიდერის გარეშე პარალელური ჩაწერები აუცილებლად დაუპირისპირდება ერთმანეთს. გჭირდებათ დეტერმინისტული, რიგისგან დამოუკიდებელი გზა მათი შერწყმისთვის — თორემ მონაცემებს უხმაუროდ დაკარგავთ.

ინსტრუმენტების ლანდშაფტი — გლობალურად განაწილებული მონაცემთა ბაზები

როგორ ავირჩიო: გჭირდებათ გლობალური ძლიერი თანმიმდევრულობა SQL-ით და GCP-ზე ხართ → Spanner. გინდათ იგივე, ოღონდ პორტატული და Postgres-ის ფორმის → CockroachDB. გჭირდებათ ჩაწერის უკიდურესი მასშტაბი და რეგულირებად/eventual თანმიმდევრულობას იტანთ → Cassandra ან Dynamo-ს სტილის საცავი.

ინსტრუმენტების ლანდშაფტი — განაწილებული ლიმიტერი Redis-ზე

ერთი კვანძის მეხსიერებაში მყოფი მთვლელი მთელ ფლოტზე არ მუშაობს — გჭირდებათ საერთო, ატომური საცავი. Redis ნაგულისხმევია: ქვემოთ მოცემული ყოველი მიდგომა ერთ ატომურ ოპერაციად სრულდება, ამიტომ პარალელური მოთხოვნები ლიმიტს ვერ გაუსწრებენ.

როგორ ავირჩიო: ნაგულისხმევად აიღეთ Lua-ს token bucket — ნახტომებიანი, O(1), ატომური. დაეშვით უბრალო INCR-ზე, როცა უხეში ჭერიც საკმარისია, ხოლო sorted-set ფანჯარა მხოლოდ მაშინ გამოიყენეთ, როცა მართლა ზუსტი რაოდენობები გჭირდებათ. ძალიან მაღალ RPS-ზე ლიმიტი ლოკალურად დააწესეთ, თითო კვანძის მცირე ბიუჯეტით, და პერიოდულად დაასინქრონეთ Redis-თან — ცოტა სიზუსტეს შეყოვნებაზე გაცვლით.

ხუთი წესი, რომელიც თან უნდა წაიღოთ

ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში