pipeline与multi区别

从上面分别对pipeline与multi的介绍，可以看出两者在定位与功能分工上的差异点：

• pipeline是客户端行为，只是负责将客户端的多个请求一次性打包传递到服务器端，服务端依旧是按照和单条请求一样的处理，批量传递到服务端的请求之间可能会插入别的客户端的请求操作，所以它是无法保证原子性的，侧重点在于其可以提升客户端的效率（降低频繁的网络交互损耗）

• multi是服务端行为，通过开启事务缓存，保证客户端在事务期间提交的请求可以被一起集中执行。它的侧重点是保证多条请求的原子性，执行期间不会被插入其余客户端的请求，但是由于开启事务以及命令缓存等额外的操作，其对性能略微有一些影响。

多级缓存机制

本地+远端的二级缓存机制

在涉及与集中式缓存之间频繁交互的时候，通过前面介绍的pipeline方式可以适当的降低与服务端之间网络交互的频次，但是很多情况下，依旧会产生大量的网络交互，对于一些追求极致性能的系统而言，可能依旧无法满足诉求。

回想下此前文章中花费大量篇幅介绍的本地缓存，本地缓存在分布式场景下容易造成数据不一致的问题，但是其最大特点就是快，因为数据都存储在进程内。所以可以将本地缓存作为集中式缓存的一个补充策略，对于一些需要高频读取且不会经常变更的数据，缓存到本地进行使用。

常见的本地+远端二级缓存有两种存在形式。

• 独立划分，各司其职

这种情况，将缓存数据分为了2种类型，一种是不常变更的数据，比如系统配置信息等，这种数据直接系统启动的时候从DB中加载并缓存到进程内存中，然后业务运行过程中需要使用时候直接从内存读取。而对于其他可能会经常变更的业务层面的数据，则缓存到Redis中。

• 混合存储，多级缓存

这种情况可以搭配Caffeine或者Ehcache等本地缓存框架一起实现。首先去本地缓存中执行查询，如果查询到则返回，查询不到则去Redis中尝试获取。如果Redis中也获取不到，则可以考虑去DB中进行回源兜底操作，然后将回源的结果存储到Redis以及本地缓存中。这种情况下需要注意下如果数据发生变更的时候，需要删除本地缓存，以确保下一次请求的时候，可以再次去Redis拉取最新的数据。

本地+远端的二级缓存机制有着多方面的优点：

• 主要操作都在本地进行，可以充分的享受到本地缓存的速度优势；

• 大部分操作都在本地进行，充分降低了客户端与远端集中式缓存服务器之间的IO交互，也降低了带宽占用；

• 通过本地缓存层，抵挡了大部分的业务请求，对集中式缓存服务器端进行减压，大大降低服务端的压力；

• 提升了业务的可靠性，本地缓存实际上也是一种额外的副本备份，极端情况下，及时集中式缓存的服务端宕机，因为本地还有缓存数据，所以业务节点依旧可以对外提供正常服务。

二级缓存的应用身影

其实，在C-S架构的系统里面，多级缓存的概念使用的也非常的频繁。经常Clinet端会缓存运行时需要的业务数据，然后采用定期更新或者事件触发的方式从服务端更新本地的数据。而Server端负责存储所有的数据，并保证数据更新的时候可以提供给客户端进行更新获取。

一个典型的例子，就是分布式系统中的配置中心或者是服务注册管理中心。比如SpringCloud家族的Eureka，或者是Alibaba开源的Nacos。它们都有采用客户端本地缓存+服务端数据统一存储的方式，来保证整体的处理效率，降低客户端对于Server端的实时交互依赖。

看一下Nacos的交互示意：

从图中可以表直观的看到，Client将业务数据缓存到各自本地，这样业务逻辑进行处理的时候就可以直接从本地缓存中查询到相关的业务节点映射信息，而Server端只需要负责在数据有变更的事后推送到Client端更新到本地缓存中即可，避免了Server端去承载业务请求的流量压力。整体的可靠性也得到了保证，避免了Server端异常对业务正常处理造成影响。

小结回顾

好啦，到这里呢，《深入理解缓存原理与实战设计》系列专栏的内容就暂告一段落咯。本专栏围绕缓存这个宏大命题进行展开阐述，从缓存各种核心要素、到本地缓存的规范与标准介绍，从手写本地缓存框架、到各种优秀本地缓存框架的上手与剖析，从本地缓存到集中式缓存再到最后的多级缓存的构建，一步步全方位、系统性地做了介绍。希望通过本专栏的介绍，可以让大家对缓存有个更加深刻的理解，可以更好的在项目中去使用缓存，让缓存真正的成为我们项目中性能提升的神兵利器。

看到这里，不知道各位小伙伴们对缓存的理解与使用，是否有了新的认识了呢？你觉得缓存还有哪些好的使用场景呢？欢迎评论区一起交流下，期待和各位小伙伴们一起切磋、共同成长。

我是悟道，聊技术、又不仅仅聊技术~

如果觉得有用，请点赞 + 关注让我感受到您的支持。也可以关注下我的公众号【架构悟道】，获取更及时的更新。

期待与你一起探讨，一起成长为更好的自己。