架构师训练营 1 期 - 第六周总结（vaik）

关注

发布于: 2020 年 11 月 01 日

本周概要

本周主要讲解是分布式数据存储的技术，从 mysql 的主从复制（读写分离）到主从多复制再到主主复制再到数据库分片提升写的高并发能力，数据库分片的中间件 cobar 以及 mycat，介绍他们的原理和机制，以及如何做集群的伸缩；接着讲述了 CAP 原理，最终一致性的实现原理，并讲解了 Cassandra 和 Hbase 的机制原理；然后是分布式一致性算法 Paxos,以及 Zookeeper 的 Zab 协议实现的分布式一致性的机制原理；再来就是搜索引擎的加构和原理，常用的搜索引擎框架 Lucence 和 ElasticSearch;最后介绍了智慧老师自己的案例 KV Engine Doris.关键技术点讲解。

分布式数据库

MySQL 复制

MySQL 主从复制
MySQL 主多从复制
分摊负载
专机专用
便于冷备
高可用
MySQL 主主复制

优点

当前主服务器失效时，可自动恢复到另一台主服务器

不足

主主复制的两个数据库不能并发写入
复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力
更新表结构会导致巨大的同步延迟

我的思考：我认为 MySQL 的主从复制的应该场景主要适合于，当前系统的最主要的瓶劲在于读的并发能力上，对于写和数据容量不存在的瓶劲的怀况，使用 MySQL 主从复制，使用主主复制是为了进一步提升写的高可用.

数据分片

硬编码实现数据分片

映射表外部存储

分布式数据库中间件

cobar

mycat

CAP 原理

概念理解

C 是 Consistency,指强一致性，系统在执行过某项操作后仍处于一致的状态。
A 是 Avalilabillity,指可用性，每一个操作总是在一定时间内返回结果。
P 是 Partition-tolerance,指分区容错性。大多数分布式系统都分布在多个子网络，每个子网络就是一个分区，分区容错是指区间通信可能失败，一般来说分区容错无法避免，因此 CAP 的 P 总是成立。

我的理解：

CAP 原理是指分布式系统无法同时满足上述三个指标，通常设计以满足 CP 或 AP 为主，当然不是说忽略第三个指标，虽然无法完全满足第三个指标，而是尽可能提升第三个指标。

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

最终一致写冲突

客房端冲突解决

投票解决冲突

ACID 与 BASE

ACID

原子性（Atomicity）: 事务要么全部完成，要么全部取消。如果事务崩溃，状态回到事务之前（事务回滚）。
隔离性（Isolation）: 如果 2 个事务 T1 和 T2 同时运行，事务 T1 和 T2 最终的结果是相同的，不管 T1 和 T2 谁先结束，隔离性主要依靠锁实现。
持久性（Durability）: 一旦事务提交，不管发生什么（崩溃或者出错），数据要保存在数据库中。
一致性（Consistency）: 只有合法的数据（依照关系约束和函数约束）才能写入数据库。

BASE

基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。
Soft state（弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
Eventually consistent（最终一致性）指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。