а как сделать СР систему, по идее, если какой-то узел выходит из строя или между узлами прерывается связь, то пользователям вообще должно быть запрещено взаимодействие с любым из узлов пока не устранится проблема?
Михаил, Вы все верно поняли. 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
Спасибо за наводку. Ссылку обновил 🤝
хотел уточнить по поводу партишн толеранс, в примере был запрос на один сервер, где мы обновили данные, потом идет запрос на чтение данных со второго сервера, и получает старые данные) так и в чем тут суть?) я туповат, признаюсь, не стыдно) суть в том, что второй сервер вместо того, чтоб отвалиться и сказать, что я не дам тебе данные, потому что я не общаюсь с первым сервером, просто возвращает старые данные?
Вы всё верно поняли: если у вас нарушен механизм общения между двумя серверами или кластерами, но вы всё еще хотите получать со всех них данные, то должны мириться с тем, что данные будут неконсистенты. Если же вы хотите консистентные данные, то должны попрощаться с partition tolerance и получать данные только с того сервера, где они последней версии, либо попрощаться с availability и ждать, пока связь между двумя частями (в данном случае) восстановится и целостность данных восстановится.
Всё куда проблемней, если у вас кластеров несколько и на одном одни данные свежие, а на другом другие :) Поэтому в некоторых системах никуда не уйти от одного класса, в других от другого. Скажем, если вы закинули в корзинку товар, которого уже нет, это, хоть и нехорошо, но допустимо, однако он на чекауте уже должен быть обязательно недоступен.
Можете посмотреть еще что такое eventually consistent, тоже интересно и полезно в этом свете. Также, отсюда вырастает еще один серьезный класс проблем: т.н. "split brain", с которым тоже надо знать, как бороться.
А что с сайтом?(( Хотел статью почитать...
Спасибо что обратили моё внимание! 🤝 Забыл обновить ссылку. Вот правильная: fullstackguy.anverbogatov.ru/cap-theorem/
@@fullstackguy Супер! Спасибо!
Теорема не может "работать" или "не работать". Теорема может быть истинной или нет, иметь доказательство или не иметь.
Как всё медленно, скорость 1.5 выручает
Целью этого канала Я ставлю просвещение. А сложные знания, вроде этих, торопежки не терпят.
Для меня скорость вполне комфортная. Есть возможность обдумать сказанное
Consistency (согласованность) - это свойство, которое говорит, что система имеет согласованное состояние. Ага. Не поспоришь.
Учился у лучших! От создателей «это вам не это» и «не только лишь все» 😀