Обработка регистрации по потоку данных

Question

У меня есть экземпляр EC2 с потоком данных, который использует событие-эмиттер для обработки данных. Например.

stream.on('new event', function doSomething(event){ do more stuff...}) 

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

Следовательно, я решил, что отправлю журналы в пакетном режиме. Например.

let logArray = []; 
function sendToLogs(logs) {\** send stuff *\} 

stream.on('new event', function doSomething(event){ 
    \\do some stuff 

    logArray.push({newLog: event}) 
    if (logArray.length >= 500) { 
    sendToLogs(logArray) 
    logArray = []; 
    } 
}) 

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

Кроме того, использование журналов cloudwatch требует от меня передать «sequenceTokens» между различными вызовами функции ведения журнала. Если два события одновременно запускают условие регистрации, все может стать странным. (Эта проблема будет существовать, даже если я зарегистрировал каждое событие отдельно.)

Как я должен обрабатывать ведение журнала через этот поток данных?

Answer 1

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

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

Недостатками являются:

1. Вы должны написать это отдельный процесс для обработки протоколирование в CloudWatch или где-либо.
2. Ваши журналы не будут в режиме реального времени. Между журналами основного приложения и приложением журнала в CloudWatch будет по крайней мере некоторое время ожидания. При дополнительных процессах регистрации вы должны быть близки, но это не гарантия.