У меня есть два приложения: Приложение 1 и Приложение 2. Оба приложения - Rails.Приложение 1 собирает данные от пользователя, и эти собранные данные необходимо синхронизировать с приложением 2. Я использую RabbitMQ и Sneakers (с 5 рабочими процессами) для процесса синхронизации между приложениями.Всякий раз, когда в приложении 1 происходит какое-либо обновление, задание помещается в очередь на сервере RabbitMQ.Оттуда Sneakers обрабатывает эти задания и сохраняет данные в базе данных приложения 2.
Архитектура, используемая для хранения данных в обоих приложениях, выглядит следующим образом.
Приложение 1
У автора много книг.
Таблица авторов:
id name
1 Kruze
2 Jiht
3 Rama
Таблица книг:
id name author_id
1 Book A 1
2 Book B 2
3 Book C 1
Приложение 2
Таблица авторов:
id name original_id books
1 Kruze 1 {'1':{'id':1, 'name':'Book A'}, '3':{'id':3, 'name':'Book C'}}
2 Rama 3 {}
3 Jiht 2 {'2':{'id':2, 'name':'Book B'}}
Здесь в столбце original_id указан идентификатор записи автора приложения 1, а в столбце книг - хэш, содержащий информацию обо всех книгах автора.
Проблема, с которой я столкнулсяздесь, когда было несколько обновлений в книгах одного и того же автора (создание или обновление) в одно и то же время несколькими пользователями, было несколько заданий, поставленных в очередь на сервер RabbitMQ.В приложении 2 Sneakers обрабатывает эти задания параллельно (пять заданий одновременно, поскольку в приложении 2 выполнялось пять процессов кроссовок).Каждый процесс кроссовок занимает разное время, чтобы совершить.Таким образом, в конце неверные данные присутствуют в приложении 2.
Enqueue Order Commit Order Process
1 1 1
2 2 2
3 5 5
4 6 1
5 4 4
6 3 3
7 7 2
8 10 5
9 9 4
10 8 3
Но когда существует только один процесс Sneakers, эта проблема не возникает.
Myвопрос: есть ли способ преодолеть эту некорректную проблему данных?