我正在使用twisted从与Internet连接的传感器获取消息,以便将其存储到数据库.我想检查这些消息而不会干扰这些过程,因为我需要将每条消息与db的一些基本值进行比较,如果某些匹配,我需要为此触发一个警报,并且这个想法不会阻止任何过程…

我的想法是创建一个新的流程进行检查和警报,但是在第一个流程存储完消息后,我需要将其发送到新流程,以便检查和警报是否需要.
我为此需要IPC,我当时正在考虑使用ZeroMQ,但也有一种扭曲的方法可以与IPC一起工作,我想如果我使用ZeroMQ,但这也许会成为自败之举…

您如何看待我的方法？也许我完全错了？

任何建议都欢迎.
谢谢
PD：此过程将在专用服务器上运行,预期负载为6000 msg /小时,每台1Kb

解决方法:

所有这些方法都是可能的.我只能抽象地发言,因为我不知道您的应用程序的确切轮廓.

如果您已经有一个可以运行的应用程序,但是它的速度还不够快,无法处理您向它抛出的消息数量,那么请确定瓶颈.造成延迟的两个可能原因是数据库访问或警报触发,因为其中之一可能是同步IO操作.

如何处理取决于您的工作量：

>如果您的消息速率很高且恒定,那么您需要确保数据库可以处理该速率.如果您的数据库无法处理,那么无阻塞的消息传递将无济于事！按此顺序：

>尝试调整数据库.
>尝试将数据库放在更大的组件上,并增加内存.
>尝试在多台计算机上共享数据库以分配工作负载.
一旦知道您的数据库可以处理消息速率,就可以使用其他形式的并行性处理其他瓶颈.

>如果您的消息速率是突发性的,那么您可以使用排队来处理突发.按此顺序：

>将负载均衡器放在消息处理器集群的前面.该平衡器应该做的就是将传感器消息重新分配给不同的机器,以进行检查和警报处理.这种方法的优点是您可能不需要更改现有应用程序,只需在更多计算机上运行它即可.如果您的负载均衡器不需要等待响应,而只是转发消息,则效果最好.
>如果您的通信需求更加复杂或是双向的,则可以使用消息总线(例如ZeroMQ)作为消息处理器,警报发件人和数据库检查器之间的通信层.这个想法是通过使非阻塞通信通过总线发生并使总线上的每个节点仅做一件事情来增加并行度.然后,可以根据消息处理每个阶段花费的时间来更改节点类型的比率. (即,在整个消息处理过程中使队列深度相等.)