а как сделать СР систему, по идее, если какой-то узел выходит из строя или между узлами прерывается связь, то пользователям вообще должно быть запрещено взаимодействие с любым из узлов пока не устранится проблема?
Михаил, Вы все верно поняли. CP системы должны быть согласованы в любой момент времени. Это значит, что пока, например, запись данных не завершиться на всех узлах системы, система не вернет ответ пользователю и он будет ждать. Если запись на один или несколько узлов не удалась, происходит откат везде и сразу (пример: двухфазный коммит). Примером CP систем является Redis, например
Прошу прощения за долгий ответ. О CP отвечу прямо тут: Исходя из определений C и P (www.fullstackguy.ru/knowledge-base/distributed-systems/cap-theorem/), можно представить, что CP система будет консистентна и при этом устойчива к секционированию. Что это значит? 1) что система будет хранить свои данные на нескольких узлах. То есть - будет дупликация данных. 2) что система будет позволять пользователям читать данные с любого узла, даже если связь между двумя узлами нарушена 3) что система НЕ будет позволять производить запись новых данных, если узлы не связаны друг с другом (при дублировании данных на разных узлах - в случае, если узлы не могут связаться друг с другом, это нарушение целостности данных или Consistency принципа)
хотел уточнить по поводу партишн толеранс, в примере был запрос на один сервер, где мы обновили данные, потом идет запрос на чтение данных со второго сервера, и получает старые данные) так и в чем тут суть?) я туповат, признаюсь, не стыдно) суть в том, что второй сервер вместо того, чтоб отвалиться и сказать, что я не дам тебе данные, потому что я не общаюсь с первым сервером, просто возвращает старые данные?
Вы всё верно поняли: если у вас нарушен механизм общения между двумя серверами или кластерами, но вы всё еще хотите получать со всех них данные, то должны мириться с тем, что данные будут неконсистенты. Если же вы хотите консистентные данные, то должны попрощаться с partition tolerance и получать данные только с того сервера, где они последней версии, либо попрощаться с availability и ждать, пока связь между двумя частями (в данном случае) восстановится и целостность данных восстановится. Всё куда проблемней, если у вас кластеров несколько и на одном одни данные свежие, а на другом другие :) Поэтому в некоторых системах никуда не уйти от одного класса, в других от другого. Скажем, если вы закинули в корзинку товар, которого уже нет, это, хоть и нехорошо, но допустимо, однако он на чекауте уже должен быть обязательно недоступен. Можете посмотреть еще что такое eventually consistent, тоже интересно и полезно в этом свете. Также, отсюда вырастает еще один серьезный класс проблем: т.н. "split brain", с которым тоже надо знать, как бороться.
