架构师训练营第 1 期 - 第 6 周学习总结

本周学习了分布式关系数据库、CAP原理与NoSQL数据库架构、Zookeeper、搜索引擎架构、Doris

一、分布式关系数据库

MySQL数据库复制

为提升数据库处理性能，我们可以对数据库进行读写分离，在主数据库进行写操作，在从数据库进行读操作。主数据库的数据需要同步到从数据库，如何来做呢？

1. 主从复制

默认情况下，MySQL采用异步复制的方式。主库接收到客户端的请求之后，会先写入Binlog，然后再提交事务，更新数据库中的数据，事务提交完成后，给客户端返回响应。从库会有一个专门的Log获取线程，从主库接收Binlog，然后把Binlog写到Relay Log中去，另外的执行线程会执行Relay Log中的操作，把所有的写操作都更新到从数据库。

1. 一主多从复制

为了提升数据库的查询能力，可以部署多个从节点。一主多从的所有从节点执行的过程都是一样的，每个从节点都接收主库的Binlog，然后回放写操作到自己的从节点上。

1. 主主复制

2个主节点主要是为了实现主节点的高可用，当一个主节点失效时，可以快速切换到另一个主节点上。主节点和主节点的复制也是一样的，当主节点A执行写操作时，主节点A生成Binlog，另一个主节点B获取Binlog，写到Relay Log中，主节点B的执行线程去执行这些回放操作，把写操作更新过来，当主节点B执行写操作时，过程是一样的。2个主节点的情况下，同时只会有一个主节点执行写入操作，不会同时执行写操作，否则，可能会导致数据库的数据丢失或者数据不一致。每个主节点都有自己的从节点，当写操作从主节点A切换到主节点B时，读操作也会从主节点A的从节点切换到主节点B的从节点。

数据分片

当MySQL需要处理海量数据时，主从架构支持不了这么大的数据量和高并发，这个时候就需要进行分库分表。分库分表的话，就需要用分片算法，把数据均匀的分布到不同的数据库中去，数据分片可以采用硬编码、或者查表法。

1. 硬编码方式

硬编码方式是指根据分片的key得到hash值，然后对数据库服务器的数量做取模运算，得到的编号就是数据库服务器的编号。比如我们有id这一列作为分片的key，当id=20时，做取模运算，得到服务器编号为0的数据库，写操作和读操作都发送到编号为0的数据库，当id=21时，做取模运算，得到服务器编号为1的数据库，相应的操作都发送到编号为1的数据库。

1. 查表法

外部查表法是指查询数据库表得到分片的数据库编号。比如我们有下面的表，以id这一列作为分片的key，当id=20时，得到服务器编号为0的数据库，当id=30时，得到服务器编号为1的数据库。

通过查表法，分片的策略可以动态调整，比较灵活，比如，当发现某个分片已经是热点的话，就可以修改分片的策略，动态增加分片。但是每次分片都需要多查询一次分片表，性能会慢，但是也可以通过把分片表缓存起来，来提升查询分片表的速度。

数据分片极大地限制了数据库的查询能力，当要查询的数据跨多个分片时，无法进行联合查询，可以把数据同步到其他存储里面，进行数据的查询操作。

分布式数据库中间件

因为数据分片之后，应用程序需要访问不同的数据库，代码就需要做大量的适配。为避免代码的适配和分片算法对应用程序的侵入，可以使用数据库中间件产品Mycat或者Cobar组件等。当使用Cobar组件时，在路由配置文件中，需要事先规划好多少台分片的数据库，然后配置这些数据库的数据源到配置文件中去。

比如我们目前有2台MySQL物理服务器，那么可以配置60个数据库实例，每台物理服务器上面30个实例，把所有的60个数据库实例的数据源都配置在路由配置文件中。如果后续要增加物理服务器，那么就需要把物理服务器1和物理服务器2上面的各10个数据库实例迁移到物理服务器3上，然后再修改路由配置文件，把原先的数据库实例地址指向新的物理服务器3。



二、CAP原理与NoSQL数据库架构

CAP原理

CAP原理包括3个指标：

1. 一致性（Consistency）

一致性是指客户端访问分布式集群中的任意一台节点时，要么读到最新的数据，要么返回错误。

1. 可用性（Availability）

可用性是指客户端访问分布式集群中的任意一台节点时，节点应该尽可能的返回数据给客户端，但不一定要返回最新的数据。

1. 分区耐受性（Partition Tolerance）

分区耐受性是指当发生网络原因导致消息丢失或者延迟时，系统仍然可以继续工作。

分布式系统不是单机系统，始终会面临网络分区的问题，所以分区耐受性是必须要考虑的指标。那么在一致性和可用性之间选择的话，如果选择了一致性，那么当发生网络分区时，就无法保证可用性，如果选择了可用性，那么当发生网络分区时，就无法保证一致性，因为可能读到旧数据。因此在设计分布式系统的时候，需要根据具体的业务场景，权衡选择C或者A。

NoSQL数据库架构

这里以Cassandra为例，Cassandra保证了CAP中的可用性和分区耐受性，并且实现了最终一致性

1. 高伸缩

Cassandra是一个高伸缩的存储系统，集群节点可以根据需要动态添加和删除。基于Gossip协议，每个节点都保存了一份节点成员的列表。

1. 高可用

Cassandra是一个故障容错的存储系统，如果某一个节点不可用，节点的其他成员会通过Gossip协议，把不可用节点的状态，散播到整个群组中。

1. 最终一致性

为了满足性能、伸缩和高可用等特性，Cassandra实现了最终一致性。最终一致性是指所有的更新操作在一段时间之后，最终会更新到所有的副本中。数据的不同版本可能会短暂存在，但是最终会达到一致的状态。最终一致性是为了满足高可用性的前提下的实现方案，可能会有读操作和写操作的延迟。



三、Zookeeper

Zookeeper是一个开源的分布式协调服务，可以用它进行配置管理、名字服务等等。Zookeeper实现了ZAB协议，是Paxos算法的一种具体实现。

集群需要选举选出主节点，ZAB协议支持3种成员身份。

1. 领导者

作为主节点，在同一时间集群只会有一个领导者。所有的写请求都必须在领导者节点上执行。

1. 跟随者

作为备份节点，集群可以有多个跟随者，他们会响应领导者的心跳，并参与领导者选举和提案提交的投票。跟随者可以直接处理并响应来自客户端的度请求，但对于写请求，跟随者需要将它转发给领导者处理。

1. 观察者

作为备份节点，类似跟随者，但是没有投票权，也就是说，观察者不参与领导者选举和提案提交的投票。

写操作只能由主节点处理。

在Zookeeper中，写请求必须在主节点上处理，并且提案的广播和提交，也是由主节点来完成的，所以主节点特别重要。如果它突然奔溃了，怎么？Zookeeper中的跟随者会发出领导者选择，选出新的领导者。



四、搜索引擎架构

搜索引擎是互联网应用中常用的技术，当需要在海量的数据中查询用户需要的数据时，就需要使用到搜索引擎。相比于数据库的Like查找速度，搜索引擎的查找速度更快。搜索引擎使用了一种特殊的数据结构，倒排索引。比如我们要搜索商品，有如下商品数据

构建倒排索引之后的数据结构有

关键字作为Keyword，对应值就是商品的ID，这样当我们要搜索苹果手机的时候，先搜索“苹果”，得到“123,456”的值，再搜索“手机”，得到“456”的值，两者取交集，得到456，那456就是我们要查找的商品。如果不是用倒排索引，那么普通的数据库Like查找就需要全表扫描，通过Name去一一匹配了，效率十分低下。当然，这里面还需要对商品Name进行分词，对分出来的词建立倒排索引。

比如我们常用的ElasticSearch，就是一个支持海量数据查询的搜索系统。它以Lucene为基础，扩展了分布式的功能

1. 索引分片，实现分布式

2. 索引备份，实现高可用

3. API更简单、更高级

ElasticSearch在对索引进行分片时，需要预分配，确定分片的个数。这样当对集群进行扩容时，分片的数据会迁移到新的节点上。