架构师训练营 第六周 学习心得

一. 数据库分片

1. 分片目标

• 分布均匀，即每台设备上的数据量要尽可能相近；

• 负载均衡，即每台设备上的请求量要尽可能相近；

• 扩缩容时产生的数据迁移尽可能少。

2. 数据库分片方式

2.1 垂直分片

• 按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库

2.2 水平分片

• 水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。

3. 数据库分片原理

3.1 hash方式

• 哈希表（散列表）是最为常见的数据结构，根据记录（或者对象）的关键值将记录映射到表中的一个槽（slot），便于快速访问。在哈希表中，最为简单的散列函数是 mod N（N为表的大小）。即首先将关键值计算出hash值（这里是一个整型），通过对N取余，余数即在表中的位置。数据分片的hash方式也是这个思想，即按照数据的某一特征（key）来计算哈希值，并将哈希值与系统中的节点建立映射关系,从而将哈希值不同的数据分布到不同的节点上。

• 当加入或者删除一个节点的时候，大量的数据需要移动；数据不均衡的问题。原始数据的特征值分布不均匀，导致大量的数据集中到一个物理节点上；对于可修改的记录数据，单条记录的数据变大。

3.2 一致性hash

• 一致性hash是将数据按照特征值映射到一个首尾相接的hash环上，同时也将节点（按照IP地址或者机器名hash）映射到这个环上。对于数据，从数据在环上的位置开始，顺时针找到的第一个节点即为数据的存储节点。

• 在其中一个节点挂掉的时候，该节点的压力也会被全部转移到下一个节点。我们希望的是“一方有难，八方支援”，因此需要在增删节点的时候，已存在的所有节点都能参与响应，达到新的均衡状态。

3.3 range based

• 就是按照关键值划分成不同的区间，每个物理节点负责一个或者多个区间。其实这种方式跟一致性hash有点像，可以理解为物理节点在hash环上的位置是动态变化的。

• range based的元数据管理相对复杂一些，需要记录每个节点的数据区间范围，特别单个节点对于多个区间的情况。而且，在数据可修改的情况下，如果块进行分裂，那么元数据中的区间信息也需要同步修改。

4. 数据分片的挑战

• 虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构在获得了收益的同时，也引入了新的问题。面对如此散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道数据需要从哪个具体的数据库的分表中获取。

• 能够正确的运行在单节点数据库中的 SQL，在分片之后的数据库中并不一定能够正确运行。例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。跨库事务也是分布式的数据库集群要面对的棘手事情。合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。 而基于 XA 的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。

二. NoSQL

1. 诞生的原因

• 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度;

• 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量;

• 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理;

• 庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

2. NoSQL的三大基石

2.1 CAP

一个分布式系统不能同时满足一致性（Consistency），可用性（Availability），分区容错性(Partition tolerance)。

一致性： 任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

可用性： 每一个操作总是能在确定的时间内返回，也不是系统随时都是可用的。

分区容错性： 在出现网络分区（如断网）的情况下，分离的系统也能正常运行。



• NoSql则以CAP理论为指导，大多选择实现了CAP理论的两点（如CA、CP、AP）

2.2 BASE

即基本可用（Basically Availble）、软状态/柔性事务（Soft-state）、最终一致性（Eventual Consistency）

2.3 最终一致性

• 为了高可用和海量数据存储，我们会选择牺牲一致性，但这并不意味着我们不要一致性，而是我们可以选择不实现强一致性，而实现弱一致性或者最终一致性。无论是在关系型数据库或者NoSql中，我们都是通过事务来实现一致性。

三. ZooKeeper

1. 分布式系统脑裂

• 在一个高可用系统中，当联系着的节点断开联系时，本来为一个整体的系统，分裂成两个独立节点，两个节点开始争抢共享资源造成系统混乱、数据损坏的现象，成为“脑裂”。

2. 分布式一致性算法 paxos

2.1 三个角色

• Proposer

• Acceptor

• Learner



第一阶段： Prepare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。



第二阶段： Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的propose请求进行Accept处理。



第三阶段： Learn阶段。Proposer收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。





Proposer生成全局唯一且递增的Proposal ID（可以使用时间戳+ServerID）,向所有的Acceptors发送Prepare请求。这里无需携带内容提案，只携带Proposal ID即可。Acceptors收到Prepare和propose请求后

1. 不再接受 Proposal ID小于等于当前请求的Prepare请求。

2. 不再接受 Proposal ID小于当前请求的propose请求。

3. ZooKeeper是什么

• ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

4. 用途

4.1 数据发布与订阅（配置中心）

• 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

4.2 负载均衡

• 在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。

4.3 命名服务(Naming Service)

• 通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

4.4 分布式通知/协调

• ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理

4.5 集群管理与Master选举

• 在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。

4.6 分布式锁

• 分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。