Почему системы CP также не могут быть CAP?

Question

Я понимаю аббревиатуру CAP следующим образом:

• Постоянно: каждое чтение получает самую последнюю запись
• Доступный: каждый узел доступен
• Допустимое отклонение: система может продолжать выполнять обещания A и C, когда сетевое соединение между узлами прерывается

Если предположить, что мое понимание более или менее верное, то что-то беспокоит меня.

AFAIK, доступность достигается с помощью любого из следующих методов:

• Балансировки нагрузки
• Репликация в систему аварийного восстановления

Итак, если у меня есть система, которую я уже знаю, это CP, почему я не могу " сделать ее полной CAP ", применив один из этих методов, чтобы сделать ее также доступной? Я уверен, что мне здесь не хватает чего-то важного, но не знаю, что именно.

Answer 1

Это допуск раздела, что вы ошиблись.

Пока разделение не происходит, системы могут быть согласованными и доступными. Есть системы CA, которые говорят, что мы не заботимся о разделах. Вы можете запускать их внутри стоек с серверным оборудованием и делать разделение крайне маловероятным. Проблема в том, что, если возникают разделы?

Система может выбрать

• продолжать предоставлять услугу, надеясь, что другой сервер не работает, а не предоставляет ту же услугу и обслуживает другие данные - выбирая доступность (AP)
• прекратить предоставление услуги, потому что она больше не может гарантировать согласованность, так как не знает, работает ли другой сервер или фактически работает, и просто разрывается связь между этими двумя - выбор согласованности (CP)

Идея теоремы CAP заключается в том, что вы не можете обеспечить как доступность, так и согласованность, после того, как произойдет разбиение, вы можете либо пойти на доступность и надеяться на лучшее, либо играть безопасно и быть недоступным, но согласованным.

Вот 2 отличных поста, которые должны прояснить:

• Вы не можете пожертвовать допуском раздела. Идея состоит в том, что каждая действительно распределенная система должна иметь дело с разделением сейчас, а затем и, следовательно, системы CA будут мгновенно ломаться при первом появлении раздела.
• CAP Двенадцать лет спустя: как изменились "правила", он немного более актуален и демонстрирует более гибкую теорему CAP, где разработчики могут выбирать, как приложения ведут себя во время разбиения, и могут пожертвовать немного согласованности, чтобы получить некоторую доступность, ...

Таким образом, чтобы, наконец, ответить на ваш вопрос, если вы берете систему CP и реплицируете ее чаще, вы можете столкнуться с накладными расходами сообщений, отправляемых между узлами системы, чтобы поддерживать ее согласованность, или - в случае сбоя значительной части узлов или разделение сети происходит без какой-либо части, имеющей явное большинство, она не сможет продолжить работу, поскольку не сможет гарантировать согласованность больше. Но да, эти строки становятся более размытыми, и я думаю, что ссылки, которые я предоставил, дадут вам гораздо лучшее понимание.