Всем привет. Вчера провел викторину(https://t.me/romankh3/226), в которой решил узнать насколько известно о семантике доставки событий в распределенных системах. В итоге, в момент пока пишу этот пост, правильно ответили 24%. А это значит, что такие вещи стоит повторить еще раз и закрепить для себя. Прежде чем грузить теорией, хочется описать почему это важно. Ведь смысл потреблять информацию, если не знаешь зачем она тебе, правильно? Так вот, в распределенных системах сбои - это норма. Может сеть лагать, могут падать узлы, сообщения между системами могут теряться или дублироваться. И вот здесь без понимания четкой семантики невозможно построить надежную бизнес-логику. Какие могут быть моменты, например: 1️⃣ Что будет, если дважды спишутся деньги со счета? 2️⃣ Что будет, если заказ потеряется? 3️⃣ Что будет, если в целом получится ситуация, при которой у нас хранилище данных перейдет в неконсистентное состояние? Думаю мало кто будет спорить с тем, что будет так себе... Поэтому давайте поговорим о семантике доставки. Какие бывают? 🙈At-most-once (не более одного раза)🙈 Сообщение может быть доставлено только один раз, а может быть и вообще не доставлено. В этом случае у нас простая и быстрая реализация этого подхода, без механизма повторов. Самый главный риск - это то, что сообщение будет потеряно при сбоях. Как пример: это обычный HTTP запрос, если сбой по сети или что-то еще, то информация просто потеряется. 👍At-least-once (не менее одного раза)👍 Сообщение гарантировано будет доставлено, вместе с тем может быть доставлено повторно. Такой подход требует идемпотентности обработчика сообщений, чтобы если будет доставлено повторно, то ничего бы не изменилось. Такой подход используется большинством брокеров сообщений по-умолчанию (Kafka, RabbitMQ). 🚀Exactly-once (ровно один раз)🚀 Самая сложная и одновременно самая желанная - сообщение гарантировано будет доставлено и доставлено будет один раз. Такой подход в свою очередь уже требует сложных механизмов для реализации: транзакций и согласования состояний. Как вариант приближенный к этой модели - это Kafka с transactional producer + idempotent consumer. ✍️ Вместо вывода: Тема важная для разработки и знать о ней нужно хотя бы с позиции понимания терминов, что они несут за собой, чтобы при столкновении было сразу понятно. Разумеется, это быстрое overview цель которого приоткрыть вам дверь в этом вопросе. Всем дочитавшим до конца спасибо за внимания, можем продолжить дискуссию в комментариях! Подписывайтесь на мой канал в тг: https://t.me/romankh3 #семантика_доставки
Frontend-университет