分片架构的本质
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. 成本高，每个分区需要独立的备份中心，备份中心的场地成本是主要成本。
分区架构备份策略对比
原文始发于微信公众号（二进制跳动）：存储架构模式之分片架构和分区架构
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167068.html
