Comments 5
UPD: проект доступен под двойной LGPL or EULA лицензией.
Что-то или очень сложно, или я что-то упускаю.
- При сохранении объекта в БД с использованием оптимистической блокировки получаем его актуальную версию (та, что в
update ... set Version = Version + 1 where Version = ...) - Эту версию передаем в "задаче"
- Когда наступает время обработки, вычитываем из ES "индексированную" версию объекта и сравниваем с той, что пришла в задаче. Если версия из задачи меньше, то просто ничего не делаем
- Если индексировать всё же надо, то вычитываем сущность из БД (или получаем из API) и обновляем ES-индекс с использованием
version_type=external
Если так смотреть, то все еще проще, эластик сам умеет оптимистические блокировки.
Возможно вы просто не сталкивались с подобными проблемами.
У нас очень много дублей. Оптимистические блокировки никак это не исправят, все равно нужно ходить в эластик/бд.
Предположим, пришла задача с id = 1. Пока она лежит в очереди, пришло еще с десяток задач с id = 1. Все кроме последней задачи протухли и обрабатывать их уже не нужно. Опять таки оптимистическая блокировка не поможет.
https://youtu.be/TFCLaZr6vxY?t=11622 вот тут cto из ecwid рассказывают почему не взяли kafka, а написали сами. Мотивы схожие.
Пока она лежит в очереди, пришло еще с десяток задач с id = 1. Все кроме последней задачи протухли и обрабатывать их уже не нужно.
Я ровно об этом и писал. Если мы получили задачу с определенным ID заказа, то варианта развития событий всего два: мы либо обновляем индекс свежайшей информацией из БД, либо не делаем ничего, поскольку данные кто-то уже обновил и в индексе хранятся уже самые актуальные данные.
Похода в ES можно избежать небольшой оптимизацией — хранить в памяти словарь "ID заказа — последняя полученная из ES версия". В таком случае если версия новой задачи меньше, чем та, что есть у нас в памяти, то даже в ES стучаться не надо.
Lowkiq. Зачем мы его сделали?