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

妖狐艹你老母 2022-07-15 03:20 168阅读 0赞

http://www.jianshu.com/p/fcc28b195fa9

*  多线程的最大副作用: `并发`.
    
     *  如果多个逻辑控制流在时间上发生了重叠, 就会产生并发.
     *  逻辑控制流是指一次程序操作.
        
         *  如读取或者更新内存变量的值.
         *  `更新的并发性`: 多线程同时更新内存值而产生的并发.
 *  分布式一致性
    
     *  目标:
        
         *  增加系统可用性, 防止因单点故障引起的系统不可用.
         *  提高系统的整体性能, 通过负载均衡, 让分布在不同地方的数据副本都能为用户提供服务.
     *  缺陷:
        
         *  为了解决复制延迟, 阻塞写入动作直到所有的复制完成, 会严重影响写入的性能.
         *  在不影响系统运行性能前提下,保证数据一致性是不可能的.
         *  一致性的级别:
            
             *  `强一致性`. 最好的用户体验, 但是会影响性能.
             *  `弱一致性`. 尽可能快地但不保证数据一致状态.
                
                 *  分为会话一致性和用户一致性.
             *  最终一致性. 保证一定时间内,达到数据一致状态.
                
                 *  属于弱一致性的特例. 是目前最被广泛接收的.
 *  分布式架构
    
     *  常见问题
        
         *  通信异常,节点故障.
         *  `网络分区`:
            
             *  部分节点的网络延迟过大, 导致只有部分节点间能够正常通信的现象.
         *  请求与响应的`三态`: 成功,失败,超时.
     *  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).
        
         *  关系型数据库的通用做法, 属于强一致性算法.
         *  阶段: 提交事务请求(投票); 执行事务提交(执行).
            
             *  采用先尝试后提交的方式.
         *  缺点:
            
            1.  同步阻塞(participant 会一直等待它人的响应);
            2.  单点问题(coordinator);
            3.  数据不一致性(阶段二如果有节点没有收到提交消息时);
            4.  太过保守(coordinate 只能依靠超时来处理长时间无响应的participant).
     *  三阶段提交协议(3PC)
        
         *  阶段:
            
             *  CanCommit, PreCommit, Do Commit.
             *  participant 在PreCommit 阶段执行事务操作,并将Undo 和Redo 信息记录到事务log 中.
         *  缺点:
            
             *  进入Do commit阶段,参与者在等待(协调者的提交/中断指令)超时后,会继续进行事务提交. 可能导致数据的不一致性.
         *  优势:
            
             *  降低了参与者的阻塞范围, 且在单点故障后继续达成一致性.
    
      
      
    
    
    文／沪上最强亚巴顿（简书作者）  
    原文链接：http://www.jianshu.com/p/fcc28b195fa9  
    著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。