а как сделать СР систему, по идее, если какой-то узел выходит из строя или между узлами прерывается связь, то пользователям вообще должно быть запрещено взаимодействие с любым из узлов пока не устранится проблема?
Михаил, Вы все верно поняли. 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", с которым тоже надо знать, как бороться.
Крайне понятное и лаконичное объяснение темы. Один из лучших ресурсов про САР, что я видел. Большое вам спасибо!
Большое спасибо Вам, Егор, за теплые слова! 🤝
Очень понятно, с примерами и подробностями. Спасибо!
Пожалуйста! Рад, что видео оказалось полезным! 🤝
лучшее объяснение, что мне приходилось слышать, спасибо!!
Приятно слышать! Спасибо за добрые слова! 🤝
Жму руку!👍
Рад, что видео понравилось! 🤝
очень рад, что нашел ваш канал - прекрасное изложение
Спасибо за тёплые слова! 🤝
оч классно. Недоумеваю почему так мало просмотров. Удачи каналу. Шалом из Израиля
Большое спасибо! Рад что мои видосы оказались полезными 🤓
Круто, самое поняиное объяснение с примерами. Лайк
Очень познавательно и интересно, спасибо больше за столь информативное видео
Спасибо за добрые слова! Рад, что видео оказалось полезным! 🤝
Очень доступно. Спасибо
Рад, что материал понравился! 🤝
Очень хорошо подан материал!
Михаил, большое спасибо за отзыв! Я рад что моя работа оказалась полезной! 🤝
спасибо, наконец понял
Крутяк! 🤝
Thanks a lot, it was very helpful
I’m happy that it was useful for you 🤝
Топчик, однозначно👍
Видео супер полезное, лайк
Рад что пригодилось! 🤝
а как сделать СР систему, по идее, если какой-то узел выходит из строя или между узлами прерывается связь, то пользователям вообще должно быть запрещено взаимодействие с любым из узлов пока не устранится проблема?
Михаил, Вы все верно поняли. CP системы должны быть согласованы в любой момент времени. Это значит, что пока, например, запись данных не завершиться на всех узлах системы, система не вернет ответ пользователю и он будет ждать.
Если запись на один или несколько узлов не удалась, происходит откат везде и сразу (пример: двухфазный коммит).
Примером CP систем является Redis, например
не покрыт кейс: CP
Прошу прощения за долгий ответ.
О CP отвечу прямо тут:
Исходя из определений C и P (www.fullstackguy.ru/knowledge-base/distributed-systems/cap-theorem/), можно представить, что CP система будет консистентна и при этом устойчива к секционированию.
Что это значит?
1) что система будет хранить свои данные на нескольких узлах. То есть - будет дупликация данных.
2) что система будет позволять пользователям читать данные с любого узла, даже если связь между двумя узлами нарушена
3) что система НЕ будет позволять производить запись новых данных, если узлы не связаны друг с другом (при дублировании данных на разных узлах - в случае, если узлы не могут связаться друг с другом, это нарушение целостности данных или Consistency принципа)
Ссылка на статью not found
Спасибо за наводку. Ссылку обновил 🤝
А что с сайтом?(( Хотел статью почитать...
Спасибо что обратили моё внимание! 🤝 Забыл обновить ссылку. Вот правильная: fullstackguy.anverbogatov.ru/cap-theorem/
@@fullstackguy Супер! Спасибо!
хотел уточнить по поводу партишн толеранс, в примере был запрос на один сервер, где мы обновили данные, потом идет запрос на чтение данных со второго сервера, и получает старые данные) так и в чем тут суть?) я туповат, признаюсь, не стыдно) суть в том, что второй сервер вместо того, чтоб отвалиться и сказать, что я не дам тебе данные, потому что я не общаюсь с первым сервером, просто возвращает старые данные?
Вы всё верно поняли: если у вас нарушен механизм общения между двумя серверами или кластерами, но вы всё еще хотите получать со всех них данные, то должны мириться с тем, что данные будут неконсистенты. Если же вы хотите консистентные данные, то должны попрощаться с partition tolerance и получать данные только с того сервера, где они последней версии, либо попрощаться с availability и ждать, пока связь между двумя частями (в данном случае) восстановится и целостность данных восстановится.
Всё куда проблемней, если у вас кластеров несколько и на одном одни данные свежие, а на другом другие :) Поэтому в некоторых системах никуда не уйти от одного класса, в других от другого. Скажем, если вы закинули в корзинку товар, которого уже нет, это, хоть и нехорошо, но допустимо, однако он на чекауте уже должен быть обязательно недоступен.
Можете посмотреть еще что такое eventually consistent, тоже интересно и полезно в этом свете. Также, отсюда вырастает еще один серьезный класс проблем: т.н. "split brain", с которым тоже надо знать, как бороться.
Теорема не может "работать" или "не работать". Теорема может быть истинной или нет, иметь доказательство или не иметь.
Как всё медленно, скорость 1.5 выручает
Целью этого канала Я ставлю просвещение. А сложные знания, вроде этих, торопежки не терпят.
Для меня скорость вполне комфортная. Есть возможность обдумать сказанное
Consistency (согласованность) - это свойство, которое говорит, что система имеет согласованное состояние. Ага. Не поспоришь.
Учился у лучших! От создателей «это вам не это» и «не только лишь все» 😀