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

分布式关系型数据库

CAP 原理与 NoSQL 数据库架构

Zookeeper 与分布式一致性架构

搜索引擎架构

一、分布式数据库

MySQL 复制 --- 主从复制

（从服务器客户端线程 自 主服务器数据库 Binlog 中 获取信息 追加存入从服务器数据库的 Relay Log 中，从服务器的 SQL 执行线程观察 Relay log，读取新命令，执行。 ）

--- 一主多从复制 （读--高可用）

(优点：1. 分摊负载 2.专机专用 3.便于冷备 4.高可用)

-- 主主复制 （写-- 高可用）

-- 主主失效恢复 （写-- 高可用）

-- 主主失效的维护过程

MySQL 复制注意事项：

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

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

3. 更新表结构直接操作各个数据库，因为以复制方式，更新表结构会导致巨大的同步延迟。

数据分片（目标，特点，原理）

实现方式：1.硬编码实现 2. 外部存储一个 映射表（具体数据主键--存放的数据库服务器）

数据分片的挑战：

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

• 无法执行多分片的联合查询。

• 无法使用数据库的事务。

• 随着数据的增长，如何增加更多的服务器问题。

分布式数据库中间件 （Mycat , Cobar）

Cobar 系统组件模型，做集群伸缩，扩容策略

数据库部署方案：

1.单一服务与单一数据库

2.主从复制实现伸缩

3.(功能分割(---业务分库))两个 Web 服务及两个数据库

4.综合部署(功能分割(---业务分库)+分布式集群(数据分片+主从复制+失效转移))

NoSQL 数据库架构

CAP 原理:

C 一致性(Consistency)

每次读取的数据都应该是最近写入的数据或者返回一个错误,而不是过期的数据.

(Every read receives the most recent write or an error.)

A 可用性(Availability)

每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证是最近写入的.

也就是说,系统需要一直都是可以正常使用的,不会引起调用者的异常,但是并不保证响应的数据是最新的.

(Every request receives a (non-error) response,without the guarantee that it contains the most recent write)

P 分区耐受性(Partition tolerance)

即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的.

(The system continues to operate despite )

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

即在分布式系统必须满足分区耐受性的前提下,可用性和一致性无法同时满足.

最终一致性

最终一致性-- 写冲突--->根据时间戳,最后写入覆盖.

客户端冲突解决-- 由客户端根据业务需求处理数据.

投票解决冲突(Cassandra):

尝试写入 3 个节点,等待至少 2 个节点响应更新成功.

尝试从 3 个节点读取.等待至少 2 个节点返回.取最新版本.

Cassandra 分布式架构:

客户端连接到任意 1 个节点,按照投票一致性级别写入记录 1234.

此节点计算记录 1234 的分区范围,然后将查询发送给存有数据的 3 个节点.

HBase 架构

Log Structed Merge Tree (LSM 树)

ACID

A 原子性(Atomicity) : 事务要么全部完成,要么全部取消.如果事务崩溃,状态回到事务之前(事务回滚).

C 一致性(Consistency):只有合法的数据(依照关系约束和函数约定)才能写入数据库.

I 隔离性(Isolation):如果 2 个事务,T1 和 T2 同时运行,事务 T1 和 T2 最终的结果是相同的,不管 T1 和 T2 谁先结束,隔离性主要依靠锁实现.

D 持久性 (Durability):一旦事务提交,不管发生什么(崩溃或者出错),数据要保存在数据库中.

BASE

基本可用 (Basically Available):

系统在出现不可预知故障时,允许损失部分可用性,如响应时间上的损失或功能上的损失.

软状态(弱状态) -- Soft state :

指系统中的数据存在中间状态,并认为中间状态的存在不会影响系统的整体可用性,

即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时.

最终一致性 (Eventually consistent):

指系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态,因此,

最终一致性的本质是需要系统保证数据能够达到一致,而不需要实时保证系统数据的强一致性.

ZooKeeper 与分布式一致性架构: (高可用)

分布式系统脑裂

---在一个分布式系统中,不同服务器获得了互相冲突的数据信息或者执行命令,导致整个集群陷入混乱,数据损坏.

分布式一致性算法 Paxos

三个角色: Propose, Acceptor, Learner

Zab 协议

搜索引擎架构

1. 互联网搜索引擎整体架构

2. 爬虫系统架构,爬虫禁爬协议

3. 文档矩阵 与 倒排索引(带词频的倒排索引,带词频与位置的倒排索引)

4. Lucene 架构-->Lucene 倒排索引

5. Lucene 索引文件准实时更新,不支持分布式集群.

6. Lucene 引入 段 的概念,将一个索引文件拆分成多个子文件,每个子文件叫做段,每个段都是一个独立的可被搜索的数据集,索引的修改针对段进行操作.

ElasticSearch 架构:

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

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

3. API 更简单,更高级

4. ES 分片预分配与集群扩容

完成.