Week_06 总结 + 作业

分布式关系数据库

mysql 一主多从，主从复制

• 完成读数据的高可用

• 分摊负载

• 便于冷备

mysql 写入的 高可用

• 主主复制（双主不能同时写）

失效维护过程（通过配置 mycat 进行失效检测与失效迁移

• balance="1": 全部的 readHost 与 stand by writeHost 参与 select 语句的负载均衡。

• writeType="0": 所有写操作发送到配置的第一个 writeHost，第一个挂了切到还生存的第二个 writeHost，重新启动后以切换后的为准，切换记录在配置文件中:dnindex.properties 。

• switchType="1": 1 默认值，自动切换。）

1. 检测到失效

2. 失效转移：写操作发送的另一台主服务器，读操作发送到另一台的从服务器上

3. 重建失效的主服务器和其从服务器

4. 恢复完成

mysql 复制注意事项

• 主主复制不能并发写入

• 复制着增加了读并发能力，未增加写并发能力和存储能力

• 更新表结构会有巨大的同步延时（关闭表结构同步操作，更新表结构，用人工的方式进行）

mysql 提升写并发能力和存储能力

通过数据分片提升写并发能力和存储能力

• 分片目标

• 硬编码分片：

• 应用代码中根据 id 特征进行服务器映射；

• 增加服务器映射表

• 存在的问题：

1. 处理逻辑复杂

2. 进行分片联合查询时，很难执行

3. 用不成数据库的事务

4. 数据扩容时，数据迁移与代码变更复杂

• 分布式数据库中间件

• mycat

• cobra

• 其他

• 分片特点

• 分片原理

• 分片路由配置

• hash 取模

• 数据库的伸缩策略

• 分片之前预先设置较大模数，每个服务器上均衡启动多个 mysql 实例（指 schema）。路由配置时配置相应的 hash 规则

• 数据库扩容需要扩容时，从不同的服务器上选出一些 mysql 实例（指 schema），新服务器启动后，以主从的方式，将各个服务器上选出来的这些 schema 复制到新服务器上，然后更改 mycat 中 schema 对应的 ip，即完成扩容

分布式关系数据库部署方案

• 单服务单数据库

单服务器的伸缩通过主从复制实现

• 两服务两数据库

单服务单数据库需要进行进一步的伸缩时，采用分库的方式，根据不同业务功能进行数据库的拆分

• 综合部署

业务数据库写入压力大，单一数据库跟不上，此时进行分片操作

分布式 NOSql 数据库

cap 原理（作业一）

一致性 Consistency

每次读数据，要么最新的，要么读不到返错误。数据是一致的

可用性 Availability

客户端的请求，总是能获取响应，而不是获取到错误或者根本没有响应。响应对应的数据不保证是最新的

分区耐受性 Partition tolerance

网络原因，导致服务器节点间消息丢失或者延时，这种情况下，系统依旧可以操作

对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证

的，那么在可用性和一致性上就必须二选一。

当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个

错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个

数据，但是并不能保证这个数据是最新的。

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

数据一致性冲突

最终一致性

最终一致性写冲突

最终一致性冲突解决方案

• 根据时间戳，进行写入覆盖

• 客户端获取数据集合，进行冲突解决

• 投票解决

cassandra 分布式架构

写入：根据行 key 进行分区计算，获取写入节点，根据配置策略，写入两节点成功，则认为成功

读取：根据行 key 进行分区计算，获取读取节点，根据配置策略，读取到数据不一致时，会进行投票，选择多数进行返回，cassandra 同时还会进行读修复，将不一致的节点数据进行修复

Hbase 架构

Hbase 存储用的是 Hadoop。Hmaster 是元数据服务，部署有多个实例，通过 zookeeper 提供一个主服务。HRegionServer 是数据服务，每个数据服务内部又进行了逻辑分组，分为多个 HRegion 提供数据存储能力。

当客户端进行数据访问时，先通过 zookeeper 获取主元数据服务，然后向其查询 HRegionServer 的地址，然后访问数据服务，获取具体的 HRegion，最后找的数据的存放位置。

Hbase 是以 LSM 树方式进行存储的，与之对应的是关系数据库的 b+tree。b+tree 是随机进行读写操作的，LSM 是顺序进行写入的.

传统数据库与 NOSql 对比

• ACID

• 原子性(atomicity)：事务操作要么全部完成，要么全部取消。失败时要进行事务回滚

• 隔离性(isolation)：多个事务同时运行，最终结果是一致的，不论哪个事务先结束

• 持久性(durability)：一旦提交，数据就要保存到数据库

• 一致性(consistency)：只有合法的数据才能写入库中

• BASE

• 基本可用(Basically Available)：系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。

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

• Eventually consistent（最终一致性）：需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性架构

分布式一致 ZooKeeper

分布式系统的问题

在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个

集群陷入混乱，数据损坏，本称作分布式系统脑裂。

分布式一致性算法 Paxos

zab 协议

zookeeper 数据的记录

• 以树状结构进行数据记录

• zookeeper 的 api

String create(path, data, acl, flags)

void delete(path, expectedVersion)

Stat setData(path, data, expectedVersion)

(data, Stat) getData(path, watch)

Stat exists(path, watch)

String[] getChildren(path, watch)

void sync(path)

List multi(ops)

zookeeper 的选主

1. 从 zookeeper 上获取当前主

2. 没有时进行 create，自举为主。多个 follow 进行自举时，通过选举投票选择一个出来，create 只有一个能成功.

zookeeper 的集群管理（负载均衡与失效转移）

• 监控进程通过调用 getChildren 接口，监控 nodes 目录。当需要进行负载均衡时，根据当前集群情况进行负载分发。

• 当出现节点故障时，通过 watch 可以知道哪个节点有问题，哪个节点没问题，进而进行失效转移

zookeeper 性能

• 读多写少，zookeeper 集群越大，读性能越好。

• 读占比大于 80%时，每秒请求数能达到 > 60000。

• 读占比小于 20%时，每秒请求数 < 25000.

搜索引擎

通用架构

文档矩阵与倒排索引

带词频与位置的倒排索引

lucence 架构

对数据源进行分词，构建倒排索引。查询时，经过分词器进行分词，然后查找倒排索引，获取结果，最后对结果进行排序等处理，返回结果。

lucence 索引文件准实时更新

• 索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大时效率很低，并且由于创建一次索引的成本很高，性能也很差。

• Lucene 引入了段的概念，将索引文件拆分为多个子文件，每个子文件对应一个段，每个段都是一个独立可搜索的数据集，索引的修改是针对段进行的。

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

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

• 更新：更新的操作其实就是删除和新增的组合，先在.del 文件中记录旧数据，再在新段中添加一条更新后的数据。

• 段多了，就需要进行控制，定期进行段合并

• luncne 不提供高可用，搜索引擎的高可用是通过 elasticsearch 实现的

elasticsearch 架构

es 是数据的分配与扩容

• 建索引时，就需要指定分片数

• 分片是预分配的，服务器数等于分片数时，无法再进行扩容

• 副本指的是分片的副本

NoSql 案例：Doris

Doris 案例分析

Doris 架构

基于虚拟节点的分区算法

实现虚拟节点对物理节点的映射关系

Doris 高可用与扩容

高可用设计

• 数据服务进行分组，分为 primary 和 secondary

• 写入时，按分组进行双写（可配置），确保写必须成功。

• 读的时候只需读一个分组就 ok,因为写保证了一致

• 如果写的时候，发现一个写成功，另一个写失败，此时如何保证可用性？

当写入失败时，client 会向 configserver 进行数据节点的状态报告，由 configServer 进行确认数据节点是否真正失效。配置服务进行该数据的写入，失败则认为该节点失效了

• 瞬时失效

• 网络闪断

• 超时丢包

• 垃圾回收

策略：重试

• 临时失效

• 网络不可用，服务器升级

• 失效机器在短时间内可恢复

• 恢复后数据一致

策略：选择备份节点，进行备份写，但备份写，只记录写日志，即 redolog。当临时失效节点恢复后，在该节点上执行 redo 操作，恢复数据。失效期间的由未失效的节点承担所有读操作。

• 永久失效

• 机器下线

策略：当永久失效发生时，从备用服务器中选择一个，代替失效的节点。先将数据文件进行 copy，然后在新节点上执行临时失效期间的 redolog，保证数据的完整。

扩容伸缩设计