Чтение верблюжьего файла: состояние гонки с 2 активными серверами

Question

В нашем проекте ESB у нас есть много маршрутов чтения файлов с протоколом file2 или ftp для дальнейшей обработки. Важно отметить, что файлы, которые мы читаем локально (протокол file2), подключаются к общим сетевым ресурсам через разные протоколы (NFS, SMB).

Теперь у нас проблемы с условиями гонки. Оба сервера читают файл и обрабатывают его. Мы уменьшили вероятность этого с помощью опции preMove, но время от времени повторное чтение все еще происходит, когда оба сервера опрашивают в одну и ту же миллисекунду. Согласно документации, idempotentRepository вместе с readLock=idempotent могут помочь, например, с HazelCast.

Однако мне интересно, подходит ли это решение для моей проблемы, поскольку я не знаю, будет ли оно работать во всех случаях. За считанные миллисекунды оба сервера читают файл, поэтому информация о том, что один сервер уже обработал файл, должна быть доступна в сетке HazelCast в тот момент, когда второй сервер пытается прочитать. Это возможно? Что произойдет, если будут минимальные задержки (например, связанные с сетью)?

Кроме того, настройка readLock=idempotent доступна только для file2, но не для ftp. Как решить эту проблему там?

Опять же: проблема не в том, чтобы предотвратить повторное копирование файлов, а в том, чтобы предотвратить гонку.

Answer 1

AFAIK. Идемпотентное хранилище должно предотвратить в вашем случае , чтобы оба потребителя прочитали один и тот же файл.

Задержка между обнаружением файла и записью в Hazelcast не имеет значения, поскольку потребители файлов не вводят то, что они читают. Вместо этого они оба запрашивают у хранилища эксклюзивную блокировку чтения . Первый выигрывает, второй отказывается, поэтому он переходит к следующему файлу.

Если вы хотите минимизировать потенциальные конфликты между потребителями, вы можете включить shuffle=true, чтобы рандомизировать порядок файлов для использования.

Для проблемы с отсутствующим readLock=idempotent на клиенте ftp: возможно, вы могли бы создать отдельный маршрут передачи только с одним потребителем, который загружает файлы. Тогда ваш файл-маршрут может обработать их идемпотентами.