Пошук уроків, статей та іншого контенту
Чому розподілена система не може одночасно гарантувати консистентність, доступність і стійкість до розділення.
CAP-теорема стверджує: розподілена система (дані розкидані по кількох серверах з можливою мережевою затримкою чи розривом зв'язку між ними) може одночасно гарантувати щонайбільше дві з трьох властивостей — Consistency (консистентність: усі вузли бачать ті самі, актуальні дані одночасно), Availability (доступність: кожен запит отримує відповідь, навіть якщо не найновішу), Partition tolerance (стійкість до розділення: система продовжує працювати, навіть якщо мережевий зв'язок між частинами системи розірваний).
У реальних розподілених системах мережеві розриви (partition) — не рідкісний гіпотетичний випадок, а неминучість: мережеве обладнання, кабелі, дата-центри час від часу відмовляють чи гальмують. Це означає, що P (partition tolerance) на практиці не опціональна властивість, від якої можна відмовитись, — реальний вибір системи насправді відбувається між C і A саме в момент, коли розділення відбулось.
CP (consistency + partition tolerance) — під час мережевого розділення система відмовляється відповідати частині запитів (чи відповідає помилкою), щоб гарантовано не повернути застарілі чи суперечливі дані. Приклад практичного застосування: банківські транзакції, де показати неправильний баланс гірше, ніж тимчасово відмовити в обслуговуванні.
PostgreSQL з традиційною primary-replica реплікацією (курс PostgreSQL, урок про транзакції) типово схиляється до CP-поведінки в межах однієї транзакції — саме тому рівні ізоляції транзакцій (READ COMMITTED, SERIALIZABLE) взагалі існують: це той самий компроміс консистентність/доступність/продуктивність, розглянутий у масштабі однієї бази даних, а не розподіленого кластера.
CP чи AP — не властивість «усієї системи» назавжди, а рішення, яке ухвалюють для конкретної частини даних відповідно до бізнес-вимог: той самий застосунок може обробляти платежі в CP-режимі (краще відмовити, ніж показати неправильний баланс) і лічильники переглядів в AP-режимі (краще показати трохи неточне число, ніж не показати взагалі).
Трактувати CAP-теорему як вибір «між усіма трьома властивостями завжди» — partition tolerance на практиці неминуча, реальний вибір відбувається між C і A саме в момент розділення.
Застосовувати один і той самий CP/AP-вибір до геть усіх даних застосунку без урахування різних вимог різних типів даних (платежі проти лічильників переглядів).
Плутати CAP-консистентність (усі вузли бачать ту саму версію даних) з ACID-консистентністю транзакцій (курс PostgreSQL) — терміни схожі, але описують різні, хоч і споріднені, властивості на різних рівнях системи.
CAP-теорема стверджує, що розподілена система не може одночасно гарантувати консистентність, доступність і стійкість до мережевого розділення — оскільки розділення на практиці неминуче, реальний вибір відбувається між консистентністю (CP: відмовити, а не показати застарілі дані) і доступністю (AP: продовжити відповідати, ризикуючи тимчасовою неузгодженістю). Це ситуативне рішення для конкретного типу даних, а не універсальна властивість усієї системи.