应用场景

如何进行选择的

Redis的发布订阅模式对于WebServer和Mqtt的优点

1. 解耦性更强。使用发布订阅模式,发布者和订阅者之间没有直接的联系,增加了系统的松耦合性。
2. 性能更好。Redis作为中间件支持高性能的发布订阅功能,而不像Web服务器需要建立请求-响应连接,性能更高。
   1. 虽然到后面实际运用并不需要高性能高并发
3. 实时性更强。Redis发布订阅模式支持**同步实时通知,**消息从发布端立即传达给订阅端,相比Web请求的延迟更小。
4. 可靠性更高。Redis内部实现机制可以保证消息的可靠性传递,而Web服务器中间可能有失败没有返回结果的情况。
   1. 也是基于TCP连接的
5. 成本更低。Redis本身性能强大,部署复杂度低,相比使用完整Web服务器或者mqtt服务成本更低。
   1. 成本更低，更加轻量，MQTT太过于笨重
6. 管理简单。使用Redis一个中间件就可以连接不同设备,而不需要部署和管理额外的协议栈或者消息中间件。
   1. 发布订阅类似于广播，只需一个设备就可以给多台设备发信息
7. 扩展性好。Redis不仅支持点对点通信,还支持群发模式,更易于大规模设备扩展。

为什么不用WebServer

• 请求响应模型不适合实时通信:WebServer采用请求-响应的传统模型,设备间通信需要建立连接并发起请求,响应时间较长,不适合实时性要求较高的通信场景。
• 单点通信不利于扩展:WebServer和MQTT协议本身都是点对点通信,一台设备如果需要连接多台设备,**需要分别建立和维护多个连接,**不易于大规模扩展。
  • 不轻量，太过于笨重，且多了很多其他的操作
• 性能瓶颈:WebServer在传统架构下处理能力有限,随着连接和设备数量增加容易成为系统性能的瓶颈。MQTTbroker的单点架构同样面临此问题。
  • 由于业务是面向于多台设备的，所以WebServer，MQTT会随着设备的增加而到达瓶颈，由于是单点架构
• 连接管理复杂:在WebServer和MQTT中,设备之间的连接需要自己维护,如建立连接、断开连接等都需要程序控制,增加了开发和管理难度。
  • 管理复杂，不像Redis只需要一个设备进行发布即可，不需要部署和管理额外的协议栈或者消息中间件。
• 错误处理不便:点对点通信模型下,如果消息传输或设备响应失败,需要自定义重试和错误处理机制,开发和调试难度较大。
  • （可靠性不高，同样是采用HTTP，也是基于TCP），但是信息发送失败， 你需要自定义的重试以及错误处理机制，麻烦
• 消息路由依赖关系紧:点对点交互对消息的发送与接收端产生强依赖,不便于实现设备解耦和路由灵活配置。
  • 同样是点对点，交互需要对发送和接收端产生依赖，不便于实现解耦
• 不支持过滤订阅:WebServer和MQTT原生不支持订阅指定topic下的部分消息,订阅范围较单一
  • 对于Redis的发布订阅模式，类似的MQTT其实也有topic进行发布订阅，但是都是依赖于一个中继Broker进行通信，对他的性能会直接影响通信延迟和吞吐量等
  • 要是broker崩溃失败了，所有通过他 的客户端都无法通信
  • 占用量大

为什么不用MQTT

• 对于少量设备和低频率通信任务,这类场景MQTT可能相对过于笨重。