分片架构解决的问题

通过堆机器，提升读写性能，与存储性能

分片架构设计要点

分片规则 

选择Cardinality大的作为分片键，尽可能保证数据分布均匀

常见分片键： 基于主键（业务型数据），基于时间（流水型数据）

常见分片策略：

分片策略	实现举例	数据分布	以后扩展
基于Hash	hash(分片键)%分片数 一致性hash算法	数据分布均匀	不易扩容，扩容需要数据迁移
范围分片	例如按年分，按月，按日	数据分表可能不均匀	易扩展，扩展不需要数据迁移

路由规则

客户端如何找到数据所在分片

•  静态路由： 配置文件。特点： 简单，不能扩展再平衡，例如：Mysql分表
• 动态路由：实现复制，支持动态扩展，再平衡

动态路由方式	基本流程	特点	举例
配置中心	配置中心记录分片信息，客户端先访问配置中心， 获取分片信息之后进行读写操作	支持大规模集群，配置中心需要独立部署，需要高可用	MongoDB的Sharding模式
路由转发	所有分片都保存路由信息，客户端请求任意分片， 获取分片信息之后进行读写操作	架构简单，一般利用gossip协议，不支持大规模集群	Redis Cluster （官方推荐1000，实际建议100）

高可用

备份方式	特点	举例
独立备份	架构简单，硬件成本高，分片级别的复制	Mysql ，Redis等
相互备份	架构复杂，硬件成本低，数据块级别的复制	ElasticSearch 等

redis cluster 分析

特点

理论支持1000台，实际建议100台以内。 高性能，线性可扩展，无代理，异步复制。

架构图- 来自阿里云溪社区

分片规则

分片键

redis的key

分片方式

类似一致性Hash， 通过CRC16算法计算出来的哈希值，对16384（2^14）取模，取模之后得到的值就是对应的槽位，然后每个Redis节点都会负责处理一部分的槽位。

扩展1 一般hash算法缺点

hash（键值）%分片数量，如果有分片挂掉，分片数量会下降，整个集群会失效。

扩展2 一致性hash算法

CRC16算法计算出来的哈希值，对2^32取模

实例也分布在圆环(0-2^32)上，我们在圆环上按照顺时针的顺序找到第一个实例

实例可能分布不均匀，采用虚拟节点机制解决

路由规则

路由转发模式，一般利用gossip协议，所有分片都保存路由信息，客户端请求任意分片

集群为了分布均匀，再平衡，或，添加，删除master实例，存在重定向的情况。

重定向

场景	命令	说明
全部迁移完成的情况下	MOVED命令	1.MOVED把客户端所请求数据的最新实例地址返返回客户端 2.更新客户端缓存的哈希槽分配信息
哈希槽数据还在迁移中	ASK	1.ASK 命令把客户端所请求数据的最新实例地址返回给客户端 2.客户端需要给目标实例 发送 ASKING 命令，然后再发送操作命令 3.不更新客户端缓存的哈希槽分配信息

备份方式

独立备份

故障转移：

某一个节点认为A宕机了，那么此时是主观宕机

集群内超过半数的节点认为A挂了， 那么此时A就会被标记为客观宕机

从A节点的slave节点中选举出一个，将其切换成新的master对外提供服务