Комментарии 6
Напишу свое мнение про данную тему в Редисе, т.к. последние полгода довольно плотно использую его «и в хвост и в гриву».
Из хорошего — все нужные примитивы, действительно, есть. Поддержка lua-хранимок (кастомных команд) сделана просто великолепно. И можно построить космический корабль, если хочется (единственное «но» — БД не может быть больше памяти, вот это неустранимый минус).
А теперь о плохом. Такое ощущение, что разработчики Редиса пытались сделать «швейцарский нож» и хватались делать абсолютно все фич-реквесты пользователей, не следя особо за архитектурой и смыслом. Например, блокирующий BLPOP (как и бОльшая часть остальных блокирующих команд) не имеет не малейшего смысла, потому что обработку очереди на ее основе не построить: если клиент упал после выемки элемента, но до его обработки, элемент потеряется. Это архитектурная проблема. (Впрочем, внутри lua-хранимок такие команды могут еще иметь хоть какой-то смысл.)
В целом использование редис-примитивов эмоционально похоже на хождение по минному полю: без должного опыта, просто хватаясь за те команды, которые на первый взгляд кажутся осмысленными, ничего надежного не построить. Вот если была какая-то систематизация за всем этом, было бы гораздо лучше.
если клиент упал после выемки элемента, но до его обработки, элемент потеряется
В статье приведён пример BRPOPLPUSH, про 2 очереди:
1) общая очередь с уведомлениями о заданиях
2) processing-очередь с заданиями, которые нужно удалять после выполнения
В примере при запуске/перезапуске клиента, невыполненные задания начинают выполнятся.
На мой взгляд правильнее при запуске/перезапуске клиента + по таймеру периодически проверять время создания заданий и просто переносить просроченные в общую очередь.
Brpolpush-то есть. Но речь была не об этом, а о том, что есть и вещи, которые использовать нельзя никак, и таких вещей подозрительно много.
Но некоторых вещей также нет совсем, либо же сделано неправильно. Например, hset с expiration элемента — нет. А для кастомного шардинга (выбора слота) часть ключа нужно обрамлять в {}, что несовместимо с бинарными ключами (приходится ключи делать base64 и терять половину места: +треть дает base64 и еще +2 байта дают эти {}).
Результат на строке 5 покажет изменения только экземпляра 2, и изменение цвета экземпляром 1 будет утеряно
Так JSON же здесь не причем, это так называемое состояние гонки (race condition), которое можно продемонстрировать даже на простом инкрементировании числа на стороне клиента
Redis Best Practices, часть 2