分片架构&分区架构

分片架构

主从复制

缺点：

1. 只有主机承担写，写性能会存在瓶颈
2. 每台机器保存全量数据，存储存在瓶颈

分片架构

本质

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

设计核心

分片规则：数据按照什么规则分片

核心原则

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

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

分片数据

分片方式	具体说明
主键	适合主业务数据，例如数据库分片常用的用户ID、订单ID，Redis分片的key，MongoDB的文档ID
时间	适合流水型业务，例如创建日期、IoT事件、动态

分片规则

规则	具体说明
Hash分片	1. sharding key=hash(原始键值)分布均匀，但是不支持范围查询 2. 扩容服务器麻烦，需要做数据迁移
范围分片	1. 分布可能不均匀，支持范围查询 2. 方便扩容新服务器，无需迁移历史数据

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

分片动态路由-配置中心

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

分片动态路由-路由转发

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

缺陷

无法应对城市级别的故障

分片架构高可用方案

方案1-独立备份

原理

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

优缺点

1. 实现简单
2. 机器硬件成本比较高

应用

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

案例

MongoDB，Redis，MySQL

方案2-互相备份

原理

分片之间的节点互相备份

优缺点

1. 实现复杂
2. 机器硬件成本相对来说低，互相利用

应用

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

案例

HDFS、Elasticsearch

分区架构

本质

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

全局路由

DNS

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

GSLB

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

备份策略

集中式

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

互备式

1. 设计比较复杂，各个分区除了要承担业务数据存储，还需要承担备份功能，互相之间互相关联和影响
2. 扩展麻烦，例如增加一个武汉分区
3. 成本低，直接利用已有机房和网络

独立式

1. 设计简单，各分区互不影响
2. 扩展容易，新增加的分区只需要搭建自己的备份中心即可
3. 成本高，每个分区需要独立的备份中心，备份中心的场地成本是主要成本

对比

	集中式	互备式	独立式
成本	中	低	高
可扩展	高	低	高
复杂度	低	高	低