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

MySQL复制

MySQ主从复制

Mysql 中有一种日志叫做 bin 日志（二进制日志）。这个日志会记录下所有修改了数据库的SQL 语句（insert,update,delete,create/alter/drop table, grant 等等）。

主从复制的原理其实就是把主服务器上的 bin 日志复制到从服务器上执行一遍，这样从服务器上的数据就和主服务器上的数据相同了。

过程：

1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。

2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件

3、主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。

4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个，在后面详细讲解）。

5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

从节点：

I/O Thread: 从 Master 节点请求二进制日志事件，并保存于中继日志中。

Sql Thread: 从Relay log 中读取日志事件并在本地完成重放。

主节点：

Dump Thread:为每个 Slave 的 I/O Thread 启动一个 dump 线程，用于向从节点发送二进制事件。

思考：从节点需要建立二进制日志文件吗？

看情况，如果从节点需要作为其他节点的主节点时，是需要开启二进制日志文件的。这种情况叫做级联复制。如果只是作为从节点，则不需要创建二进制文件。

MySQL一主多从复制

与主从复制不同点在于，主节点对每个需要复制的从节点都会启动一个Dump Thread，其他步骤跟主从复制一致

一主多从复制的优点：分摊负载；专机专用；便于冷备；高可用。

MySQL主主复制

跟主从复制的不通点在于，原本的从节点换成主节点，同时增加给其他节点同步Binlog事件，两个主节点都开启Binlog和Relaylog，相互同步，缓解一台主库的压力，并提升单台主数据库的可用性。需要一个能够在同时作业时的负载均衡路由算法将压力有规律的分摊给两个主库。

MySQL主主失效恢复



MySQL复制注意事项：

1、主主复制的两个数据库不能并发写入

2、复制只是增加了数据的读并发处理能力，没有增加些并发能力和存储能力。

3、更新表结构会导致巨大的同步延迟。一般最好是手动介入去更新表结构。



数据分片

https://www.cnblogs.com/leeSmall/p/9462658.html

分片目标

分片特点

分片原理



1、硬编码实现数据分片

2、映射表外部存储

3、数据分片的挑战

3.1、需要大量的额外代码，处理逻辑因此变得更加复杂

3.2、无法执行多分片的联合查询

3.3、无法使用数据库的事务

3.4、随着数据的增长，如何增加更多的服务器



分布式数据库中间件-mycat

MyCat前身是Amoeba，Amoeba又来源于Cobar



NoSQL

CAP原理

一致性Consistency

一致性是说，每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read

receives the most recent write or an error），而不是过期数据，也就是说，数据是一致的。

可用性Availability

可用性是说，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error)response, without the guarantee that it contains the most recent write），也就是说系统需要一致都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。

分区耐受性Partition tolerance

分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该可以操作的（The system continues to operate despite an arbitrary number of

messages being dropped (or delayed) by the network between nodes）



当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性就得不到保证。

对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。

当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不保证这个数据是最新的。

所以，关于CAP原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。



CAP原理与数据一致性冲突

最终一致性

最终一致性写冲突

客户端写冲突解决

投票解决冲突Cassandra

Cassandra分布式解决方案



Hbase架构

https://www.jianshu.com/p/9d3d388eae19?utm_source=oschina-app

Log Structed Merge Tree

https://www.cnblogs.com/owenma/p/8723551.html



分布式一致性Zookeeper

https://blog.csdn.net/qq_21125183/article/details/86484213



Doris

基本情况和如何申请专利



课堂笔记：

oceanbase

tidb

分布式数据库不用考虑分表

CQRS



MySQL

分片中间件需要预设路由方式

例如可以根据省份路由



MyCat前身是Amoeba，Amoeba又来源于Cobar

中间件有橙色四个模块组成：SQL解析模块，SQL路由,SQL执行代理模块，结果合并模块



余数hash取模得余数路由增减服务器

把新的key分到新服务器上

一个库中放多个Schema，预设对几取余，就设置在一个数据库设置几个Schema，迁移数据时，只用将几个库的部分Schema迁移到新的库中就行

根据实际情况可以选择部分数据库进行分片，不能盲目分片

同步的时候在快要同步完成又不能停机的情况下，可以在这几秒钟时间DBA注意手动处理

分片后就不用join，需要使用的话就需要手动将join拆分开，得到数据再组合起来



一致性存在，但是可用性不是绝对的



最终一致性

用户一致



时间戳验证，时间一致最好的是用gis验证时间戳



投票解决冲突（Cassandra）保证一致性



HMaster提供路由分配，为了高可用有多个服务器上存在HMaster，提供服务的是主HMaster

通过zookeeper选出一个主HMaster，宕机也由zookeeper再次选一个出来，避免脑裂

HRegionServer 宕机可以将宕机的服务负责的key交给其他 HRegionServer 管理，key存放的是指向 HFile文件位置，就可以获得数据

增加减少服务器时，只用将key迁移过去就行，类似于Mycat分配多个Schema，不同是数据再Hadoop上，不用动，更简单省事，由主HMster

HFile文件会有三个备份



HFile是存在Hadoop上的



一个key只有个 HRegionServer 负责就不会有写入多个地方，

HFile在Hadoop上只能追加写，没有修改，类似于存放的操作过程的记录，

HBase一致性比较高，可用性差一点

HRegionServer 中的HRegion相当于分片



HBase 使用的是LSM树（Log Structed Merge Tree）



写入一个数据，建立一个树存储，增，删除或修改操作的时候都是增加一个节点记录数据某种标记或新增修改的值

到了一定规模就会跟硬盘上的树合并，就会把数据写出到硬盘中的树上，如果合到硬盘上的树发现合过来的新树上有删除标记，就会删除硬盘上这个节点数据，

更新的话原来的硬盘树上有数据就会刷新新的数据，如果硬盘上的树上没有数据，就会新增树枝节点，把内存树合到硬盘C1树上，当C1树到达一定规模后，

就会合并C2树，合并完变成到Ck树上，追加节点时比较方便，查找时需要内存没有到硬盘新树一直没有查到会查到最终树，才确定没有查到，

写操作性能高，宕机恢复花费时间长点

机械磁盘顺序写的时候比随机写至少高出2个数量级，所以HBase性能高

写的时候写内存，同时写磁盘，所有操作都是有log记录

HBase 的 HRegionServer宕机了就不可用了，虽然数据一致性保证较好



ACID(RDB)酸与BASE（NOSQL）碱



少量需要 join 时可以使用指定单独一个数据库服务器负责支持 join



怎么让公司让你用新技术，目前而又不赚钱



UDAS-统一直接存取系统(Unified Direct Access System)

原NoSQL数据自动扩容都会崩

需求是超过mycat和hbase的扩容机制

电商项目可用性第一位，一致性可以通过最终一致性来完成

涉及到钱的NOSQL存储数据不一致，有问题直接将钱冻结想办法解决问题



分布式集群有多台服务器，

1、每次请求需要访问的服务器需要一致性hash路由/

2、负载均衡用轮训或加权轮训，散列hash，最少连接进行路由选择

3、分布式数据库要根据SQL解析出来的分片关键字段进行路由解析

路由算法解析方式确定了扩容时的难度，从而确定怎么分区

核心是路由分区算法



redis是虚拟分区4万多个桶，超过时就会出问题

doris是设置的1万多个，对应的最多增加到100台内服务节点



问题：是否可以二次虚拟划分，是否有必要



doris 双写，单读随机读一个

瞬时失效，多次重试，3次尝试

Config server 检查如果可用，则单个服务器自己解决问题，如果也不可用就需要通知集群其他服务器停止向这个服务器写数据

永久失效是2小时还未恢复



备份写是binlog记录操作



恢复写入时，服务器应该是只写不读，还是走另外一个节点



两个服务器提供服务，双写单读，还需要一个备用服务器，一般是手动迁移处理

X:新增服务器数

M:原来服务器数



硬盘存取，散列表



Zookeeper

作为控制中心控制选主节点



为了高可用zookeeper也需要2台一主一备

需要的决策选择的一致性



• Proposer

• Acceptor 也是 learner

• Learner



leader负责提议

当leader宕机，重新选举新的leader，时间很短系统会不可用，选举成功后就恢复了



少部分拒绝提议的，需要在commit时给服务返回操作失败，同步一致提议数据



宕机一半的服务器时，整个就没有办法确认数据了，确认数据需要半数以上确认，整个数据就不可用了

选择leader时是监视没有leader时就抢注为leader

读数据不需要通过leader

commit失败怎么处理



存放的是虚拟地址，

ephemeral



系统起名字2到3个字节



doris扩容时，是一个group先迁移，另一个group继续保持响应，然后等一个group迁移完，恢复响应后，再迁移到另一个group