分布式关系数据库

MySQL复制

MySQL主从复制



MySQL一主多从





一主多从复制优点

l  分摊负载

l  专机专用

l  便于冷备

l  高可用

主主复制





MySQL主主失效恢复





MySQL主主失效维护过程





MySQL复制注意事项

l  主主复制不能向2个服务器同时写。

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

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

数据分片

l  硬编码实现数据分片





不足：1.应用代码需要实现分片逻辑。2.集群管理比较麻烦。

l  映射表外部存储





虽然通过映射表方式，解决与应用代码隔离的问题，但是还是没有解决如下主要问题：

不足：

1.       需要大量额外代码，处理逻辑复杂。

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

3.       无法使用数据库事务。

4.       随着数据增长，增加更多服务器比较难处理。

分布式数据库中间件

l  Mycat

l  Cobar

Cobra架构





Cobra系统组件模型





Cobra组件的核心是SQL路由模块。

数据库部署方案

l  单一服务器与单一数据库





l  主从复制实现伸缩





l  按业务垂直分库：2个web服务器与2个数据库





l  垂直&水平切分：综合部署





CAP原理与NoSQL数据库架构

CAP原理

一致性（Consistency）：每次读取的数据是最近一次写入的数据或返回一个错误，而不是过期数据，也就是数据一致性。

可用性（Availability）：每次请求都应该得到一个响应，而不是返回一个错误或失去响应，不过这个响应不需保证是最近写入的，也就是系统可以一直可以正常使用，不会引起调用者异常，但并不保证调用的数据是最新的。

分区耐受性（Partition tolerance）：即使网络原因，部分服务器节点之间消息丢失或延迟，系统依然可用操作。

对于分布式系统在必须满足分区耐受性的前提下，可用性和一致性无法同时满足。

CAP原来与数据一致性冲突





解决办法：最终一致性





冲突解决策略

简单冲突处理策略：用时间戳做版本号，最后覆盖写入。

客户端冲突解决





投票解决冲突（Cassandra）





Hbase架构



LSM树





ACID与BASE

传统数据库事务：ACID

l  原子性（Atomicity）

l  隔离性（Isolation）

l  持久性（Durability）

l  一致性（Consistency）

NoSQL数据库事务：BASE

l  基本可用（Base Available）：系统在不可预知故障时，允许损失部分可用性，如响应时间损失或功能损失。

l  弱状态（soft state）：允许系统中数据存在中间状态，不认为该中间状态不会影响系统整体可用性，即允许系统在不同节点的数据副本之间数据进行数据同步过程存在延迟。

l  最终一致性（Eventually consistency）：系统中所有数据副本，经过一段时间，达到最终一致性的状态，无需实时保证系统数据的强一致性。

ZooKeeper与分布式一致性架构

分布式系统脑裂

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

分布式一致性算法Paxos





第一阶段：prepare阶段。Proposer向acceptors发出prepare请求，acceptors针对收到prepare请求进行promise承诺。

第二阶段：accept阶段。Proposer收到多数acceptors承诺promise后，向acceptors发出propose请求，acceptors针对收到的propose请求进行accept处理。

第三阶段：learn阶段。Proposer在收到多数acceptors的accept之后，标志本次accept成功，决议形成，将形成的决定发送给所有learner。

Zab协议（zookeeper应用）





Zookeeper架构





搜索引擎的基本架构

互联网搜索引擎整体架构





爬虫系统架构





文档矩阵与倒排索引

倒排索引:每个词对应一些文档编号。

带词频与位置的倒排索引



Lucene架构



Lucene索引文件准实时更新

索引有更新，需全量创建一个新的索引替换原来索引文件。如果数据量大，效率会很低，由于创建一个索引成本很高，性能也很差。

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

l  新增：当有新数据需创建索引时，原来段不变，选择一个新段存储新增的数据。

l  更新：更新操作时删除和新增的组合，先在.del文件中记录旧数据，在新段中添加一个更新后的记录。

l  删除：当要删除数据时，先在索引文件中新增一个.del文件，专门用来存储被删除的数据id。当查询时，被删除的数据还可以被查到，只是在进行文档链表合并后，才把已经删除的数据过滤掉，被删除的数据在合并时才会被真正被移除。

同时，为控制索引段的数量，会定期进行合并。

ES架构

l  索引分片，实现分布式

l  索引备份，实现高可用

l  API更简单、更高级





ES分片预分配与集群扩容

服务器能够扩容到最大机器数量等于设置的分片数量。

Put /index

{

       “setting”:{

              “number_of_shards”:2,

              “number_of_replicas”:0

}

}

Doris分析案例

技术指标





基于虚拟节点的分区算法

优点：当需要水平扩容时，比较进行线性伸缩。

物理节点扩充



基本访问架构

l  双写保证高可用（写2node，读1node）。

l  基于分区算法查找2个节点

l  数据同步和数据恢复

集群管理-监控检查和配置抓取





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

l  瞬时失效：客户端向服务器写入数据是响应超时，例如：垃圾回收、网络闪断。

l  临时失效：服务器升级或网络暂时不可用；失效机器在短时间内可恢复；恢复后数据和失效前一致。

l  永久失效：机器下线

临时失效处理方式

如果物理节点2临时失效，并可在接受时间内恢复。

物理节点x：备用节点，临时存放失效的物理节点2的数据，物理节点2恢复后，数据迁移回去。

物理节点2失效及恢复期间物理节点1承担所有read操作。

永久失效处理方式

每份数据写2份保证高可用。

关键技术点-扩容实施数据迁移