写点什么

第六周学习心得

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

本周主要学习

  1. 分布式关系数据库

  2. CAP 原理与 NoSQL 数据库架构

  3. 分布式一致 ZooKeeper

  4. 搜索引擎的基本架构

  5. Doris 案例分析

1.分布式关系数据库

1.1MySQL 复制

  • 分摊负载

  • 专机专用

  • 便于冷备

  • 高可用

1.2 数据分片

  • 分片目标

  • 分片特点

  • 分片原理

1.3 分布式数据库中间件

  • Cobar 架构

  • Cobar 系统组件模型

1.4 如何做集群的伸缩

  • 数据库部署方案- 单一服务与单一数据库

  • 数据库部署方案– 主从复制实现伸缩

  • 数据库部署方案-两个 Web 服务及两个数据库

  • 数据库部署方案– 综合部署

2.CAP 原理与 NoSQL 数据库架构

2.1CAP 概念

  • C:Consistency,一致性是说,每次读取的数据都应该是最近写入的数据或者返回一个错误(Every read receives the most recent write or an error),而不是过期数据,也就是说,数据是一致的。

  • A:Availability,可用性是说,每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证数据是最近写入的(Every request receives a (non-error)response, without the guarantee that it contains the most recent write),也就是说系统需要一直都是可以正常使用的,不会引起调用者的异常,但是并不保证响应的数据是最新的。

  • P:Partiton tolerance,分区耐受性说,即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的(The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes)。

2.2 CAP 原理

  • 当网络分区失效发生的时候,我们要么取消操作,这样数据就是一致的,但是系统却不可用;要么我们继续写入数据,但是数据的一致性就得不到保证。

  • 对于一个分布式系统而言,网络失效一定会发生,也就是说,分区耐受性是必须要保证的,那么在可用性和一致性上就必须二选一。

  • 当网络分区失效,也就是网络不可用的时候,如果选择了一致性,系统就可能返回一个错误码或者干脆超时,即系统不可用。如果选择了可用性,那么系统总是可以返回一个数据,但是并不能保证这个数据是最新的。

  • 所以,关于 CAP 原理,更准确的说法是,在分布式系统必须要满足分区耐受性的前提下,可用性和一致性无法同时满足。

2.3NoSQL 数据库架构

  • Cassandra 分布式架构

  • Hbase 架构

  • Log Structed Merge Tree(LSM 树)

3.分布式一致 ZooKeeper

3.1 分布式系统脑裂

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

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

3.2 分布式一致性算法 Paxos

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

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

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

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

Acceptors 收到 Prepare 和 Propose 请求后

  1. 不再接受 Proposal ID 小于等于当前请求的 Prepare 请求。

  2. 不再接受 Proposal ID 小于当前请求的 Propose 请求。

4.搜索引擎的基本架构

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

  • 爬虫系统架构

  • 文档矩阵与倒排索引

  • Lucene 架构

  • ElasticSearch 架构

5.Doris – 海量 KV Engine

学习具体的产品开发案例 Doris,及方案结构

  1. 当前现状

  2. 产品需求

  3. 产品目标

  4. 技术指标

  5. 逻辑架构

  6. KV Storage 概念模型

  7. 关键技术点

  8. 数据分区

  9. 基于虚拟节点的分区算法

  10. 可用性关键场景

  11. 临时失效的 fail over

  12. 永久失效 failover

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

  14. 产品规划

  15. 研发计划-功能需求

  16. 研发计划

  17. 项目计划

  18. 实施计划


用户头像

熊桂平

关注

还未添加个人签名 2020.09.14 加入

还未添加个人简介

评论

发布
暂无评论
第六周学习心得