Strong Consistency: қажет кезде

Strong Consistency (сызбалану) - барлық операциялар нақты уақытпен келісілген бірыңғай жаһандық тәртіппен бірден және бірізді орындалатындай көрінетін модель. Пайдаланушы соңғы расталған мәнді оқиды, ал екі қатарлас клиент бір-бірін қисынды түрде басып озмайды.

Қатаң келісім қарапайым ментальдық модельді береді және қатаң инварианттарды қорғайды, бірақ үйлестіруді талап етеді (кворумдар/көшбасшы), бұл кідіріс пен желілік бөліністерге сезімталдықты арттырады.

1) Strong - міндетті

Қаржы және есеп айырысу

Баланстар мен есептен шығарулар: «екі есе шығынға» жол берілмейді.
Аударымдар мен өзара есеп айырысулар: бір сома екі рет жүргізілмейді.

Мүкәммал мен лимиттер

Тауардың қалдықтары/қонақ үйдегі орындар/билеттер: теріс мәндерге кетуге болмайды.
Уақыт бірлігіндегі операциялардың лимиттері (кредиттік лимиттер, API-кредиттер).

Бірегейлігі мен тұтастығы

Бірегей логиндер/идентификаторлар/дедупликация ережелері.
Домен деңгейіндегі инварианттар: «бөлімшеде ≥ 1 дәрігер кезекшілік етуі тиіс», «кезекте> N белсенді міндеттер болмауы тиіс».

Аудит және өзгермейтін журналдар

Ақиқаттың заңды көзі болып табылатын оқиғалар: тәртіп пен толықтығы сыни.

Егер инвариантты бұзу қолайсыз бизнес-тәуекелге алып келсе (ақшаны жоғалту, санкциялар, сенімді жоғалту) - Strong Consistency таңдаңыз.

2) Нені «қатаң»

Linearizability (операциялық деңгей): оқу ең соңғы сәтті жазбаны көреді; заман құрметке ие.
Serializable (транзакциялық деңгей): нәтиже транзакцияларды дәйекті орындауға баламалы (strong болуы мүмкін, бірақ кейде қатаң real-time тәртібінсіз іске асырылады).
Маңызды айырмашылық: Serializable транзакция деңгейінің ауытқуларынан (phantom/write-skew) қорғайды, ал Linearizable - жалғыз операциялардың сәттілігі мен тәртібі туралы. Жиі екі сипат қажет (мысалы, ақша ДБ + оқиғалар журналы).

3) Қатаңдық бағасы: PACELC және CAP

PACELC: желіні бөлу кезінде (P) C (қатаңдық) немесе A (қолжетімділік) таңдауға тура келеді. Strong → CP: инвариантты бұзғаннан гөрі бас тарту немесе бұғаттау жақсы. Бөлу болмаған кезде (EL) L - үйлестірумен/кворуммен p95/p99 өседі.
Практика: «инварианттар ядросы» үшін strong, айналасында - UX зардап шекпеу үшін eventual жылдам проекциялар/кэштер.

4) Strong Consistency қалай жетеді

Көшбасшылық және кворумдар

Жалғыз басшы жазбаларды қабылдайды; оқу - көшбасшыда немесе реплика кворумы бойынша.
Жазу үшін 'W' және 'R' оқу үшін 'R + W> N' кворумы «соңғы» оқу мүмкіндігін арттырады.

Келісу алгоритмдері

Raft/Paxos: репликация журналы, көпшілікті растау, термин/индекстер.
Ілеспе репликация: жазба тек кворумдағы персистенттіліктен кейін ғана расталады.

Сағат және тәртіп

TrueTime/Hybrid Logical Clocks (HLC): қауіпсіз жаһандық сериалдандыру үшін сағаттардың рассинхронын шектеу.
Fence-токендер/нұсқалау: «таңертеңгі» көшбасшылардан және сплит-брейнден қорғау.

Транзакцияларды оқшаулау

Serializable (SI + қайшылықтарды/локтарды предикаттар бойынша тексеру): phantom/write-skew-ден қорғау.
Strict-serializable: шынайы уақытқа қатысты сериалдану + сызықтану.

5) Мульти-өңір: нұсқалар мен ымыраға келу

Жаһандық көшбасшы (CP)

Жазбалар бір жетекші өңір арқылы жүреді; оқу - жергілікті кэштер/проекциялар немесе көшбасшы арқылы.
Артықшылықтары: қарапайым модель. Кемшіліктері: көшбасшыға дейін p95/RTT, P кезінде - жазбаларды бұғаттау.

Өңірлік көшбасшылар + синхронды кворум

Бірнеше өңірден геоқайланған кворум; әрбір жазба> 50% растауды күтеді.
Артықшылығы: бірыңғай «жіңішке мойынсыз», жоғары орнықтылығы. Кемшіліктері: құрлықаралық жасырын.

Geo-partitioning

Өңір үшін «үй» деректері (тенант/юрисдикция); жаһандық операциялар - сағалар/агрегаттар арқылы.
Артықшылықтары: жергілікті жазбалар үшін төмен кідірістер. Кемшіліктері: деректер шекарасын жоспарлау.

6) R/W және оқуларды теңшеу

Жазбалар: 'W = majority' - strong үшін стандарт.

• «Ең жаңасы» - 'R = majority' немесе көшбасшыдан оқу.
• L төмендету үшін - «stale-ok» екінші дәрежелі экрандарға арналған репликалардан оқу (UX-те анық таңбалаумен).
• Read-repair/lease read: көшбасшының қысқа аренада қатаңдықты жоғалтпай оңтайландыру.

7) Өнімділік және UX

Жасырындылық: клиент пен көшбасшы/кворум арасындағы RTT бағдарланыңыз (өңіраралық жүздеген мс).
«write-strong, read-fast» үлгісі: жазбадағы strong + оқулықтағы кэш/проекция, автор үшін RYW.
Batch/бумалар: жазбаларды топтаңыз, бірақ артқы жасырындылықты қадағалаңыз.
Деградация контурлары: оқыс оқиға кезінде - read-only, адал мәртебелер, қауіпті мутацияларға тыйым салу.

8) Strict жолының бақылануы

Өлшемдер

p50/p95/p99 latency: write-кворум, read-кворум, көшбасшылық оқулар.
Кворумдардың, қайталаулардың/кері қайтарулардың, көшбасшы ауысулардың табыстылығы.
Репликациялық лаг (күтілетін аз, бірақ міндетті түрде мониторингілеу).
Оқудың «стейл» үлесі (егер қосылған болса).

Трейсинг

«Көшбасшының қабылдауы», «репликация», «коммит кворум».
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Алерттар

p95/p99 өсуі, көшбасшының жиі қайта сайлануы, кворум-timeouts, split-brain индикаторлары.

9) Тесттер және хаос

Jepsen-ұқсас: желілік бөлулер, кідірістер, дроптар, clock-skew.
Safety-инварианттар: қосарланған шығындардың/теріс қалдықтардың/қосарланған брондаудың мүмкін еместігі.
Көшбасшылық: көшбасшының бас тартуы, жүктемемен қайта сайлау, fence-токендер.
Оқылым үйлесімділігі: оқылым жазудан кейін бірден «жаңа» (RYW/linearizable read) көру керек.

10) Инциденттердің плейбуктері

Кворумды жоғалту: read-only-ге ауыстыру, клиенттерді хабардар ету, geo-partitioning болған жағдайда «үй» аймағына жазба жіберу.
Латенттіліктің өңіраралық өсуі: қатаң жазбалар көлемін уақытша төмендету (кезектегі/проекциядағы ағындардың бір бөлігінің көшуі), трафикті оқшаулау.
Көшбасшының флапы: сайлау таймауттарын ұлғайту, желілерді/сағаттық дрейфтерді/GC-үзілістерді тексеру.
Split-brain: fence-токендерді/lease-тексерулерді қосу, оператор деңгейінде ескі көшбасшыларды тоқтату.

11) Типтік қателер

Strong «барлық жерде» талап ету: инварианттарға назар аударудың орнына жасырындылық пен құнды жару.
Шынайы бөліністе CA болуға тырысу: P сәтінде жүйе бәрібір таңдау жасайды, көбінесе анық емес.
Dual-write әртүрлі аймақтарға сағасыз/үйлестірушісіз: фантомдар және инварианттарды жоғалту.
RYW жоқ: пайдаланушы өзінің жаңа жазылған мәнін - сенімнің төмендеуін көрмейді.
Сағаттарды елемеу: HLC/TrueTime шекаралары жоқ, «секіру» уақыты мен жарыстарын алу оңай.
Деградация жоспары жоқ: P кезінде ретсіз ішінара ақаулар басталады.

12) Жылдам шешімдер (рецепттер)

Төлемдер/баланстар: көшбасшы + majority-кворум; strict-serializable транзакциялары; қысқа таймауттар, Р кезінде қатты істен шығу.
Брондау (орындар/слоттар): көшбасшы арқылы write-strong, оқу - RYW бар кэш; TTL-резервтер + TCC.
Жаһандық SaaS: geo-partition бойынша 'tenant/region'; үй аймағындағы қатаң операциялар, есептер/іздеу - проекциялар арқылы.
Аудит/журнал: append-only CP-журнал; оқуларды кешіруге болады, бірақ бақылау нүктелерімен тексеруге болады.

13) Азық-түлік алдындағы чек-парағы

• strong талап ететін инварианттар жазылған; қалғаны - АР/проекцияда.
• Таңдалған режим: бірыңғай көшбасшы/өңіраралық кворум/geo-partition.
• Критикалық жолдар үшін 'W = majority', 'R = leader' majority 'теңшелген.
• UX үшін RYW/monotonic қамтамасыз етілген; «stale-ok» оқулары анық белгіленген.
• Кворум, лагтар, жасырындылық өлшемдері қосылған; p95/p99-ға арналған алерталар және қайта сайлау.
• Degrade-жоспары бар: read-only, қауіпті мутацияларды сөндіру, «дауылдан кейін» кезек.
• Хаос-тесттер: бөлулер, clock-skew, көшбасшының бас тартуы; тексерілген safety-инварианттар.
• Келісімшарттардың құжаттамасы: не қатаң, не «артта қалуы мүмкін», өнім/қолдау үшін коммуникация.

Қорытынды

Strong Consistency - қате қабылданбайтын жерде ақиқатты қорғау құралы. Оны қатты инварианттардың айналасында жасырындылықпен және дауылға қол жетімділікпен үйлестіру үшін саналы түрде төлей отырып, нүктелі қолданыңыз. Біріктіріңіз: Критикалық, AP оқу және жылдамдық проекциясы үшін CP ядросы. Дұрыс телеметриямен, деградациямен және тесттермен сіз әдептілікті де, пайдаланушылық тәжірибені де сақтайсыз.