最近项目中，有个功能点是利用redis的发布订阅机制，进行服务器本地缓存数据同步。
由于redis发布订阅功能的可靠性较差，在项目中出现了有服务器没有订阅成功问题，以及服务器订阅消息不及时，导致部分业务受到影响。所以将redis通知本地缓存的机制改为了使用redis做二级缓存。
虽然Redis能够实现发布/订阅的功能,但是有如下缺点,所以选用前需谨慎考虑
1.消息无法持久化，存在丢失风险
和常规的MQ不同,redis实现的发布/订阅模型消息无法持久化,一经发布,即使没有任何订阅方处理,该条消息就会丢失
2.没有类似ACK的机制
即发布方不会确保订阅方成功接收
3.广播机制，下游消费能力取决于消费方本身
广播机制无法通过添加多个消费方增强消费能力,因为这和发布/订阅模型本身的目的是不符的.广播机制的目的是一个一个发布者被多个订阅进行不同的处理
Redis发布/订阅应用场景
由于Redis发布/订阅模型存在的缺陷,所以使用前需要考虑如下几点
1.对于消息处理可靠性要求不强
2.消费能力无需通过增加消费方进行增强
————————————————
原文链接：https://blog.csdn.net/weixin_32394085/article/details/105006123
