分布式数据库

数据分片

把一个大量的数据表，分别存储在几个服务器上

如何实现数据分片

  • 硬编码

image.png

  • 映射表

不常使用，因为同样需要大量的数据存储，而且需要二次查询
image.png

  • 分布式数据库中间件

由数据库中间件实现数据分片
image.png

新增数据库服务器怎么做

  1. 先把数据都同步到新的服务器上

image.png

  1. 修改同步策略中的url

image.png

  1. 删除各个服务器上没用的数据库

数据库部署方案

  1. 早期只需要一个数据库

image.png

  1. 读写分离，主从复制，往主服务器写数据，从服务器负责读数据。只提升了读效率。

image.png

  1. 业务分离，每个业务模块进行读写分离。读写效率都增加了一倍。

image.png

  1. 综合部署，数据分片。分片首先要经过业务分离。

image.png

NoSQL

CAP原理

一致性：每次读取的数据都应该是最近写入的数据或者返回一个错误，而不应该过期的数据。
可用性：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的。
分区耐受性：即时因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然是可以操作的。
当网络分区发生时，我们要么取消操作，这是数据是一致的，但系统不可用；要么可以继续写入数据，但数据一致性就得不到保证。

对于分布式系统而言，网络失效是一定会发生的。也就是说，分区耐受性是必须保证的，可用性和一致性只能二选一。

当选择可用性时，系统总会返回数据，但这个数据可能就不是最新的；选择一致性时，系统就可能返回一个错误码，即系统不可用。

关于CAP原理，更准确的描述是，在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。即AP或者CP。

CAP与数据一致性冲突

image.png

最终一致

最终一致性，是当时可能数据不一致，但随着时间的推移，最终会是一致的。NoSql产品提出了『用户一致性』
image.png

保证最终一致性的方案

  1. 按时间戳判断

image.png

  1. 客户端冲突解决，没有的数据添加，已有的数据覆盖

image.png

  1. 投票解决冲突

image.png

Cassandra分布式架构
image.png

HBase 架构

HBase的可用性不是本身实现的，利用的是hdfs的数据复制特性；通过HRegionServer是实现的，Hregion的文件是存储在HFile中，HFile是hadoop的文件，默认是实现了三备份的。

image.png
HBase是高一致性的，可用性较差

HBase的存储使用的是LSM树（Log Structed Merge Tree）

HBase 写数据只写内存，读数据时，首先从内存中查询
越新的数据存放在越低的树节点上，所以新数据查询更快。
删除时不是直接删除，而是在该节点上增加一个删除标记，在写入到硬盘上时（合并数据）才删除
image.png

ACID与BASE

关系型数据库的ACID

A：原子性：事务要么全部完成，要么全部取消。如果事务崩溃，状态要回到事务之间。
C：一致性：只有合法的数据（依照关系约束和函数约束）才能写入数据库中。
I：隔离性：如果两个事务同时运行，两个事务的最终结果应该是相同的，不论T1和T2谁先结束；隔离性主要依靠锁实现。
D：持久性：一旦事务提交，不论发生什么（崩溃或者报错），数据都要保存在数据库中。


NoSql数据库实现的BASE

BA：（Baseically Available）基本可用：当系统在出现不可预知故障的情况下，允许损失部分可用性，如响应时间上的损失或者功能上的损失
S：（Soft state）：弱状态（软状态）：指允许系统中的数据存在中间状态，即允许系统在不同节点进行数据同步时存在延时，且不会影响系统的整体可用性；
E：（Eventually consistent）：最终一致性：指不需要实时保证系统数据的强一致性，而是允许在经过一段时间的同步后，最终能够达到一个一致的状态。

一个实现NoSql系统的案例：Doris

  • 作为架构师，如何打动决策者启动项目
    • 提出问题
      • 现状存在哪些问题
      • 需要实现些什么样的功能
      • 通过什么方案解决现有的问题
      • 需求是迫切的
      • 方案是可行的
    • 能够主动提出问题和解决方案，才有可能主导这个项目，才会有上升的机会
    • 成本及计划
  • 怎样做出系统的特色

分布式一致性

分布式系统脑裂

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

具体场景:
当有多个同一职责的节点共存时，如何判断某个节点是否是活动的？
通过另外的某个仲裁决定

zookeeper解决的是，简化分布式应用开发中多进程协作的问题，保证一致性

分布式一致性算法：Paxos

早期用来讨论分布式系统中的锁应该如何获得；

三个角色：

  • Proposer：
    • 1.1 发起提案（比如发起一个对资源的锁），向Acceptor发去Prepare请求
    • 1.3 Proposer收到多数Acceptors的Promise后，向Acceptor发出Propose请求；
    • 1.5 Proposer收到多数Acceptors的Accept后，表示本次Accept成功，决议形成，将决议发送给所有Learners
  • Acceptor：
    • 1.2 针对收到的Prepare请求进行Promise承诺；
    • 1.4 Acceptor针对收到的Propose请求进行Accept处理
  • Learner

分阶段：

  • 第一阶段：Prepare阶段，包括1.1和1.2
  • 第二阶段：Accept阶段，包括1.3和1.4
  • 第三阶段：Learn阶段，包括1.5

image.png

zookeeper架构

zookeeper使用的是自定义的Zab协议

image.png

image.png

image.png

zookeeper开放了哪些API

扩展

HBASE的实现原理
LSM和B+树的区别
hdfs

zab协议的具体实现
Leader的选举
zookeeper开放了哪些API

学习一个框架或者技术，不止是学会用，而是要学会自己实现。

架构师要经得起质疑，质疑者的层次越高越好。

专业的东西都是反常识的。

不要太忙，不然没有时间思考