深入理解Redis系列——发布与订阅详解

根据场景去理解https://www.cnblogs.com/goodAndyxublog/p/13716071.html

假设我们有这么一个业务场景，在网站下单支付以后，需要通知库存服务进行发货处理。

上面业务实现不难，我们只要让库存服务提供给相关的给口，下单支付之后只要调用库存服务即可。

后面如果又有新的业务，比如说积分服务，他需要获取下单支付的结果，然后增加用户的积分。

这个实现也不难，让积分服务同样提供一个接口，下单支付之后只要调用库存服务即可。

如果就两个业务需要获取下单支付的结果，那也还好，程序改造也快。可是随着业务不断的发展，越来越多的新业务说是要下单支付的结果。

这时我们会发现上面这样的系统架构存在很多问题：

第一，下单支付业务与其他业务重度耦合，每当有个新业务需要支付结果，就需要改动下单支付的业务。

第二，如果调用业务过多，会导致下单支付接口响应时间变长。另外，如果有任一下游接口响应变慢，就会同步导致下单支付接口响应也变长。

第三，如果任一下游接口失败，可能导致数据不一致的情况。比如说下图，先调用 A，成功之后再调用 B，最后再调用 C。

如果在调用 B 接口的发生异常，此时可能就导致下单支付接口返回失败，但是此时 A 接口其实已经调用成功，这就代表它内部已经处理下单支付成功的结果。

这样就会导致 A，B，C 三个下游接口，A 获取成功获取支付结果，但是 B，C 没有拿到，导致三者系统数据不一致的情况。

其实我们仔细想一下，对于下单支付业务来讲，它其实不需要关心下游调用结果，只要有某种机制通知能通知到他们就可以了。

讲到这里，这就需要引入今天需要介绍发布订阅机制。

Redis 提供了基于「发布/订阅」模式的消息机制，在这种模式下，消息发布者与订阅者不需要进行直接通信。