Comments 6
Я как проджект был тем самым «бизнесом» который просил просто сделать по fifo, а тех лид мне на бумажке популярно объяснял примерно то же самое что в статье :)
Сталкивался с такой же проблемой при расчете доступности товара к продаже. С одной стороны два сообщения «товар заблокирован» и «товар снова доступен» нельзя перепутать местами, иначе товар останется не в том статусе. С другой стороны, нагрузка была просто гигантская и нужно было много партиций Кафки.
Решение - партицию куда отправить сообщение выбирали по хэшу артикула. Появилась гарантия что один артикул попадётся строго в одной партиции и будет обработан последовательно, а с другой стороны нет проблем перемешивать сообщения от разных артикулов.
В довесок еще и потребитель навесил логику обработки сообщений по временной метке, что бы игнорировать устаревшие смены состояний.
Я бы сказал, что и в мире FIFO переоценен, и его суют, куда не попадя потому, что кто-то когда решил, что это хорошая идея. К примеру, та же очередь на кассу в супермаркете, к врачу, или очередь на рассмотрение заявления на ПМЖ.
Если обобщить, то живая очередь означает лишь функцию выбора следующего заказа (заказчика) при освобождении обслуживателя, которая ранжирует заказы по уже просранному времени в этой очереди. То есть, то абсолютно неконструктивному критерию, не имеющему ценности. Да, в этом есть пара плюсов - например, ни один заказ не может ждать обработки вечно. Или, есть "справедливость" между заказчиками. Или то, что при возникновении несоразмерно большой в сравнении с получаемой ценность очереди, происходит саморегуляция и часть заказчиков уходит получать услугу в другом месте.
Проблема в том, что при достижении определённого размера очереди услуга теряет смысл в принципе. Хороший пример - западная Европа, где можно ждать 6 месяцев визита к стоматологу и 2 года визита к психиатру. Объективно, при таком сроке можно лишь констатировать, что услуга в должном качестве не предоставляется в принципе (ходить с больным зубом 6 мес неадекватно, а человек с проблемами с головой может создать достаточно проблем себе и окружающим за 2 года). Причём, за счёт того, что ждут все, она не предоставляется в должном качестве никому.
И, если так подумать, то, если отказаться от концепции того, что заказ, просравший время в очереди, важнее, то можно сделать эффективные решения под целевую функцию каждого конкретного случая.
Приведу пример: олдскульные таксисты в заповедниках, где это ещё есть, например, на Мадейре, стоят длинными вереницами машин в специально отведенных местах. И очередного клиента обслуживает первый в этой очереди. После чего остальные подкатываются на 1 корпус вперёд (иногда даже мускульной силой, ибо зачем заводить мотор ради 5 метров, а размяться не помешает). Убер заменил это логичным алгоритмом "кто ближе, тот и папа" и рассредоточением машин по городу.
И так можно разобрать любой кейс. Та же стоматология, например. Либо надо решать проблему радикально, расширяя количество стоматологов. Либо, если на уровне принятия решения нет такой возможности, то перестраивать процесс, например, делая запись не через интернет, а через медсестру, делающую первичный осмотр и отказывающую в записи всем, у кого недостаточно критичный случай. Или супермаркет - можно иметь разные кассы с разной ценой. Например, 8 касс с базовой ценой. 1 с +5%, 1 с +10%. Тогда человек, ценящий свое время, сможет решить задачу быстро. Ну, или совсем теоретический пример, когда вместо очереди стоит толпа, и при освобождении кассы происходит аукцион. Победитель платит в кассу цену товара + победную ставку за обслуживание
В примере с виноградом бизнес-логика складского учета почему-то переложена на очередь FIFO - неудачный пример. Какой именно виноград взять со стеллажа (понедельника или вторника) решает же не очередь сообщений.
В примере с банком - если у нас 10 млн пользователей, нам не нужно выстраивать операции Васи в очередь перед операциями Пети. Т.е. строгий глобальный FIFO редко нужен. Нужна консистентность в рамках одной сущности (аккаунта пользователя), т.е. "простой" будет только по user_id. Уточню - Kafka гарантирует порядок только при условии, что потребитель не читает сообщения параллельно из одной партиции (число консюмеров <= числа партиций).
А в целом, спасибо, идея масштабируемости - это правильный способ выявить требования и аргумент, который можно приводить заказчикам.
И так, у нас есть склад с фруктами. В понедельник привезли партию винограда со сроком годности 5 дней. Во вторник привезли партию винограда со сроком годности 3 дня(потому что поставщик привез товар постарше).
Разве, в этом случае, не будет двух различных позиций номенклатуры и двух отдельных карточек в интернет-магазине с явным указанием срока годности?
Но, вообще говоря, учёт партий — важная штука. В первую очередь, конечно же, следует реализовывать партию с меньшим сроком годности.
Почему бизнес хочет FIFO и почему это не всегда «серебряная пуля»