Я работаю над своим проектом, используя Akka для создания системы обработки в реальном времени, которая принимает поток Twitter (пока) и использует актеров для обработки указанных сообщений различными способами. Я читал об аналогичных архитектурах, которые другие построили с помощью Akka, и этот конкретный пост в блоге привлек мое внимание:
http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling
Здесь они объясняют различные проблемы, возникающие при передаче работы (т. е. сообщений) акторам по сравнению с тем, когда акторам приходится выполнять работу. Перефразируя статью, с помощью отправки сообщений нет встроенного способа узнать, какие единицы работы были получены каким работником, и это нельзя надежно отследить. Кроме того, если рабочий процесс внезапно получает большое количество сообщений, каждое из которых имеет довольно большой размер, вы можете оказаться перегруженными, и компьютеру может не хватить памяти. Или, если обработка интенсивно использует ЦП, вы можете сделать свой узел не отвечающим из-за перегрузки ЦП. Кроме того, в случае сбоя jvm вы потеряете все сообщения, которые были у актера(ов) в его почтовом ящике.
Вытягивание сообщений в значительной степени устраняет эти проблемы. Поскольку конкретный участник должен получить работу от координатора, координатор всегда знает, какая единица работы есть у каждого работника; если рабочий умирает, координатор знает, какую единицу работы нужно переработать. Сообщения также не хранятся в почтовых ящиках воркеров (поскольку он извлекает одно сообщение и обрабатывает его, прежде чем извлекать другое), поэтому потеря этих почтовых ящиков в случае сбоя актора не является проблемой. Кроме того, поскольку каждый работник будет запрашивать дополнительную работу только после того, как завершит свою текущую задачу, нет никаких опасений, что работник получит или начнет больше работы, чем он может выполнить одновременно. Очевидно, что с этим решением также есть проблемы, например, что происходит, когда происходит сбой самого координатора, но пока давайте предположим, что это не проблема. Подробнее об этом шаблоне вытягивания также можно узнать на веб-сайте Let It Crash, на который ссылается блог:
http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2
Это заставило меня задуматься о возможной альтернативе этому шаблону вытягивания, который состоит в том, чтобы выполнять проталкивание, но с прочными почтовыми ящиками. Примером, о котором я думал, была реализация почтового ящика, который использовал RabbitMQ (другие хранилища данных, такие как Redis, MongoDB, Kafka и т. д., также будут работать здесь), а затем каждый маршрутизатор акторов (все из которых будут использоваться для одной и той же цели) совместно используют та же очередь сообщений (или та же БД/коллекция/и т. д., в зависимости от используемого хранилища данных). Другими словами, у каждого маршрутизатора будет своя очередь в RabbitMQ, служащая почтовым ящиком. Таким образом, если один из маршрутов выходит из строя, те, которые все еще работают, могут просто продолжать получать из RabbitMQ, не слишком беспокоясь о том, что очередь переполнится, поскольку они больше не используют типичные почтовые ящики в памяти. Кроме того, поскольку их почтовый ящик не реализован в памяти, в случае сбоя маршрута большинство сообщений, которые он может потерять, будут просто единственными, которые он обрабатывал до сбоя. Если весь маршрутизатор выходит из строя, вы можете ожидать, что RabbitMQ (или любое другое используемое хранилище данных) будет обрабатывать повышенную нагрузку до тех пор, пока маршрутизатор не сможет восстановиться и снова начать обработку сообщений.
Что касается надежных почтовых ящиков, кажется, что еще в версии 2.0 Akka тяготел к их более активной поддержке, поскольку они реализовали несколько, которые могли работать с MongoDB, ZooKeeper и т. д. Однако похоже, что по какой-то причине они отказались от этой идеи. в какой-то момент, так как последняя версия (2.3.2 на момент написания этого поста) не упоминает о них. Вы по-прежнему можете реализовать свой собственный почтовый ящик, реализовав интерфейс MessageQueue, который предоставляет вам такие методы, как enqueue(), dequeue() и т. д., поэтому создание того, который работает с RabbitMQ, MongoDB, Redis и т. д., не кажется быть проблемой.
В любом случае, просто хотел узнать мнение ваших парней и девушек по этому поводу. Кажется ли это жизнеспособной альтернативой вытягиванию?
