Локальное, малообъемное сообщение для массивно распределенных клеточных автоматов

Question

Я работаю над разработкой моделирования с использованием распределенных клеточных автоматов. Моделирование ячеек распределяется между узлами и координируется с использованием ZooKeeper. Постоянные данные хранятся в Riak. Само клеточные автоматы написаны на Python.

Было бы очень удобно для моей симуляции, если бы ячейка могла передавать небольшую громкость (между несколькими и десятками в секунду, скажем) сообщений (возможно, пару с ключом) своим непосредственным соседям (окрестности Манхэттена). Однако для моделирования миллионов ячеек наивный подход заканчивается миллионами маленьких почтовых ящиков, по одному для каждой ячейки и медленной струйкой сообщений в каждом ящике. Это приносит ZooKeeper или RabbitMQ на колени! I've been recommended DDS, но, похоже, это очень Enterprise, и никаких привязок Python я не могу найти.

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

Я направляюсь куда-нибудь рядом с реальным решением этой проблемы? Каким образом распределенные узлы могут передавать сообщения малого объема своим соседям?

Answer 1

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

ZooKeeper получает заболоченность, потому что он обеспечивает общий общий объем заказа на все сообщения. Я точно не знаю, какой тип координации требуется вашей системе через Zookeeper, но лучше всего работает с координацией курса, а не с мелкомасштабной координацией. (Где я работаю, мы называем эту роль, замок и ресурс блокировки соответственно уточнить намерения. Работник берет на себя роль вместо блокировки ресурса.)

Итак, вот несколько идей, с тем, что информация У меня есть.

Если сообщения не нуждаются в долговечности, наилучшим подходом было бы поддерживать соединение со своими соседями и отправлять сообщения непосредственно им. Я предполагаю 2D или 3D, поэтому число (Манхэттен) соседей невелико.

Остальная часть будет предполагать, что вам требуется прочность.

Одна система очереди сообщений должна обрабатывать миллионы сообщений; но они получают лучшую производительность, если они несколько разделены.

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

[ Router ]--->[ Queue ]--->[ Router ] 
^ ^^     | | | 
| | |     V V V 
[A] [B] [C]     [D] [E] [F] 

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

 ,----->[ QueueA ]<------. 
     |      | (Note which arrows are bi-directional) 
     V      | 
[ RouterA ]--->[ QueueB ]<--->[ RouterB ] 
^ ^^     ^^^
| | |      | | | 
V V V      V V V 
[A] [B] [C]     [D] [E] [F] 

Если система обмена сообщениями еще завален, вы могли бы заменить очереди на диаграмме выше всего сообщений очереди системы.

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

Кстати, вы можете изучить архитектуру Twitter (прошлое и настоящее), потому что у них в основном миллионы почтовых ящиков, по одному для каждого клеточного автомата (он же человек).

Answer 2

Одна идея, я играл вокруг с:

Я прочитал в нескольких местах людей, использующих Zookeeper в качестве альтернативы DNS для внутренних систем. Поскольку процессы рабочего процесса моделирования уже регистрируются в ZooKeeper, для которых имитируются ячейки, я полагаю, что не должно быть слишком далеко, чтобы также регистрировать IP-адрес и порт, на которые они будут реагировать, а затем использовать ZeroMQ для настройки сообщения P2P, проходящего между ячейками. Это все еще грубый эскиз.