一个允许高效广播通信的gearman工作进程
项目描述
齿轮鼓
一个允许高效广播通信的gearman工作进程
扇出工作进程
Gearman没有内置的将工作复制到多个工作进程的方法。此工作进程将执行此操作，以支持称为“扇出”的常用消息模式
运行后，扇出工作进程将订阅“register_fanout_subscriber”和“fanout”队列。
subscribe_fanout unsubscribe_fanout
这些队列将包含一个JSON有效负载，其中包含一个包含两个键的映射：topic, client_id。client_id将作为topic下的集合保留，用于向适当的订阅者队列发送消息。它应为每个预期收件人队列在每个扇出请求中是唯一的。通常这将是每个主机的唯一值。
fanout
此队列将包含一个包含两个键的映射的JSON有效负载：topic, payload。topic将用于搜索订阅者ID列表。对于找到的每个subscriber_id，将向名为topic_subscriber_id的队列发送有效负载的副本。因此，如果我们有两个订阅了“officememos”的订阅者，其ID分别为“bob”和“alice”，则向fanout发送此有效负载的消息
{"topic": "officememos",
"payload": "please go home early today."}
可选地，可以添加一个‘unique’键来利用Gearman的唯一/合并功能。还可以使用‘background’键设置一个真值，这将告诉gearhorn在移动到更多消息之前不要等待接收者。
会导致工作器向队列“officememos_bob”和“officememos_alice”发送负载副本。
匹配
为了将主题与订阅者匹配，工作器必须共享每个主题的订阅者列表。映射存储在后端数据存储中。任何时间出现新的注册事件，该存储中的列表都会更新，并向__matchmaking主题发送消息。工作器自动将自己添加到/从__matchmaking列表中，以确保在规范列表更新时能够收到通知并清除缓存。失败猛烈的工作器必须手动删除。
失败的想法
以下想法是第1号，它并没有比仅仅运行Redis作为pub/sub和直接通信后端更有效率。它保留在这里，作为不要重新实现Redis的提醒。
使用它的预期方式是有一个希望接收广播请求的gearman客户端，使用唯一的ID请求给定的广播函数，该ID是最后看到的序列ID。当这个守护程序收到这项工作时，它会查找任何序列号大于此ID的项目，如果找到了，就回复一个json负载的
{"sequence": 2,
"payload": "foobarbaz"}
客户端将消费此内容，然后提交一个带有new_seq的新作业。这使得同步作业流成为广播负载流，客户端有很好的机会接收到所有序列。
待办事项
真正的功能测试
使所有东西可配置
工作队列名称
调整回调和刷新频率
考虑一个工作队列，工作器可以使用它来共享他们当前应该使用的序列。
这会太竞争吗？或者鉴于“尽力而为”，仅仅努力尝试就足够了吗？
我们需要某种类型的UUID，以便允许客户端检测到所有工作器都消失了，序列重置为0吗？
添加一个客户端辅助模块，该模块实现序列获取，以便更容易编写Python消费者
gearhorn-0.0.5.tar.gz的散列
| 算法 | 散列摘要 | |
|---|---|---|
| SHA256 | 227a13d19210bd9079ab819cf7db4de472c749d9e8188d10169e2d8a90f4bada |
|
| MD5 | 8b79334a06215df069aaf8d577f545a4 |
|
| BLAKE2b-256 | 8c996c3bb4b7045d51b41bfe423e4e72783b037d674ccd9ba472a48d21eb9581 |
