• 欢迎访问蜷缩的蜗牛博客 蜷缩的蜗牛
  • 微信搜索: 蜷缩的蜗牛 | 联系站长 kbsonlong@qq.com
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Zookeeper 与 Kafka (1) : 分布式一致性原理与实践

Zookeeper 蜷缩的蜗牛 3个月前 (07-03) 14次浏览 已收录
  1. 多线程的最大副作用: 并发.
  • 如果多个逻辑控制流在时间上发生了重叠, 就会产生并发.
  • 逻辑控制流是指一次程序操作.
    • 如读取或者更新内存变量的值.
    • 更新的并发性: 多线程同时更新内存值而产生的并发.
  • 分布式一致性
    • 目标:
      • 增加系统可用性, 防止因单点故障引起的系统不可用.
      • 提高系统的整体性能, 通过负载均衡, 让分布在不同地方的数据副本都能为用户提供服务.
    • 缺陷:
      • 为了解决复制延迟, 阻塞写入动作直到所有的复制完成, 会严重影响写入的性能.
      • 在不影响系统运行性能前提下,保证数据一致性是不可能的.
      • 一致性的级别:
        • 强一致性. 最好的用户体验, 但是会影响性能.
        • 弱一致性. 尽可能快地但不保证数据一致状态.

          • 分为会话一致性和用户一致性.
        • 最终一致性. 保证一定时间内,达到数据一致状态.
          • 属于弱一致性的特例. 是目前最被广泛接收的.
  • 分布式架构
    • 常见问题
      • 通信异常,节点故障.
      • 网络分区:

        • 部分节点的网络延迟过大, 导致只有部分节点间能够正常通信的现象.
      • 请求与响应的三态: 成功,失败,超时.
    • 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 日志,但不提交.
        • 执行事务提交(执行).
        • 采用先尝试后提交的方式.
      • 缺点:
        1. 同步阻塞(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) : 分布式一致性原理与实践


蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明Zookeeper 与 Kafka (1) : 分布式一致性原理与实践
喜欢 (0)
[]
分享 (0)