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

6.1 分布式关系数据库（上）

• MySQL复制

• MySQL主从复制

• MySQL一主多从复制

• 分摊负载

• 专机专用

• 便于冷备

• 高可用 - 部分高可用，读数据高可用

• MySQL的主主复制

• 主主复制的两个数据库不能并发写入。

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

• 更新表结构会导致巨大的同步延迟。

• MySQL的主主失效恢复

• MySQL主主失效的维护过程

• 数据分片

• 分片目标 - 分布式数据库通过增加服务器，提高处理能力

• 分片特点

• 分片原理

• 硬编码实现数据分片

• 映射表外部存储

• 数据分片的挑战

• 需要额外代码

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

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

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

6.2 分布式关系数据库（下）

• 分布式数据库中间件 - 中间件实现分片逻辑

• Cobar架构

• 路由配置 - 如何做集群的伸缩

• 一开始就取一个模比较大的值，将来再做数据迁移(主从复制)。

• 数据库部署方案

• 单一服务与单一数据库

• 两个Web服务及两个数据库

• 综合部署

6.3 CAP原理与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 原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。

• 最终一致性

• 所谓的最终一致性是说，在一段时间范围之内数据是不一致的。但是当网络延迟恢复，数据同步完成的时候，最终是一致的。

• 最终一致写冲突

• 简单冲突处理策略：根据时间戳，最后写入覆盖。

• 客户端冲突解决

• 客户端合并数据

• 投票解决冲突(Cassandra)

• HBase

• Log Structed Merge Tree (LSM 树)

• ACID与BASE

• 传统关系型数据库ACID - 原子性 (Atomicity), 隔离性(Isolation), 持久性(Durability), 一致性(Consistency)

• NoSQL BASE - 基本可用(Basically Available), 软状态，弱状态(Soft state)，最终一致性(Eventually consistent)

6.4 ZooKeeper与分布式一致性架构

• 分布式系统脑裂 - 在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，本称作分布式系统脑裂。

• ZooKeeper需要多个服务器，保证高可用。

• 分布式一致性算法Paxos

• 三个角色

• Proposer

• Acceptor

• Learner

• 三个阶段

• Prepare阶段

• Accept阶段

• Learn阶段

• Proposer 生成全局唯一且递增的Proposal ID (可使用时间戳加Server ID)，向所有Acceptors 发送Prepare 请求，这里无需携带提案内容，只携带Proposal ID 即可。

• 相对比较复杂

• Zab协议

• Leader, Follower

• ZooKeeper

• Zookeeper的架构

• 树状记录结构

• API

• 应用场景

• 配置管理

• 选Master

• 集群管理(负载均衡与失效转移)

• 性能

• 读的性能要远超过写的性能

• 服务器数目越多，读的性能越高。服务器数目越多，写的性能越差。

6.5 搜索引擎的基本架构

• 互联网搜索引擎整体架构

• 爬虫系统架构

• 爬虫禁爬协议

• 文档矩阵与倒排索引

• 倒排索引 - 哪些文档里包含了特定的词

• 带词频的倒排索引

• 带词频与位置的倒排索引

• Lucene架构

• Lucene索引文件准实时更新 - Lucene 中引入了段的概念，将一个索引文件拆分为多个子文件，每个子文件叫做段，每个段都是一个独立的可被搜索的数据集，索引的修改针对段进行操作。

• 不支持分布式集群

• ElasticSearch架构

• 索引分片，实现分布式

• 索引备份，实现高可用

• API更简单，更高级

• ES分片预分配与集群扩容

6.6 NoSQL案例：Doris分析案例（一）

• 当前现状

• 当前存在的问题

• 开源解决方案为什么不行

• 产品需求

• 产品定位

• 解决问题

• 产品目标

• 功能目标

• 非功能目标

• 约束

• 逻辑架构

• 两层架构 - Client, Data Server + Store

• 四个核心组件 - Client, Data Server, Store, Adminstration

• KV Storage 概念模型

• Logical Layer - Namespace

• 关键技术点

• 数据分区

• 基于虚拟节点的分区算法

• 均衡性

• 波动性

6.7 Doris分析案例（二）：高可用与集群扩容如何设计？

• 基本访问架构

• 对等Node 访问

• 双写保证可用性（W=2， R=1）

• 基于分区算法查找两个Node

• 数据恢复和数据同步

• 集群管理– 健康检查和配置抓取

• 检查1：ConfigServer 对 DataServer心跳检查

• 检查2：Client 访问时Fail 报告

• 其他Client 定时配置抓取

• 关键技术点- 可用性关键场景

• 瞬时失效

• 临时失效

• 永久失效

• 关键技术点－临时失效的fail over

• 备用节点(日志节点）

• 关键技术点– 永久失效failover

• 每份Data 写两份保证高可用：Copy 1， Copy2

• 一致性处理：version(timestamp)

6.8 Doris分析案例（三）：扩容伸缩是如何设计的？

• 关键技术点- 扩容实施数据迁移： 基本原理

• 数据可识别功能- 逻辑数据结构

• Namespace：一个业务实体数据的集合