CAP және инженерлік мәмілелер

CAP: желіні бөлу жағдайында (Partition, P) бөлінген жүйе бір мезгілде күшті келісімділікке (Consistency, C) және қолжетімділікке (Availability, A) кепілдік бере алмайды. P болған жағдайда не CP, не AP таңдауға тура келеді. Бөлулер болмаған жағдайда шектеу қолданылмайды, бірақ басқа да ымыраға келу пайда болады - ең алдымен кідіріс (latency) және құн.

Практикалық инженерия CAP шегінен шығады: PACELC маңызды (егер P - C немесе A таңдасақ; әйтпесе - Latency және Consistency арасында таңдаймыз), үйлесімділік модельдері, SLA/SLO, бизнестің жүзкейстері мен тәуекелдері.

1) Базалық анықтамалар (философиясыз)

Келісімділік (С): барлық клиенттер операциялардың «дәйекті орындалғанындай» бір ғана нәтижені көреді (желілік/strong consistency).
Қол жетімділік (А): түспеген торапқа әрбір сұрау бөлген кезде де ақылға қонымды уақытта жауаппен аяқталады.
Бөлу (P): тораптар/өңірлік кластерлер арасындағы байланыстың жоғалуы немесе едәуір тозуы; шын мәнінде - үлкен ауқымда «сөзсіз».
PACELC: P кезінде C немесе A таңдаймыз; else (P болмаған кезде) L (төмен кідіріс) немесе C (күшті үйлесімділік) таңдаймыз.

2) Интуитивті таңдау суреті

CP (келісім маңыздырақ): бөлген кезде инварианттарды бұзбау үшін сұраулардың бір бөлігін қабылдамаймыз/бұғаттаймыз. Ақша, транзакциялар, қалдықтарды есепке алу үшін жарамды.
AP (қол жетімділік неғұрлым маңызды): біз әрқашан жауап береміз, бірақ уақытша келіспеушілікке жол береміз, содан кейін қақтығыстарды (CRDT/мердж ережелері) құлатамыз. Соц-фидтер, лайк есептегіштер, кешенделген профильдер үшін жарамды.
CA (бір мезгілде C және A): тек P болмағанда ғана мүмкін, яғни әзірге желі сау. Нақты пайдалануда «CA» - дизайн қасиеті емес, уақытша жай-күй.

3) PACELC: кідіріс туралы ұмытпаймыз

• Өңірлер арасындағы күшті консистенттілік = құрлықаралық кворумдар ⇒ p95-ке ондаған-жүздеген мс.
• Жергілікті оқулар (төмен L) = әлсіз кепілдіктер (read-my-writes, bounded staleness, eventual).
• PACELC неге «тез және қатаң» жаһандық сирек кездесетінін түсіндіруге көмектеседі: жарық - жылдам емес, ал кворумдар желінің бүктелуімен өседі.

4) Келісу модельдері (жылдам спектр)

Linearizable/Strong: бір тізбекті тәртіп сияқты.
Serializable: кейбір бірізді транзакция тәртібіне баламалы (жазба деңгейінен жоғары).
Read-your-writes/Monotonic reads: клиент өз жазбасынан кейін жаңа мәнді оқиды.
Bounded staleness: N нұсқасынан/ Δ t аспайды.
Eventual consistency: уақыт өте келе барлық көшірмелер үйлеседі; жанжалдарды шешу керек.

5) Өнімдер мен хаттамалардағы CP және AP паттерндері (тұжырымдамалық)

CP-тәсілдері: кворумдық журналдар/көшбасшылық (Raft/Paxos), қатаң транзакциялар, көшбасшының жаһандық орналасуы, синхронды репликация. Баға - Р кезінде сұрау салулардың бір бөлігінің істен шығуы және кідірістердің өсуі.
AP тәсілдері: мульти-мастер/мульти-көшбасшы, CRDT, gossip-тарату, асинхронды репликация, қақтығыстарды шешу (LWW, векторлық сағаттар, домендік мердж функциялары). Баға - уақытша келіспеушілік және домендік ережелердің күрделілігі.

6) Мульти-өңірдегі мәмілелер

Жаһандық көшбасшы (CP): қарапайым логика, бірақ «алыс» өңірлер жасырындылықпен төлейді; P кезінде - жазбаларды бұғаттау.
Жергілікті көшбасшылар + асинхрон (AP): жазба жылдам жергілікті, содан кейін репликалау; қайшылықты өзгерістер мерджді талап етеді.
Geo-partitioning: деректер пайдаланушыға/юрисдикцияға жақын «өмір сүреді»; кросс-өңір - тек агрегаттар.
Dual-write саг/CRDT-сыз тыйым салынады: әйтпесе фантомдар мен қосарланған есептен шығарулар алынады.

7) Инженерлік инварианттар және бизнес шешімдер

Алдымен инварианттар: ешқашан бұзуға болмайтын нәрсе (қос шығын, теріс қалдық, кілттің бірегейлігі), ал eventual не «бастан кешіретіні» (қарау санауышы, ұсынымдар).

• Тиісті операциялар үшін «қатты» → CP инварианты.
• Кейіннен құлау арқылы «жұмсақ» → AP инварианты.

8) Мәмілелерді жұмсарту техникасы

Кэш және CQRS: жақын кэш/проекция арқылы оқу (AP), жазбалар - қатаң журналға (CP).
RPO/RTO компромисс тілі ретінде: қанша деректерді жоғалтуға болады (RPO) және қалай тез қалпына келтіруге болады (RTO).
Келісілген ID және сағат: монотонды таймстамптар (Hybrid/TrueTime-тәсілдер), ULID/Snowflake.
Саги/ТСС: жаһандық бұғаттаудың орнына бизнес-өтемақы.
CRDT және домендік мердж: коллекциялар, санауыштар, «соңғы жеңістер» үшін.
Bounded staleness: UX және дәлдік балансы.

9) Бақылау, SLO және инциденттерді басқару

SLO (p50/p95/p99) оқу/жазу және аймақтар үшін жеке.
Аймақтың фейловерін ескере отырып, қол жетімділік бойынша SLO.
Lag репликация/жанжалдық: жанжалдардың үлесі, орташа шешу уақыты.
P белгісі бойынша алерттар: өңіраралық арналар таймауттарының көтерілуі, кворум қателерінің өсуі.
Degrade-жоспарлар: read-only режимі, кейіннен мерджмен жергілікті қызмет көрсету, «қымбат» функцияларды өшіру.

10) Стратегияны таңдау чек-парағы

1. Қандай инварианттарды бұзуға болмайды? Eventual не жол береді?
2. Төменгі латентті кросс-өңірлік жазба қажет пе?
3. Мақсатты SLO (жасырындылық/қолжетімділік) және құны (egress/репликация) қандай?
4. manual merge немесе тек автоматты (CRDT/ережелер) рұқсат етесіз бе?
5. Желі істен шығуының профилі қандай: жиілігі, ұзақтығы, blast radius?
6. Деректерді заңды оқшаулау (residency) бар ма?
7. Деректердің/операцияның әрбір түрі үшін қандай келісімділік моделі қолайлы?
8. Лагтарды, қақтығыстарды, кворумдардың жағдайын қалай бақылайсыз?
9. P кезінде жүйе не істейді: трафикті бұғаттайды, деградациялайды, бөледі?
10. P-ден кейін деректерді қалпына келтіру және репатриациялау жоспары қандай?

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

«CA мәңгі» ізіне түсу. Бірінші кезде P таңдауға тура келеді - алдын ала таңдаған дұрыс.
Мердж ережесінсіз жаһандық мульти-мастер. Қайшылықтар деректер мен сенімді «жейді».
Күшті төзімділік «барлық жерде». Артық кворумдар p95/p99 және бюджетті қамтиды.
Dual-write транзакциясыз/сағатсыз. Жоғалған инварианттар мен фантомдар.
PACELC елемеу. Бейбіт уақытта жасырындылық, дауыл кезінде қолжетімділік зардап шегеді.
Жанжалдар мен лагтардың нөлдік телеметриясы. Проблемалар тек пайдаланушыға ғана көрінеді.

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

Төлем/теңгерім: кворумы бар CP-сақтау орны; жазбалар тек жетекші арқылы; оқулар кэштелуі мүмкін, бірақ сыни UX - read-your-writes.
Контент/фид: AP-репликация + CRDT/мердж ережелері; P кезінде - жергілікті қызмет көрсету, содан кейін құлату.
Жаһандық SaaS: geo-partitioning бойынша 'tenant/region'; «үй» өңіріндегі қатаң операциялар (CP), есептер/іздеу - асинхронды проекциялар (AP) арқылы.
Real-time сигнал: Anycast/edge + AP-шина; сыни командалар расталған арна (CP) арқылы өтеді.
Аудит/журнал: CP-кепілдіктері бар жалғыз ақиқат көзі (append-only), айналасында - кэштер мен проекциялар.

13) Архитектураның шағын эталоны (сөзбен)

Write-core (CP): көшбасшы + кворумдық репликация, қатаң инварианттар, сервистік әсерлерге арналған сағалар.
Read-plane (AP): материалданған көріністер, кэштер, search-индекстер, асинхронды жаңарту.
Geo-routing: пайдаланушылар «үй» аймағына түседі; P - жергілікті режим + кейінгі репликация.
Қайшылық-қозғалтқыш: CRDT/ережелер; жанжалдар журналы және қолмен реттеу құралдары.
Байқалуы: кворумдардың трейсингі, лагтар, желі инциденттерінің картасы.

14) Кідірістердің практикалық математикасы (қарапайым бағалау)

Оптика 1000 км-ге 5 мс ≈ (RTT одан да көп). Құрлықаралық кворумдар → p95 оңай> 150-250 мс.
Жазу үшін кез келген «жаһандық Strong» - бұл қымбат сұраныс. Егер UX <100-150 мс талап етсе, жергілікті write-home + асинхрондық салдарлар туралы ойланыңыз.

15) Бөлiнген жағдайдағы саясат

CP жолы: жазбаларды кворумнан тыс бұғаттау; read-only қосу; пайдаланушыға адал мәртебе беру.
AP-жолы: жергілікті қызмет көрсету; нұсқаларын таңбалау; қалпына келтіру кезінде - детерминирленген мердж; қақтығыстарды талдау кезегіне қою.

Қорытынды

CAP - догма емес, еске салғыш: желінің бөлінуі сөзсіз, және жоба дауылда не құрбандық ететінін алдын ала таңдауы тиіс - қол жетімділік немесе қатаң келісу. PACELC ашық ауа райында кідірістің негізгі білігін қосады. Стратегияларды біріктіріңіз: CP ядросын инварианттар қасиетті жерде және AP жазықтығын жылдамдық пен тұрақтылық маңызды жерде ұстаңыз. Телеметрия, деградация жоспарлары мен мерджинг процестерін салыңыз - жүйе деректерді де, пайдаланушылар сенімін де сақтайды.