分片，Redis 数据的分布方式，分片就是将数据拆分到多个 Redis 实例，这样每个实例将只是所有键的一个子集。
1 为什么要分区？
当我们的系统开始用缓存承担大部分读压力，从而缓解db查询压力，在提升性能同时保证系统的稳定性。这时，系统整体架构如下：
在Web层和DB层间增加了缓存层，请求会首先查询缓存，只有当缓存中没有需要的数据时才会查DB。
这时，就需关注缓存命中率：
缓存命中率 = 命中缓存的请求数 / 总请求数
一般你系统核心缓存的命中率需维持在99%甚至99.9%，哪怕下降1%，系统都会遭受毁灭性打击。
算笔账，假设系统QPS 1w，每次调用会访问10次缓存或DB的数据，则当缓存命中率仅减少1%，DB每s就增加1w * 10 * 1% = 1000次请求。
一般单个MySQL节点读请求峰值QPS就1500左右，增加的这1000次请求很可能会给DB带来毁灭打击。
更不用说缓存节点故障会有多大影响了。图中单点部署的缓存节点就成了整体系统中最大隐患！
那如何解决这个问题，提升缓存可用性？
可部署多个节点，同时让这些节点互为备份。这样，当某节点故障，其备份节点可顶替它继续服务。
这就是分布式缓存的高可用方案。
就需要把数据和请求分散到多台机器，这就需要引入分布式存储。
单点缓存节点受机器内存、网卡带宽和单节点请求量限制，随着请求量和数据量的增加，不能承担更高并发，考虑将数据分片，依照分片算法将数据打散到多个不同节点，每个节点存储部分数据。
这样在某个节点故障的情况下，其他节点也可以提供服务，保证了一定的可用性。这就好比不要把鸡蛋放在同一个篮子里，这样一旦一个篮子掉在地上，摔碎了，别的篮子里还有没摔碎的鸡蛋，不至于一个不剩。
1.1 分布式存储的特性
- 增强可用性
如果数据库的某个节点出现故障，在其他节点的数据仍然可用 - 维护方便
如果数据库的某个节点出现故障，需要修复数据，只需修复该节点 - 均衡I/O
可以把不同的请求映射到各节点以平衡 I/O，改善整个系统性能 - 改善查询性能
对分区对象的查询可以仅搜索自己关心的节点，提高检索速度
分布式存储首先要解决把整个数据集按分区规则映射到多个节点的问题，即把数据集划分到多个节点，每个节点负责整体数据的一个子集：
- 分片可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。
- 分片使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。
有哪些分片方案？
假设：
- 有 4 个 Redis 实例 R0，R1，R2，R3
- 很多表示用户的键，像 user:1，user:2
有如下方案可映射键到指定 Redis 节点。
范围分区(range partitioning)
也叫顺序分区，最简单的分区方式。通过映射对象的范围到指定的 Redis 实例来完成分片。
- 假设用户从 ID 1 ~ 33 进入实例 R0，34 ~ 66 进入R1
优点
- 键值业务相关
- 可顺序访问
同一范围内的范围查询不需要跨节点，提升查询速度 - 支持批量操作
缺点
- 数据分散度易倾斜
- 需要一个映射范围到实例的表格。该表需要管理，不同类型的对象都需要一个表，所以范围分片在 Redis 中常常并不可取，因这要比其他分片可选方案低效得多。
产品
- BigTable
- HBase
- MySQL
- Oracle
2.2 哈希分区(hash partitioning)
传统分布式算法，适于任何键，不必是 object_name:<id> 形式：
- 使用一个哈希函数(例如crc32) ，将key转为一个数字，比如93024922
- 对该数据进行取模，将其转换为一个 0 到 3 之间数字，该数字即可映射到4个 节点之一。93024922 模 4 等于 2，所以键 foobar 存储到 R2
2.2.1 分类
2.2.1.1 节点取余分区
4redis节点
20 个数据
数据分布
5redis节点
数据分布
蓝色表与4个节点时是相同的槽。
可见，redis0只有20命中、redis1只有1命中、redis2只有2命中、redis3只有3命中。最终命中率是: 4/20=20%
- hash(key) % nodes
数据迁移
当添加一个节点时
- 多倍扩容
客户端分片：哈希+取余。
节点伸缩：数据节点关系变化，导致数据迁移。迁移数量和添加节点数量有关：建议翻倍扩容。
优点：实现简单
缺点：当扩容或收缩节点时，需要迁移的数据量大（虽然翻倍扩容可以相对减少迁移量）
