架构训练营——第六周学习总结

分布式关系数据库

• 主从复制

• 读写分离

• 主从复制流程

1. 客户端：执行写操作

2. Master：写入本地 redo log

3. Master：写入本地 binlog

4. Slave：客户端读取线程，从 binlog 读取数据

5. Slave：Log 获取线程，将日志写入 Relay Log

6. Slave：Log 执行线程，从 Relay Log 中拉取日志，重放，完成主从复制

• 一主多从复制

• 分摊负载

• 专机专用

• 便于冷备

• 高可用

• 部分高可用——只能实现读操作的高可用，写操作仍然是单点

• 主主复制

• 实现写操作的高可用

• 每个主库都可以是一个主从集群，读写操作默认都是在第一主服务器集群上执行

• 需要指定第一主服务器，其余主服务器相当于冷备

• 注意事项

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

• 如果两个主库同时写入，可能会导致数据冲突，因此一般情况下写操作只会写入第一主服务器，其他主服务器作为备份写服务器

• 复制只是提高了读数据的并发操作能力，并没有提升写并发能力和存储能力

• 所有服务器上存储的数据都是一样的，包括所有主库和从库

• 表结构变更会造成巨大的同步延迟

• 数据分片

• 分片目标

• 将不同的数据分布在不同的数据库实例上，使得增加数据库实例就可以提升集群的读写并发能力

• 分片的优势

• 提升整个集群的存储能力

• 提升整个集群的写并发能力

• 实现方式

• 硬编码实现数据分片

• 映射表外部存储

• 由专门的存储记录分区键与数据库服务器的映射关系

• 面临的挑战

• 需要大量额外代码，引入复杂度

• 无法进行跨分片关联查询

• 跨分片无法支持事务

• 随着数据量增长，需要更多服务器

• 数据分片中间件

• MyCat

• Cobar

• Sharding-JDBC

• 数据库部署方案

• 单机单库

• 主从复制

• 业务分库

• 综合部署

分布式 NoSQL

• 关系数据库本质上并不是为了分布式场景所设计的，我们采用了各种手段实现了关系数据库的分布式，但是还是有比较多的限制

• NoSQL 的伸缩性更好，更适用于分布式场景

• CAP 原理

• 一致性 Consistency

• 客户端每次读取到的都应该是最新写入的数据，或者返回一个错误，而不是过期数据

• 可用性 Availability

• 客户端的每次请求都应该得到一个响应，而不是返回一个错误或者失去响应

• 分区容错性 Partition Tolerance

• 因为网络原因，即使某些服务节点之间消息丢失或者延迟了，系统仍然是可以运行的

• CAP 定理

• 在分布式系统必须满足分区容错性的前提下，可用性和一致性无法同时得到满足

• 最终一致

• 允许集群中节点数据存储的不一致，但是尽量保证客户端读取到的数据是一致的

• CAP 原理仍然适用

• 解决数据冲突

• 根据时间戳，最后写入覆盖

• 客户端冲突解决

• 适用于客户端逻辑较重的场景

• 投票解决冲突

• HBase 架构

• HMaster

• 数据分片的路由选择

• 通过 Zookeeper 实现高可用

• HRegionServer

• 一个服务器实例

• HRegion

• HRegionServer 内部的一个逻辑分区

• HFile

• Hadoop 分布式文件系统

• ACID

• Atomicity 原子性

• Consistency 一致性

• Isolation 隔离性

• Durability 持久性

• BASE

• Basically Available 基本可用

• 系统在遇到不可预知的故障时，允许损失一部分可用性，如响应时间上的损失或非核心功能上的损失

• Soft State 软状态

• 允许系统中的数据存在中间状态，且该中间状态不会影响系统整体的可用性

• 即允许不同副本的数据之间存在同步延迟

• Eventually Consistent 最终一致

• 系统中的数据副本，经过一段时间的同步后，最终可以达到一致的状态

• 本质上是需要系统保证数据能够达成一致，而不需要保证实时的强一致

Zookeeper

• 解决的问题

• 在满足集群高可用的前提下，尽量保证各节点的数据一致性

• Paxos 算法

• 通过投票来实现集群数据的一致性

• 角色

• Proposer

• Acceptor

• Learner

• 阶段

• Prepare

• Proposer 向 Acceptors 发出 Prepare 请求，Acceptors 针对收到的 Prepare 请求进行 Promise 承诺

• Accept

• Proposer 收到多数 Acceptors 承诺的 Promise 后，向 Acceptors 发出 Propose 请求，Acceptors 针对收到的 Propose 请求进行 Accept 处理

• Learn

• Proposer 在收到多数 Acceptors 的 Accept 之后，标志着本次 Accept 成功，决议形成，将形成的决议发送给所有 Learners

• ZAB 协议

• 角色

• Leader

• Follower

• 阶段

• Propose

• Ack

• Commit

• 请求处理过程

1. Client：Request

2. Follower：Request

3. Leader：Propose

4. Follower：Ack

5. Leader：Commit

6. Follower：Response

• 树形数据结构

• Zookeeper API

• 典型应用场景

• 配置管理

• Master 选举

• 集群管理

• 负载均衡

• 故障转移

• 性能

• 读操作

• 性能高

• 因为集群中各节点数据是一致的，因此任意一个节点都可以提供读服务

• 节点越多，读操作吞吐量越高

• 写操作

• 性能低

• 因为写操作需要保证一致性，涉及到 Propose、Ack 和 Commit 各个阶段，所以性能较低

• 节点越多，写操作吞吐量越低

搜索引擎

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

• 网络爬虫

• 网页去重

• 云存储与云计算

• 倒排索引

• 内容相似性

• 链接关系

• 链接分析（Page Rank）

• 检索分析

• Cache 系统

• 网页排序

• 爬虫系统架构

• 爬虫的本质就是 HTTP GET 请求

• 原理概述

1. 预设一定数量的种子 URL

2. 通过 HTTP GET 请求种子 URL ，进行网页下载

3. 将下载到的网页进行存储，并更新已下载 URL 集合

4. 解析网页中的超链接，并持续对这些超链接进行 HTTP GET 请求

• 爬虫禁止协议

• User-agent

• Disallow

• 文档矩阵与倒排索引

• 正排索引

• 站在文档的角度，记录了一个文档中出现的所有单词及其位置

• 倒排索引

• 站在单词的角度，记录了一个单词在哪些文档中出现了

• 关键词搜索，就是将关键词进行分词，然后通过倒排索引找到所有分词所在文档的交集，整个过程效率很高

• 带词频的倒排索引：{DocId,TF}

• 带词频与位置的倒排索引：{DocId,TF,Pos}

• Lucene 架构

• 倒排索引

• 字典 -> 倒排表

• 准实时更新

• Lucene 引入了段的概念，倒排索引的更新都是在段上操作的

• 新增：创建新的段

• 删除：创建 .del 的段，在数据查询时进行过滤

• 修改：新增 + 删除

• 为了控制段的数量，必须定期进行段合并操作

• 劣势

• 不支持分布式集群

• 无法支持海量数据的存储

• 无法实现高可用

• ElasticSearch 架构

• 优势

• 索引分片，实现分布式：{Node,Shard}

• 索引备份，实现高可用：Replica

• 简单易用的 API

• 使用前需要对分片数量有一定规划，对分片进行预分配

• 将 ElasticSearch 作为分布式 NoSQL 使用，保存业务数据，兼备了高可扩展性和快速的搜索特性，是目前使用比较广泛的方案

Doris 架构

• 逻辑架构

• 二层架构

• Client

• DataServer + Store

• 核心组件

• DataServer

• Store

• Client

• Administration

• 概念模型

• Machine

• 物理机

• Node

• 逻辑分区单元

• 一台 Machine 可以运行多个 Node

• Namespace

• 用于对数据进行逻辑划分的 Tag

• 客户端需感知 Namespace

• 数据管理无须识别 Namespace

• 数据分区

• 数据分区主要用于解决海量数据的分布式存储问题

• 客户端计算分区

• 分区算法 Partition Policy

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

• 划分固定数量的 Virtual Node

• 数据 key 通过分区算法路由到 Virtual Node

• Virtual Node 通过映射表映射到具体的 Physical Node 上

• 集群伸缩时，只需修改 Virtual Node 与 Physical Node 的映射关系即可，无需大量迁移数据

• Client 从 ConfigServer 中拉取分区配置

• 基本访问架构

• 默认两个节点双写，读取可在任意一个节点上完成（W2 R1）

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

• 基于 RedoLog 进行数据恢复

• 基于 UpdateLog 进行数据同步

• 高可用设计

• 保证高可用最有效的手段就是冗余存储

• 通过定时心跳完成健康检查

• 可用性状态

• 瞬时失效：例如网络抖动等，可自动重试

• 临时失效：暂时不可用，一段时间后可恢复

• 服务端停机升级

• 网络暂时不可用

• 永久失效

• 机器下线