Как создать масштабируемый приемник вызова rpc?

Question

Я должен слушать вызовы rpc, укладывать их где-нибудь, обрабатывать их и отвечать. Дело в том, что они не запускаются, как только они приходят. Ответ является ACK для каждого полученного вызова rpc. Проблема в том, что я хочу создать его так, чтобы у меня было много серверов для прослушивания, написанных в одном и том же стеке вызовов, набирая их, когда они приходят.

Моя цель - прослушивать как можно больше звонков. Как мне это достичь?

Моей основной технологией является Perl и node.js, но для этой задачи будет использоваться любое программное обеспечение с открытым исходным кодом.

Answer 1

Звучит так, как будто любая очередь заданий будет делать то, что вам нужно; Я лично большой поклонник использования Redis для такого рода вещей. Поскольку списки Redis поддерживают порядок вставки, вы можете просто указать LPUSH информацию о вызове RPC в конец списка с любого количества веб-серверов, которые прослушивают вызовы RPC, и где-то еще (в другом процессе/на другом компьютере, я полагаю) RPOP (или BRPOP) и обработать их.

Поскольку Node.js использует полностью асинхронный ввод-вывод, предполагая, что вы не выполняете много обработки в ваших слушателях RPC (то есть вы только слушаете запросы, отправляете ACK и нажимаете на Redis), мой думаю, что Node будет чрезвычайно эффективным при этом.

Отказ от использования Redis для очереди: если вы хотите, чтобы в случае катастрофического сбоя задания не были потеряны, вам нужно будет реализовать немного больше логики; от RPOPLPUSH документации:

Pattern: Надежная очередь

Redis часто используется в качестве сервера обмена сообщениями для выполнения обработки фоновых заданий или других видов сообщений задач. Простую форму очереди часто получают толкание значений в список со стороны производителя и ожидание этих значений у потребителя с использованием RPOP (с использованием опроса) или BRPOP, если клиент лучше , обслуживаемый операцией блокировки.

Однако в этом контексте полученного очередь не является надежной, как сообщения могут быть потеряны, например, в случае существует проблема сети или если потребитель авария только после того, как сообщения получено, но он по-прежнему обрабатывать ,

RPOPLPUSH (или BRPOPLPUSH для варианта блокировки) предлагает способ избежать этой проблемы : потребитель получает сообщение и в то же время отталкивает его в список обработки. Он будет использовать команду LREM, чтобы удалил сообщение из списка обработки после обработки сообщения .

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