Приложение распределенной генерации и обработки сообщений

Приложение использует redis list (nodes:queue) для очереди сообщений, redis list (nodes:ids) для хранения идентификаторов нод (список необходим для назначения генератора), redis hashtable (nodes:list) для хранения списка нод, в котором хэш-ключ - идентификатор ноды, значение - время последней активности, redis list для хранения сообщений, обработанных с ошибкой, Ключ nodes:emitter содержит идентификатор текущей ноды-генератора.

Redis ключи, используемые в приложение кроме лога ошибок, имеют ttl 10 секунд, чтобы не оставлять данные после завершения работы.

Функция run является entry point и выполняет следующие действия:

• проверка параметра getErrors, вывод списка ошибок и завершение процесса, если параметр присутствует
• регистрация ноды (_registerNode). Внутри транзакции создается запись ноды в хэштаблицу и идентификатор ноды добавляется в список
• рекурсивная проверка является ли нода генератором и высставление соответсвующего флага (так как в случае падения назначить нового генератора может одна любая другая нода)
• проверка флага генератора с интервалом 500 мс и отправка сообщения (_emitEvent), если флаг высставлен
• постоянная проверка флага генератора и получение сообщения (_receiveEvent), если флаг не высставлен
• проверка состояния всех нод (_nodesHealthCheck) с интервалом 200 мс

Время последней активности ноды обновляется при посылке, получении сообщения и при назначении нового генератора. Все ноды проверяются на активное состояние. Если какая либо нода неактивна в течении 1000 мс, то она удаляется из хэштаблицы и из списка идентификаторов. Если неактивным был признан генератор, то назначается новый (_assignEmitter) путем выбора первого идентификатор из списка оставшихся активных нод.

Запуск

node node.js [--getErrors] [--rhost] [--rport] [--rdb]

• getErrors - получение списка ошибок
• rhost - установка хоста redis, по умолчанию 127.0.0.1
• rport - установка порта redis, по умолчанию 6379
• rdb - установка индекса базы redis, по умолчанию 0

Тестирование

Тестировал пару дней на 10-ти нодах, 1 300 000 сообщений с целью выявить утечки, проблемы типа "обработки одного сообщения несколько раз", "не назначение генератор"а после падения" или "назначение нескольких генераторов". Такого рода проблем выявлено не было. Ноды работали ровно, никаких значительных скачков по CPU или потребления памяти.