Zookeeper 与 Kafka (1) : 分布式一致性原理
作者:
沪上最强亚巴顿 | 来源:发表于
2015-11-11 18:46 被阅读2520次
- 多线程的最大副作用:
并发.
- 如果多个逻辑控制流在时间上发生了重叠, 就会产生并发.
- 逻辑控制流是指一次程序操作.
- 如读取或者更新内存变量的值.
-
更新的并发性: 多线程同时更新内存值而产生的并发.
- 分布式一致性
- 目标:
- 增加系统可用性, 防止因单点故障引起的系统不可用.
- 提高系统的整体性能, 通过负载均衡, 让分布在不同地方的数据副本都能为用户提供服务.
- 缺陷:
- 为了解决复制延迟, 阻塞写入动作直到所有的复制完成, 会严重影响写入的性能.
- 在不影响系统运行性能前提下,保证数据一致性是不可能的.
- 一致性的级别:
-
强一致性. 最好的用户体验, 但是会影响性能.
-
弱一致性. 尽可能快地但不保证数据一致状态.
- 最终一致性. 保证一定时间内,达到数据一致状态.
- 分布式架构
- 常见问题
- 通信异常,节点故障.
-
网络分区:
- 部分节点的网络延迟过大, 导致只有部分节点间能够正常通信的现象.
- 请求与响应的
三态: 成功,失败,超时.
- ACID.
- Atomicity: 事务中的所有操作只能全部执行或者全部不执行.
- Consistency: 事务的执行不能破坏�数据库中数据的完整性和一致性.
- 当�数据库在一些事务尚未完成时发生故障, 会导致部分修改写入, 而处于不一致状态.
- Isolation: 并发环境中,事物相互隔离.
- Read Uncommitted.允许脏读.
- Read Committed. 允许不可重复读(一次事物多次读取相同值时, 原始读取不可重复).
- Repeatable Read(锁定�行). 事务过程中多次读取同一数据,其值和开始时是一致的. 可能有幻影数据(锁定�行范围).
- Serializable. 所有事务串行执行,不�支持并发.
- Durability: 事务成功结束后,其对�数据库的更新要被永久保存下来.
- 分布式事务
- 由多个分布式的操作(子事务)序列组成, 嵌套型的事务. 需要兼顾可用性和一致性.
- CAP. 最多只能同时满足其中的两项. 分区容错性是必须的,平衡的是Consistency和Availability.
- Consistency. 数据在多个�副本间的一致性.
- Availability. 用户的每个请求总能在有限的时间内返回结果.
- Partition tolerance. 遇到任何网络分区(子网络)故障时,对外提供满足一致性和可用性的服务.除非整个网络故障.
- BASE 理论.
既然无法达到�强一致性, 那么采用适当的方式来达到最终一致性.
- Basically Available. 出现不可预知的故障时, 允许损失部分可用性.
- Soft state. 允许系统中的数据存在中间状态.
- Eventually Consistent. 它包含五种变种:
- Causal consistency. 更新进程完成后通知进程B,进程B拿到的是更新后的数据.
- Read your writes. 进程更新数据后,自己总是能读取到更新过的新值.
- Session consistency. 在同一会话中实现
read your writes的一致性.
- Monotonic read consistency. 进程读取某数据项后,后续的数据访问不能返回旧值.
- Monotonic write consistency. 保证来自同一进程的写操作顺序地执行.
- 核心:
牺牲强一致性来获得可用性.
- 一致性协议
- 跨越多个分布式节点的事务操作,需引入协调器(Coordinator)来调度,节点称为参与者(Participant).
- Coordinator 调度Participan t的行为, 并最终决定是否要把事务真正进行�提交.
- 两阶段提交协议(2PC, Two-Phase Commit).
- 关系型�数据库的通用做法, 属于强一致性算法.
- 阶段:
- 提交事务请求(投票); 要么返回失败,要么本地执行事务,写本地的redo/undo日志,但不提交.
- 执行事务提交(执行).
- 采用先尝试后提交的方式.
- 缺点:
- 同步阻塞(participant 会一直等待它人的响应/ 或participant 占用公共资源时);
- 单点问题(coordinator);
- 数据不一致性(阶段二如果有节点没有收到提交消息时, coordinator 就宕机时);
- 太过保守(coordinate 只能依靠超时来处理长时间无响应的participant).
- 当coordinator 发送了commit 后宕机, 且唯一接收到commit 消息的participant 也宕机后, 重新选举的coordinator 也无法知晓是否应该commit.
- 三阶段提交协议(3PC)
- 阶段:
- CanCommit, PreCommit, Do Commit.
- participant 在PreCommit 阶段执行事务操作,并将Undo 和Redo 信息记录到事务log 中.
- 改动点:
- 在协调者和参与者之间引入超时机制.
- 新插入的准备阶段, 保证了在最后提交阶段之前, 各参与节点的状态是一致的.
- 缺点:
- 进入Do commit阶段,参与者在等待(协调者的提交/中断指令)超时后,会继续进行事务提交. 可能导致数据的不一致性.
- 优势:
- 降低了参与者的阻塞范围, 且在单点故障后继续达成一致性.
本文标题：Zookeeper 与 Kafka (1) : 分布式一致性原理
本文链接：https://www.haomeiwen.com/subject/epkhhttx.html
网友评论