Пропускная способность верблюжьего файла при изменении readLock =

Question

Я использую Apache Camel для передачи файлов из входного каталога в брокер сообщений. Файлы пишутся через SFTP. Чтобы избежать использования неполных файлов, которые все еще находятся в процессе передачи, я установил readLock=changed и readLockCheckInterval=3000.

. Например, один из моих тестов выглядит так:

    <route>
        <from uri="file:inbox?readLock=changed&amp;readLockCheckInterval=3000"/>
        <log message="copying ${file:name}"/>
        <to uri="file:outbox"/>
    </route>

Я проверяю это с (echo line 1; sleep 2; echo line 2) > inbox/test, и файл точно копируется, когда readLockCheckInterval=3000. Однако это не масштабируется, потому что компонент file будет ждать три секунды перед обработкой каждого файла. Поэтому, когда я тестирую с

for n in $(seq 1 100); do (echo line 1; sleep 2; echo line 2) > inbox/$n & done

, верблюду требуется пять минут, чтобы переместить файлы с inbox на outbox.

Я прочитал главу о параллельной обработке в Camel в книге действий. Но примеры фокусируются на распараллеливании обработки строк в одном потребляемом файле. Я не мог найти способ распараллелить самого потребителя.

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

Как повысить пропускную способность, не жертвуя целостностью в лицо сетевых задержек?

Answer 1

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

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

Для решения этой проблемы вам нужно использовать распределенный идемпотентный репозиторий , чтобы убедиться, что один и тот же файл не используется несколько раз во всех случаях .

Чтобы это работало с файловым компонентом, я полагаю, вам нужно установить readLock в idempotent-changed. Таким образом, потребитель должен ждать, пока файл больше не изменится, и когда несколько потребителей пытаются прочитать файл, «выигрывает» только первый. Все остальные пропускаются, поскольку файл уже известен в идемпотентном хранилище.

Answer 2

Вместо readLockCheckInterval=3000 я использую readLockMinAge=3s, и пропускная способность в порядке. Вот так выглядит мой тестовый маршрут:

    <route>
        <from uri="file:inbox?readLock=changed&amp;readLockMinAge=3s"/>
        <to uri="file:outbox"/>
    </route>

Как оказалось, я был не единственным в этой ситуации, и был билет , чтобы ввести минимальную задержку по возрасту чтобы решить эту проблему. Я просто слишком нетерпеливо читал документацию по файловым компонентам , где это уже объяснялось.