分布式缓存分片的三种模式

在互联网行业里，我们做的都是用户端的产品，有调查称中国有6亿互联网用户，这么多的用户会给互联网应用带来了海量的请求，这也需要存储海量的数据，因此，单机的缓存满足不了对海量数据缓存的需求。我们通常通过多个缓存节点来缓存大量的临时数据，来加速缓存的存取速度，例如，可以把微博的粉丝关系存储在缓存中，在获取某个用户有权限看见的微博时，我们就可以使用这些粉丝关系，粉丝关系的数据量非常大，一个大V用户可能有几千万或者上亿的关注量，可想而知，我们需要多大的内存才能够存储这么多的粉丝关系。

在通用的解决方案中，我们会对这些大数据量进行切片，数据被分成大小相等的分片，一个缓存节点负责存储其中的多个分片。分片通常有三种实现方式，包括客户端分片、代理分片和集群分片。

客户端分片

对缓存进行客户端分片的方案如图所示：

客户端分片通过应用层直接操作分片逻辑，分片规则需要在同一个应用的多个节点间保存，每个应用层都嵌入一个操作切片的逻辑实现，一般通过依赖Jar包来实现。笔者曾工作过的几家大的互联网公司都有内部的缓存分片的实现，多数是采用在应用层直接实现的方式，应用层分片的性能更好，实现简单，有问题时容易定位和修复，4.6 节介绍的开源项目redic（https://gitee.com/robertleepeak/redic）也是采用这种方案实现的。

这种解决方案的性能很好，实现起来比较简单，适合快速上线，而且切分逻辑是自己开发的，如果在生产上出了问题，则都比较容易解决；但是它侵入了业务逻辑的实现，会让缓存服务器保持的应用程序连接比较多，这要看应用服务器池的节点数量，需要提前进行容量评估，请参考《分布式服务架构：原理、设计与实战》第3章的内容。

代理分片

对缓存进行代理分片的方案如图所示：

代理分片就是在应用层和缓存服务器中间增加一个代理层，把分片的路由规则配置在代理层，代理层对外提供与缓存服务器兼容的接口给应用层，应用层的开发人员不用关心分片规则，只需关心业务逻辑的实现，待业务逻辑实现以后，在代理层配置路由规则即可。

这种方案的好处是让应用层开发人员专注于业务逻辑的实现，把缓存分片的配置留给代理层做，具体可以由运维人员来实施；缺点是增加了代理层。尽管代理层是轻量级的转发协议，但是毕竟要实现缓存协议的解析，并通过分片的路由规则来路由请求，对每个缓存操作都增加了一层代理网络传输，对性能是有影响的，对增加的代理层也需要进行维护，也有硬件成本，还要有能够解决Bug的技术专家，成本很高。

流行的Codis框架就是代理分片的典型实现。

集群分片

缓存自身提供的集群分片方案如图所示：

有的缓存自身提供了集群功能，集群可以实现分片和高可用特性，我们只需要把它们当成一个由多个缓存服务器节点组成的大缓存机器来使用即可，分片和高可用等对应用层是透明的，由运维人员配置即可使用，典型的就是Redis 3.0提供的Cluster。我们已经在4.3.2节介绍了Redis集群。

END

【推荐书籍】

      扫码购买