Сценарий работает на 50 серверах. Как я могу удостовериться, что только один выполняет конкретный шаг?

У вас есть исходный код для сброса? Может быть подключения к базе данных не закрыты? Процессы, ожидающие подключения HTTP, которые никогда не закрываются.

Можете ли вы опубликовать журналы?

Выполните ps -ef и убедитесь, что ничего не запущено. Я видел, как веб-процессы оставляют зомби, которые не умрут, пока вы не убьете -9. Иногда завершение работы не работает или работает не полностью, и эти потоки или процессы будут удерживать ОЗУ, а иногда и ЦП.

Это может быть бесконечный цикл где-то в коде или сбойный процесс, удерживающий соединение с базой данных.

Какие модули NPM используются? Все ли они самые свежие?

Вы ловите исключения? См .: http://geoff.greer.fm/2012/06/10/nodejs-dealing-with-errors/

Здесь необходимо рассмотреть серьезные компромиссы. Этот ответ не дает вам представления о том, что делать, когда работа наполовину сделана.

NFSv3 поддерживает механизм атомарной блокировки в новых ядрах (ну, честно говоря, довольно старый) http://nfs.sourceforge.net / # faq_d10 . Таким образом, некоторый механизм для семафора теоретически может быть реализован следующим образом:

1. Готовый файл уже существует на хосте. (это сигнал только для сценария 2)
2. Откройте файл «получить» на хосте, используя O_EXCL .
3. Переименуйте «готово» в «готово.old».
4. Сделайте свое здесь особая работа.
5. Откройте файл готовой работы на хосте, используя O_EXCL .
6. Отмените связь с done.old.
7. Отмените связь с файлом accept

Вот некоторые сценарии оболочки шаблона что пытается это.

#!/bin/bash
# WARNING: This is a cricital line! NEVER EDIT THIS
set -e -o noclobber

BASEPATH=/tmp
cd "${BASEPATH}"

# 1. A done file exists on the host already (this is a signal for script 2 only)
# 2. Open an 'acquire' file on the host using `O_EXCL`.
echo > 'acquire'

# 3. Rename 'done' to 'done.old'.
mv 'done' 'done.old' 2>/dev/null || :

# 4. Do your special work here.
echo "How much wood could a woodchuck chuck if a woodchuck could chuck wood?"

# 5. Open a 'done' file using O_EXCL
echo > 'done'

# 6. Unlink 'done.old'.
unlink 'done.old' || :

# 7. Unlink 'acquire'.
unlink 'acquire'

Самая важная строка - это set -e -o noclobber , которая служит двум целям.

• Она обеспечивает выход из сценария в случае сбоя какой-либо команды.
• Сценарий не перезаписывает файлы (делает открытие происходит в O_EXCL).

Учитывая набор критериев, наиболее важной функциональной частью является echo> collect , которая будет атомарно открывать файл получения. Если это не удается (потому что это есть у кого-то другого, даже если открываются ДВА одновременно, только один будет выигрывать) опция -e в set гарантирует, что мы выходим из скрипта.

] Никогда не должно быть двух таких сценариев, работающих параллельно. Однако этот сценарий не предлагает решение, в котором два сценария выполняются один за другим (что было бы разрешено в его текущей форме). Я полагаю, что лучшим средством для этого было бы изменить файл «готово» на некоторый именованный файл с меткой времени, наличие которого вы ищете до начала процесса. Таким образом, предполагается, что «безопасно» полагаться на время как на среду для определения безопасности критичности кода.

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

Другие вещи, не охваченные:

• Что, если процесс начинается, но не завершается?
• Если общий каталог недоступен до или в середине процесса решения этой проблемы.
• Если хост слишком долго выполняет «безопасные» действия на шаге 4, как это повлияет на следующий запуск? Должны ли мы использовать старый экземпляр после его завершения или новый?

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

Могу я предложить следующее,

Назначить один сервер репозиторием репликационного кода. Затем вы можете cron обновлять этот репозиторий с любым интервалом. Остальные серверы могут проверить наличие локального репозитория, а затем выполнить синхронизацию файлов с назначенного сервера. Эта информация может храниться в общем пространстве файлового сервера. Это будет довольно легко автоматизировать, и оно должно быть достаточно надежным.

Еще одно радикальное решение -> - использовать синхронизацию bittorrent. Сервер репозитория будет доступен для чтения и записи, в то время как другие будут иметь общий доступ только для чтения. Может быть быстрее, поскольку сетевая нагрузка будет распределена между серверами. btsync можно настроить через файл конфигурации, и клиент linux работает довольно хорошо.

РЕДАКТИРОВАТЬ: вы можете пропустить сервер репозитория для радикального решения и придерживаться btsync.

Ура! :

Вам нужно будет использовать какой-то файл блокировки (прежде чем что-либо делать), который показывает владельца первого скрипта и время выполнения. Когда кто-то другой пытается выполнить сценарий, он должен найти файл блокировки и выйти. В конце скрипта (если он запущен) удалите указанный файл блокировки.