10.1 概念

在本文档中，高可用主要指的是解决尽可能在不丢失数据的前提下不间断服务问题，由于redis是异步复制，因此不保证数据完全不丢失，在这个场景下并不实现动态横向扩容，只能进行纵向扩容，你只要加内存，启动redis，设置maxmemory即可。而分片（Sharding）主要指的是解决在线动态横向扩容缩容问题，当然为了稳定也进行高可用部署配置，即包含成对的主从关系。

10.2 高可用主要场景和对应思路

适用于redis非重度用户，内存占用不大，总体内存大小的增长趋势可预估，有一定停机时间的系统——纵向扩容即可满足，可以对全库进行主从复制即满足需求而不需要做分片，一般针对单个小型项目的cache 等场景。一般采用一主多从的sentinel方案进行部署。

10.3 分片主要场景和对应思路

分片是为了应对业务增长带来的数据增长，需要对动态横向扩容有一定要求时采用。对于一般的分片采用一致性哈希，它极大的优化机器增删时带来的哈希目标漂移问题。同时对于Hash目标漂移时产生的严重的数据倾斜，可以利用虚拟节点来优化。基本上，物理节点有了一定规模后，只要不是同时挂多个节点，或者同时扩容多个节点，数据分片不会有太大的扰动。穿透过Cache的请求后端存储可以抗住即可。

稍微复杂的方案是可以使用“预分片（Pre-Sharding)”的方案，也称为按“桶”进行数据划分，即分配一个相当大的集合，对Key哈希的结果落在这个集合中，集合的每个元素又与具体的物理节点存在多对一的路由映射关系，这张路由表由一个配置中心进行维护。其实，一致性哈希中的虚拟节点，实际上也可以归类到Pre-Sharding方案中。换句话说，只要是key经过两次哈希，第一次Hash到虚拟节点，第二次Hash到物理节点，都可以算作Pre-Sharding。只不过区别在于，一致性哈希的第二次Hash其路由表是按照算法固定的，而分桶的第二次Hash其路由表是第三方可配的。

10.4 适用场景对比列表

---	动态扩容能力	系统复杂度	开发复杂度	运维复杂度
主从复制+Sentinel	No	简单	简单	简单
Twemproxy	No	简单	简单	稍微复杂
3.0 Cluster	Yes	简单	简单	复杂
Codis	Yes	复杂	简单	复杂
应用层面presharding	Yes	复杂	复杂	视开发的水平而定

本文为《Redis开发运维实践指南》内容，该书作者为黄鹏程，已授权云栖社区转载。