Комментарии 5

Что-то или очень сложно, или я что-то упускаю.


  1. При сохранении объекта в БД с использованием оптимистической блокировки получаем его актуальную версию (та, что в update ... set Version = Version + 1 where Version = ...)
  2. Эту версию передаем в "задаче"
  3. Когда наступает время обработки, вычитываем из ES "индексированную" версию объекта и сравниваем с той, что пришла в задаче. Если версия из задачи меньше, то просто ничего не делаем
  4. Если индексировать всё же надо, то вычитываем сущность из БД (или получаем из 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 стучаться не надо.

Похода в ES можно избежать небольшой оптимизацией

Среди прочего lowkiq делает это.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.