分布式相关

1、问：why分布式锁，以及how？

     曰：比如，我们有如果是单台机器，并发来了怎么搞？我们有很多处理高并发的方法手段，例如synchronized、retrentlock、courrentMap、synchronizeHashMap等等，来防止高并发，这个是合理的。但是这只能针对一台机器，如果有一个方法，每次只允许一个访问，那么synchronized也可以出现两次。所以，单机锁没有用了，需要分布式锁。

如何获得分布式锁呢：1、数据库的方法，获得一个锁就增加一条记录，释放锁就删除记录。2、缓存，redis memercache都可以。3、zk。目前用2比较溜。

 

借助zk理解分布式系统相关，参考《从paxos到zk分布式一致性原理与实践》

Part I - C1：单机-分布式系统所面临的问题

Part II - C2-C4：分布式一致性协议

Part IV - C7：ZK原理与架构设计

Part I - C1：单机-分布式系统所面临的问题

    IBM制造的System/360系列大型机为集中式结构框架起到了很大的推广作用。大型机太贵了，所以阿里08年开始推行的去IOE活动，推动了电商分布式系统的发展。既然是分布式的系统，那么节点之间可没有主从之分，但是有副本的概念，就是一个数据或服务的冗余。

    分布式系统缺乏一个全局时钟。网络故障会带来问题。

    事务也相应发生了变化：ACID----CAP/BASE

    Atomic/Consistency/Isolation/Durability

        原子性：事务要么都执行，要么都不执行

        一致性：事务如果执行了一部分，另一部分没有写入物理库，就称为破坏了一致性

        隔离性：读未提交、读已提交、重复读、串行读

        持久性：一旦submit，状态就固定了，就算机器down了，恢复也是submit之后的状态。

    Consistency/Avaliable/Partition tolerance(分区容错性)

        一致性：分布式环境的一致性指的是“数据在多个副本之间保持一致性”

        可用性：系统能在一定的时间能返回结果。

        分区容错性：分布式系统存在的核心意义，一个部分down了，其他部分可以顶起来。

    Base Avaliable/ Soft status/ Eventually consistency

        基本可用：当系统出现了问题的时候，对系统进行降级，允许损失部分可用性(同上，两个方面)。

        软状态：副本之间的状态，同步可以不实时，允许存在时延。

        最终一致性：经过一段时间之后，达到一致性。（由软状态促进）整个BASE比CAP柔和了许多。

    比如数据库的主备同步的时候，就是采取的“最终一致性”，依赖读取Binlog进行同步，而不是主备都写成功了才算Durability成功；所以有时候代码里面，需要强制读取主库才行。

Part II - C2-C4：分布式一致性协议 2PC/3PC/Paxos

    分布式系统提交事务的时候，A节点并不知道其他节点提交是否成功了，所以A提交事务的时候就会比较忐忑。因此分布式系统 同步数据的时候需要有个协调者(Coordinator)，其他的节点称之为参与者(Participant)。Coordinator负责协调Participant，决定Participant是否要进行事务的提交。

    2PC：

        1、提交事务请求

        Coordinator发放事务请求，Participant判断是否可以进行事务处理、执行事务操作、写入Undo Redo日志、返回给Coordinator Yes or No

        2、Coordinator根据Yes or No进行判断，向Participant发送commit  or rollback命令。

        完成。

        优点：简单、容易实现

        缺点：1、同步阻塞：所有节点在第一步骤之后，只能等待，不能进行其他处理；2、单点问题：Coordinator在第一步之后挂了，其他节点都会处于阻塞状态；3、数据不一致(脑裂)：第二步ing Coordinator挂了，或者第二步之后，某些节点网络挂了，导致节点之间数据不一致。4、太过保守：任意节点失败导致整个系统的事务失败。

    3PC：

        1、CanCommit：类似于2PC的第一步前面部分，是否可以进行事务处理

        2、PreCommit：2PC的第一步后面的部分，通知各节点进行事务执行，写入Undo Redo 日志；Coordinator根据Participant返回的结果通知各节点准备提交或者中断事务。

        3、DoCommit：Coordinator向Participant发送cimmit or rollback。

        相对于2PC更麻烦一点，也没有解决实际问题。

    Paxos协议

        核心点是，过半

        应用一：Chubyy分布式锁服务，使用Paxos协议确定Master是哪一台机器，其他机器使用Paxos协议从Master同步数据(即：master使用Paxos进行广播)。

        应用二：Hypertable类似于HBase的分布式存储

        应用三：产品：Zookeeper，协议：ZAB：Zookeeper Atomic Broadcast。zookeeper是一个典型的分布式数据一致性解决方案，应用程序基于其可实现诸如，发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁、分布式队列等功能

        zk数据模型类似于一个文件系统，但是数据都存储在内存中，以实现高吞吐、低延迟目的。

        角色：Leader提供读写，Follower提供读及参与Leader选举，Observer读。

        ZAB是在paxos基础上，为zk专门设计的数据一致性算法，主要是为了支持奔溃恢复和原子广播。奔溃恢复，看起来就是Master挂了之后，Lollowers进行选举，过半同意的那个称为新的Master，剩余的Followers与Master进行数据同步。

PartIII C6：应用场景

    1、数据发布与订阅(类似disconf)

        在zk中选择一个数据节点，配置上我们需要的数据，客户端在这个数据节点上注册一个watch事件，所有订阅了的客户端都可以收到变更通知，当数据变化了之后，节点会给客户端推送一个通知，客户端再来拉取最新的数据。ZK有API接口！

    2、负载均衡

        没看懂

    3、命名服务

        分布式项目中，只需要知道名字就可以对对象进行操作，避免了IP地址等细节处理。客户端根据名字获得实体服务的地址、资源等。与java里面的JNDI(Java Naming and Directory Interface)异曲同工。但是，广义上的命名，并不只是命名而已，比如获得一个全局的唯一id，也是命名。就可以通过zk的znode来获得。在zk中每一个数据节点都会维护一份子节点的顺序序列，客户端每创建一个子节点，都会在这个数据节点后面添加一个序号。

        另外，uuid32位乱序字符+4位短横杠，除了唯一性没有任何额外的意义。

    4、分布式协调/通知

        在zk中创建临时节点等。这里可以用来：节点存在即表示存活(心跳)；

    5、集群管理

        也是通过在zk中注册节点

    6、Master选举

        6.1利用数据库。各个节点向数据库插入一个unique的唯一值，插入成功了则为Master，失败了则为Slave。但是如果Master挂了，那就是挂了，并不会通知Slave们。

        6.2利用zk。而zk，其他点创建Master失败之后，会在zk上注册一个watch，master 挂了之后zk会通知Slave们，进行Master选举来。

    7、分布式锁

        在zk中注册一个临时节点，成功则为获得锁，失败则为没有获得锁，同时会注册watch事件。但是在获得锁之后要释放锁。zk也会用心跳检测获得锁的节点，如果节点挂了，就释放了临时节点，其他注册了watch事件的应用节点就可以在zk通知后，获得注册临时节点的机会了。

        redis好像没有自动释放key的方法？万一节点挂了，岂不是尴尬了？

Part IV - C7：ZK原理与架构设计

额。。。安定下来再细看