上部讲了缓存分级，HTTP缓存，进程内缓存，进程外缓存。这篇作为下部主要讲讲分布式缓存。毕竟互联网对高并发，可用性是有一定要求的。
要点：
分布式缓存
缓存高性能
缓存可用性
分布式缓存
分布式缓存是与应用分离的缓存服务，最大的特点是自身是一个独立的应用/服务，与本地应用隔离，多个应用可直接共享一个或者多个缓存应用/服务
既然是分布式缓存，缓存的数据会分布到不同的缓存节点上，每个缓存节点缓存的数据大小通常也是有限制的。数据被缓存到不同的节点，为了能方便的访问这些节点，需要引入缓存代理，类似twemproxy。他会帮助请求找到对应的缓存节点。同时如果缓存节点增加了，这个代理也会只能识别并且把新的缓存数据分片到新的节点，做横向的扩展。为了提高缓存的可用性，会在原有的缓存节点上加入Master/Slave的设计。当缓存数据写入Master 节点的时候，会同时同步一份到Slave节点。一旦Master节点失效，可以通过代理直接切换到Slave 节点，这时Slave 节点就变成了Master节点，保证缓存的正常工作。每个缓存节点还会提供缓存过期的机制，并且会把缓存内容定期以快照的方式保存到文件上，方便缓存崩溃之后启动预热加载。
高性能
数据分片
当缓存做成分布式的时候，数据会根据一定的规律分配到每个缓存应用/服务上。如果我们把这些缓存应用/服务叫做缓存节点，每个节点一般都可以缓存一定容量的数据，例如：Redis一个节点可以缓存2G的数据。如果需要缓存的数据量比较大就需要扩展多个缓存节点来实现，这么多的缓存节点，客户端的请求不知道访问哪个节点怎么办？缓存的数据又如何放到这些节点上？缓存代理服务已经帮我们解决这些问题了，例如：twemproxy 不但可以帮助缓存路由，同时可以管理缓存节点。这里有介绍三种缓存数据分片的算法，有了这些算法缓存代理就可以方便的找到分片的数据了。
哈希算法：
Hash表是最常见的数据结构，实现方式是，对数据记录的关键值进行Hash，然后再对需要分片的缓存节点个数进行取模得到的余数进行数据分配。
例如：有三条记录数据分别是 R1，R2，R3。 他们的ID分别是01，02，03，假设对这个三个记录的ID作为关键之进行Hash 算法之后的结果依旧是 01，02，03。我们想把这三条数据放到三个缓存节点中，可以把这个结果分别对3这个数字取模的余数，这个余数就是这三条记录分别放置的缓存节点。
Hash算法是某种程度上的平均放置，策略比较简单，如果要增加缓存节点，对已经存在的数据会有较大的变动。
一致性哈希算法：
一致性Hash是将数据按照特征值映射到一个首尾相接的Hash环上，同时也将缓存节点映射到这个环上。如果要缓存数据，通过数据的关键值（Key）在环上找到自己存放的位置。这些数据按照自身的ID 取Hash 之后得到的值按照顺序在环上排列。
如果这个时候要插入一条新的数据其ID是 115，那么就应该插入到如下图的位置。
同理如果要增加一个缓存节点N4 150，也可以放到如下图的位置。
这种算法对于增加缓存数据，和缓存节点的开销相对比较小。
Range Based 算法
这种方式是按照关键值（例如ID）将数据划分成不同的区间，每个缓存节点负责一个或者多个区间。跟一致性哈希有点像。
例如：存在三个缓存节点分别是N1，N2，N3。 他们用来存放数据的区间分别是，N1(0, 100]， N2(100, 200]， N3(300, 400]。那么数据根据自己ID 作为关键字做Hash 以后的结果就会分别对应放到这几个区域里面了。
可用性
缓存雪崩
当缓存失效，缓存过期被清除，缓存更新的时候。请求是无法命中缓存的，这个时候请求会直接回源到数据库。如果上述情况频繁发生或者同时发生的时候，就会造成大面积的请求直接到数据库，造成数据库访问瓶颈。我们称这种情况为缓存雪崩。
从两方面来思考解决方案：
缓存方面
- 避免缓存同时失效，不同的key设置不同的超时时间
- 增加互斥锁，对缓存的更新操作进行加锁保护，保证只有一个线程进行缓存更新。缓存一旦失效可以通过缓存快照的方式迅速重建缓存。
- 对缓存节点增加主备机制，当主缓存失效以后切换到备用缓存继续工作。
设计方面
- 熔断机制：某个缓存节点不能工作的时候，需要通知缓存代理不要把请求路由到该节点，减少用户等待和请求时长。
- 限流机制：在接入层和代理层可以做限流（之前的文章讲到过），当缓存服务无法支持高并发的时候，前端可以把无法响应的请求放入到队列或者丢弃。
- 隔离机制：缓存无法提供服务或者正在预热重建的时候，把该请求放入队列中，这样该请求因为被隔离就不会被路由到其他的缓存节点。如此就不会因为这个节点的问题影响到其他节点。当缓存重建以后，再从队列中取出请求依次处理。
缓存穿透
缓存一般是Key，Value方式存在，一个Key对应的Value不存在时请求会回源到数据库，假如对应的Value一直不存在，则会频繁的请求数据库，对数据库造成访问压力。如果有人利用这个漏洞攻击，就麻烦了。
解决方法：
- 如果一个Key对应的Value查询返回为空，我们仍然把这个空结果缓存起来，如果这个值没有变化下次查询就不会请求数据库了。
- 将所有可能存在的数据哈希到一个足够大的bitmap中，那么不存在的数据会被这个bitmap过滤器拦截掉，避免对数据库的查询压力。
缓存击穿
在数据请求的时候某一个缓存刚好失效或者正在写入缓存，同时这个缓存数据可能会在这个时间点被超高并发请求，成为“热点”数据。这就是缓存击穿问题，这个和缓存雪崩的区别在于这里是只针对某一缓存缓存，前者是针对多个缓存。
解决方案：
导致问题的原因是在同一时间读/写缓存，所以只有保证同一时间只有一个线程写，写完成以后，其他的请求再使用缓存就可以了。
比较常用的做法是使用mutex（互斥锁）。在缓存失效的时候，不是立即写入缓存，而是先设置一个mutex（互斥锁）。当缓存被写入完成以后，再放开这个锁让请求进行访问。
总结：
从分布式缓存的结构入题，从高性能和可用性介绍了缓存的原理。高性能是我们使用缓存的目的，通过数据分片的方式把更多的内容放入缓存，通过代理的方式路由和管理缓存节点。可用性需要注意，缓存雪崩，缓存穿透，缓存击穿几种情况以及应对的方法。
