使用IPC的架构方案,Twisted还是ZeroMQ?
我正在使用Twisted这个工具,从连接到互联网的传感器获取消息,然后把这些消息存储到数据库里。
我想检查这些消息,但又不想干扰这个过程,因为我需要把每条消息和数据库里的某些基准值进行比较,如果有匹配的,我就需要发出警报,而我的想法是不要阻塞任何进程……
我的想法是创建一个新的进程来进行检查和报警,但我需要在第一个进程存储消息后,把消息发送给新进程,以便在需要时进行检查和报警。
为此,我需要进程间通信(IPC),我在考虑使用ZeroMQ,但Twisted也有处理IPC的方法。我觉得如果我使用ZeroMQ,可能会适得其反……
你觉得我的想法怎么样?也许我完全错了?
任何建议都欢迎……谢谢!
附注:这个过程将在一台专用服务器上运行,预计每小时处理6000条每条1Kb的消息。
2 个回答
1
当你收到一条消息时,做两件事:
- 检查一下这条消息是否需要发出警报(如果需要的话,就发出警报)
- 把这条消息存入数据库
你不需要消息队列、多个进程、进程间通信或者其他那些复杂的东西。比如:
def messageReceived(self, message):
self.checkForAlerts(message).addCallbacks(self.maybeAlert, log.err)
self.saveMessageToDatabase(message).addErrback(log.err)
3
这些方法都是可行的。我只能大概说说,因为我不知道你应用的具体情况。
如果你已经有一个能运行的应用,但处理消息的速度不够快,无法应对你发送的消息数量,那么你需要找出瓶颈。造成这个问题的两个主要原因可能是数据库访问或者触发警报,因为这两者通常都是同步的输入输出操作。
你如何解决这个问题取决于你的工作负载:
- 如果你的消息发送速度很高且稳定,那么你需要确保你的数据库能够处理这个速度。如果数据库处理不了,那再怎么使用非阻塞的消息传递也没用!你可以按以下顺序进行:
- 尝试优化你的数据库。
- 尝试把数据库放在更强大的机器上,增加内存。
- 尝试将数据库分布到多台机器上,以分担工作负载。一旦你确认数据库能处理消息速度,就可以通过其他形式的并行处理来解决其他瓶颈。
- 如果你的消息发送速度是突发性的,那么你可以使用队列来处理这些突发情况。可以按以下顺序进行:
- 在一组消息处理器前面放一个负载均衡器。这个负载均衡器的作用就是把传感器消息重新分配到不同的机器上进行检查和警报处理。这样做的好处是,你可能不需要改变现有的应用,只需在更多的机器上运行它。如果负载均衡器不需要等待响应,只需转发消息,这样效果最好。
- 如果你的通信需求更复杂或者是双向的,可以使用消息总线(比如ZeroMQ)作为消息处理器、警报发送者和数据库检查者之间的通信层。这个想法是通过总线进行非阻塞通信来增加并行性,并让总线上的每个节点只做一件事。然后你可以根据每个消息处理阶段所需的时间调整节点类型的比例。(也就是说,让整个消息处理过程中的队列深度保持一致。)