第六周总结

用户头像
Geek_ac4080
关注
发布于: 2020 年 11 月 01 日

分布式关系数据库原理

mysql主从复制

  1. 主服务器上面的任何修改都会通过自己的 I/O tread(I/O 线程)保存在二进制日志 Binary log 里面。

  2. 从服务器上面也启动一个 I/O thread,通过配置好的用户名和密码, 连接到主服务器上面请求读取二进制日志,然后把读取到的二进制日志写到本地的一个Realy log(中继日志)里面。

  3. 从服务器上面同时开启一个 SQL thread 定时检查 Realy log(这个文件也是二进制的),如果发现有更新立即把更新的内容在本机的数据库上面执行一遍。

mysql主主复制

同步数据的过程同主从复制类似,主主复制两台数据库服务器都是主服务器,都可以进行读写操作,但同一时刻只能有一台服务器对外提供写服务,如果两台同时写操作会产生数据冲突。当一台主服务器失效时会切换到另外一台主服务器上

mysql复制注意事项

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

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

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

数据分片

  • 硬编码实现分片:对请求进行硬编码路由,分别指向不同数据库服务器

  • 映射表分片:通过外部映射表配置请求路由路径

数据分片缺点

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

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

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

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

CAP原理

  • 一致性:写操作之后的读操作,必须返回该值

  • 可用性:只要收到用户的请求,服务器就必须给出回应,而不是返回一个错误或者失去响应,但是并不保证响应的数据是新的

  • 分区耐受性:大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。分区容错的意思是,区间通信可能失败

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

zookeeper与分布式一致性架构

ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅负载均衡命名服务分布式协调/通知集群管理Master 选举分布式锁分布式队列等功能。

分布式一致性算法Paxos

三个角色:Proposer , Acceptor ,Learner

  1. 第一阶段:Prepare阶段。Proposer向Acceptors发出Prepare请求,Acceptors针对 收到的Prepare请求进行Promise承诺。

  2. 第二阶段:Accept阶段。Proposer收到多数Acceptors承诺的Promise后,向 Acceptors发出Propose请求,Acceptors针对收到的Propose请求进行Accept处理。

  3. 第三阶段:Learn阶段。Proposer在收到多数Acceptors的Accept之后,标志着本次 Accept成功,决议形成,将形成的决议发送给所有Learners

Zab协议

  1. 所有的事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器被叫做 Leader服务器。其他剩余的服务器则是 Follower服务器

  2. Leader服务器 负责将一个客户端事务请求,转换成一个 事务Proposal,并将该 Proposal 分发给集群中所有的 Follower 服务器,也就是向所有 Follower 节点发送数据广播请求(或数据复制)

  3. 分发之后Leader服务器需要等待所有Follower服务器的反馈(Ack请求),在Zab协议中,只要超过半数的Follower服务器进行了正确的反馈后(也就是收到半数以上的Follower的Ack请求),那么 Leader 就会再次向所有的 Follower服务器发送 Commit 消息,要求其将上一个 事务proposal 进行提交



Zab协议要求每个 Leader 都要经历三个阶段:发现,同步,广播

  • 发现:要求zookeeper集群必须选举出一个 Leader 进程,同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。

  • 同步:Leader 要负责将本身的数据与 Follower 完成同步,做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后,写入本地事务日志中。

  • 广播:Leader 可以接受客户端新的事务Proposal请求,将新的Proposal请求广播给所有的 Follower

搜索引擎的基本架构

单词和单词字典:搜索引擎的通常索引单位是单词,单词词典是由文档集合中出现过的所有单词构成的字符串集合,单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。

倒排列表:倒排列表记载了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息,每条记录称为一个倒排项(Posting)。根据倒排列表,即可获知哪些文档包含某个单词。

倒排文件:所有单词的倒排列表往往顺序地存储在磁盘的某个文件里,这个文件即被称之为倒排文件,倒排文件是存储倒排索引的物理文件



用户在搜索引擎搜索框输入查询词进行搜索时,搜索引擎会对查询词进行切词以及近义词匹配等操作,根据原始查询词得到一系列的单词列表。然后根据搜索引擎内部的字典来查询每个单词对应的倒排列表,从而定位到包含这个单词的网页或者说是文档。最后搜索引擎根据特定的网页排序算法将查询到的网页进行排序,通过前端将搜索结果展示给用户



用户头像

Geek_ac4080

关注

还未添加个人签名 2019.05.09 加入

还未添加个人简介

评论

发布
暂无评论
第六周总结