李新仁
笔者做过公司多个项目的微服务架构和改造，就微服务的缓存设计这个问题来发表一下自己的看法。
从3个层面来回答这个问题：
为什么用缓存？
什么场景下使用缓存？
基于缓存的架构设计点
1.为什么用缓存
在高并发场景下，如果直接读DB，很容易出现性能瓶颈，因此需要通过缓存来减少DB的压力，使得大量的访问进来能够命中缓存，只有少量的需要读DB。缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计必不可少。
2.什么场景下使用缓存
我们都知道缓存可以提升系统响应速度，那么一般哪些场景下需要用到缓存呢？我们可以列举3个场景：
2.1 计数缓存
计数对于数据库来讲，是非常繁重的任务，需要查询大量的数据，最后得出计数结果，当数据改变的时候，需要重新刷一遍，非常影响性能。
因此可以设计一个计数服务，后端对接缓存，将计数作为结果放在缓存里面，当数据改变时，调用计数服务增加或者减少计数。计数服务可以使用Redis进行单个计数，也可以用hash表进行批量计数。
微服务中的使用场景为网关中的流量控制、配额控制等计数服务。
2.2 频繁读+低频写
比如一个网上商城，商品品类信息的更新品类相对而言是比较低的，但是几乎所有商品相关的查询服务都需要读取商品的品类信息。像这种低频写、高频读的数据，比较适合放到缓存中，来提升服务性能。
2.3 较大内容的高频读数据
这个和2.2的主要区别是防止在缓存中的量级。比如物联网场景中的白名单信息。接入物联网的设备量级一般比较大，可以到万、千万甚至上亿级别。对于这些设备的白名单控制不可能每次都读取DB来做权限验证。因此需要设计针对大量数据的分布式缓存来提升服务性能。
3.基于缓存的架构设计点
基于缓存的架构设计点可以从2个方面来考虑：
3.1 分场景
要区分缓存的实际应用场景，来进行不同的缓存技术选型。对于微服务网关中的流量控制所用到的分布式缓存，可以使用redis+本地缓存技术的方案。对于商品分类信息的存放，使用本地缓存就可以满足需求。对于大型文件的缓存，则推荐本地文件+本地缓存的方式，配合版本管理实现。
3.2 缓存架构的高可用
引入缓存是为了解决性能瓶颈，但是实质上是引入了更多依赖。比如使用redis，如果没有足够的容错机制，redis一旦挂了，则会导致服务不可用。
可以使用分片，这样每一个缓存实例都不大，但是实例数目比较多，一方面可以实现负载均衡，防止单个实例称为瓶颈或者热点，另一方面如果一个实例挂了，影响面相对会小很多，高可用性大大增强。分片机制可以在客户端实现，可以使用中间件实现，也可以使用Redis的Cluster的方式，分片的算法往往都是哈希取模，或者一致性哈希。
