分片架构的本质

1. 只有主机承担写，写性能会存在瓶颈；

2. 每台机器保存全量数据，存储存在瓶颈。

本质：

通过叠加更多服务器来提升写性能和存储性能。

分片架构设计核心

1. 分片规则：数据按照什么规则分片；

2. 路由规则：业务服务器如何找到数据。

分片架构设计核心 - 分片规则

核心原则：

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

【基数 Cardinality】

被选的数据维度取值范围。

【均匀】

数据在取值范围内是均匀分布的。

分片数据：

【主键】

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

【时间】

适合流水型业务，例如创建日期，IoT 事件，动态。

分片架构设计核心 - 路由规则

分片动态路由 - 配置中心

1. 由专属的配置中心记录分片信息，客户端需要向配置中心查询分片信息，然后发起读写操作。

2. 可以支持超大规模集群，节点数量可以达到几百上千。

3. 架构复杂，一般要求独立的配置中心节点，配置中心本身又需要高可用，例如 MogoDB 用的是 replica set，HDFS 用的是ZooKeeper（注意：HDFS 2.0 版本以前的 Namenode 是单点）。

分片动态路由 - 路由转发

1. 每个节点都保存所有路由信息，客户端请求任意节点皆可；

2. 架构相对简单一些，一般通过 gossip 协议来实现分片信息更新；

3. 无法支持超大规模集群，Redis官方建议1000以内，实际集群数量建议100以内。

分片架构高可用方案1 - 独立备份

【原理】

每个分片有独立的备份节点，可以用主备、主从、集群选举等方式实现。

【优缺点】

1. 实现简单；

2. 机器硬件成本比较高。

【应用】

存储系统已经支持节点级别的复制。

分片架构高可用方案2 - 互相备份

【原理】

分片之间的节点互相备份。

【优缺点】

1. 实现复杂；

2. 机器硬件成本相对来说低，互相利用。

【应用】

存储系统支持数据块级别的复制。

分区架构的本质

本质：通过冗余 IDC 来避免城市级别的灾难，并提供就近访问。

分区架构全局路由 - DNS 和 GSLB

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

GSLB：非标准，需要独立开发部署，功能非常强大，可以做状态监测、基于业务规则的定制路由。

分区架构备份策略 - 集中式

1. 设计简单，各分区之间并无直接联系，可以做到互不影响。

2. 扩展容易，如果要增加第四个分区（例如，西安分区），只需要将西安分区的数据复制到成都备份中心即可，其他分区不受影响。

3. 成本较高，需要建设一个独立的备份中心。

分区架构备份策略 - 互备式

1. 设计比较复杂，各个分区除了要承担业务数据存储，还需要承担备份功能，相互之间互相关联和影响。

2. 扩展麻烦，例如增加一个武汉分区。

3. 成本低，直接利用已有机房和网络。

分区架构备份策略 - 独立式

1. 设计简单，各分区互不影响。

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

3. 成本高，每个分区需要独立的备份中心，备份中心的场地成本是主要成本。

分区架构备份策略对比