分片架构的本质：

分片架构能提升写性能和存储性能，对应的主备架构的本质是备份，主从架构本质提升读性能。

 分片架构的两个关键点：分片规则跟路由规则

分片规则：

选择基数比较大的某个数据键值，让数据均匀分布，避免热点切片 

1. 基数Cardinality。被选的数据维度取值范围
2. 均匀。数据在取值范围内是均匀分布的

分片数据
主键 ：适合主业务数据，例如数据库分片常用的用户ID、订单ID，Redis分片的key，MongoDB的文档ID

这里是原则，具体落地得验证，比如订单ID之前遇到老的雪花算法，偶数偏多，数据不均匀，该怎么处理？
时间：适合流水型业务，例如创建日期、IoT事件、动态
分片规则
Hash分片  

 1. sharding key=hash(原始键值)分布均匀，但是不支持范围查询
2. 扩容服务器麻烦，需要做数据迁移
范围分片    

1. 分布可能不均匀，支持范围查询
2. 方便扩容新服务，无需迁移历史数据

路由规则：

业务服务器如何找到数据

配置中心 

1. 由专属的配置中心记录分片信息，客户端需要向配置中心查询分片信息，然后发起读写操作
2. 可以支持超大规模集群，节点数量可以达到几百上千
3. 架构复杂，一般要求独立的配置中心节点，配置中心本身又需要高可用，例如MongoDB用的是replica set，HDFS用的是ZooKeeper

路由转发

   

1. 每个节点都保存所有路由信息，客户端请求任意节点皆可
2. 架构相对简单一些，一般通过gossip协议来实现分片信息更新
3. 无法支持超大规模集群，建议集群数量在100以内（李老师建议50以内）。

分片高可用方案1：独立备份

存储系统已经支持节点级别的复制，redis,mangodb，mysql

分片高可用方案2：互相备份

案例  ：HDFS、ES

二分区架构

分区 是按地区分，通过冗余IDC来避免城市级别的灾难，并提供就近访问

DNS：标准协议，通用，但基本只能实现就近接入的路由

GSLB：非标准，需要独立开发部署，功能非常强大，可以做状态监测、基于业务规则的定制路由。这个没看过，不太熟悉，从效果上基于地理位置的流量负载多数据中心外，还具备检测状态。

分区备份策略：集中式  

1. 设计简单，各分区之间并无直接联系，可以做到互不影响
2. 扩展容易，如果要增加第四个分区（例如：西安分区），只需要将西安分区的数据复制到武汉备份中心即可，其他分区不受影响
3. 成本较高，需要建设一个独立的备份中心

互备式

 优点：成本低，直接利用已有机房和网络

 缺点：扩展复杂

独立式

 设计简单，各分区互补影响。

扩展容易，新增加的分区只需要搭建自己的备份中心即可

缺点：成本高，每个分区需要独立的备份中心。