А как в eventual consistent решается проблема, если у нас ноды начали реплицировать изменения, и в этот момент в ещё неизменную ноду записали другое значение? Получается такой конфликт. Что получим на выход? Как повезет?
Это проблема lost update и concurrency. И она решается несколькими способами типа idempotency, кворума или LWW (Last Write Wins), или версионностью в nosql. Также есть другие техники, я постараюсь про них рассказать через одно видео. Там будет понятней намного. Если у нас мастер-мастер с постгрей, то иногда такие проблемы могут быть и не решаемы и это не любят использовать. Поэтому лучше заранее договариваться, какую бд брать и для каких целей и какие техники борьбы с конкарренси заюзать. Такие же проблемы могут возникнуть и с брокерами сообщений, например если дать параллельно нескольким процессам брать мессаджи из очереди, что может нарушить порядок. В кафке есть спец механизмы для борьбы с этим, если такая потребность есть. Обычная рассинхронизация часов тоже может привести к этому и мастер мастер оставит не валидное значение, если юзаем timestamp, к примеру
господи шо за канал мега имба
лайк не глядя, спасибо за Вашу работу
Лучшее объяснение по ACID что видел.
Классное видео! В качестве доп. ремарки я бы ещё упомянул CAP теорему)
Спасибо за видео! Eventual consistency - визуализация топ!
Спасибо большое за столь полезную информацию.
Gossiping можно очень мило перевести - на сплетничала, нашептал на ухо.
Спасибо за видео.
Спасибо) да я туплю иногда, когда думаешь на одном, говоришь на втором и наоборот 🤡
@@koduryem Не знаю, мне манера речи и понравилась). Особенно с поправкой на то, что нужно достаточно сложные концепции объяснить.
Спасибо) ну да, это довольно не просто делать)
А как в eventual consistent решается проблема, если у нас ноды начали реплицировать изменения, и в этот момент в ещё неизменную ноду записали другое значение? Получается такой конфликт. Что получим на выход? Как повезет?
Это проблема lost update и concurrency. И она решается несколькими способами типа idempotency, кворума или LWW (Last Write Wins), или версионностью в nosql. Также есть другие техники, я постараюсь про них рассказать через одно видео. Там будет понятней намного. Если у нас мастер-мастер с постгрей, то иногда такие проблемы могут быть и не решаемы и это не любят использовать. Поэтому лучше заранее договариваться, какую бд брать и для каких целей и какие техники борьбы с конкарренси заюзать. Такие же проблемы могут возникнуть и с брокерами сообщений, например если дать параллельно нескольким процессам брать мессаджи из очереди, что может нарушить порядок. В кафке есть спец механизмы для борьбы с этим, если такая потребность есть.
Обычная рассинхронизация часов тоже может привести к этому и мастер мастер оставит не валидное значение, если юзаем timestamp, к примеру
А есть ли ссылка на презу?