写点什么

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

用户头像
Anyou Liu
关注
发布于: 2020 年 11 月 01 日

本周学习了分布式关系数据库、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在对索引进行分片时,需要预分配,确定分片的个数。这样当对集群进行扩容时,分片的数据会迁移到新的节点上。

用户头像

Anyou Liu

关注

还未添加个人签名 2019.05.24 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第 1 期 - 第 6 周学习总结