zookeeper notes --curator Distributed Lock

Some tools in the distributed lock Curator framework
InterProcessMutex: Distributed exclusive lock reentrant

InterProcessSemaphoreMutex: Distributed exclusive lock

InterProcessReadWriteLock: Distributed read-write locks

 

 

Code:

Use Zookeeper realization leader election

All nodes Leader Latch participate in the elections, will create a sequence of nodes, the smallest node is set to master node, did not grab delete events before Leader of the node listens for a node, grab re-master after the previous node removed, when the master node calls manually close () method or a master node hung up, a subsequent sub-master node will seize. Spark which uses this method

LeaderSelector

LeaderSelector and Leader Latch most difference is that, leader leadership can be released later, you can continue to compete

 

public class LeaderSelectorClient extends LeaderSelectorListenerAdapter implements Closeable {

    private  String name;  //表示当前的进程
    private  LeaderSelector leaderSelector;  //leader选举的API
    private CountDownLatch countDownLatch=new CountDownLatch(1);

    public LeaderSelectorClient(){

    }

    public LeaderSelectorClient(String name) {
        this.name = name;
    }

    public LeaderSelector getLeaderSelector() {
        return leaderSelector;
    } 

    Public  void setLeaderSelector (LeaderSelector leaderSelector) {
         the this .leaderSelector = leaderSelector; 
    } 

    public  void Start () { 
        leaderSelector.start (); // start competition Leader 
    } 

    @Override 
    public  void takeLeadership (CuratorFramework Client) throws Exception {
         // if the incoming the current method, which means the current process to obtain a lock. After acquiring the lock, this method is the callback
         // After the implementation of this method, shows the release rights leader 
        System.out.println (name + "-> is now the leader" );
 //         CountDownLatch.await (); // blocks the current the process prevents the loss leader
     }

    @Override
    public void close() throws IOException {
        leaderSelector.close();
    }
    private static String CONNECTION_STR="x.x.x.x:2181;

    public static void main(String[] args) throws IOException {
        CuratorFramework curatorFramework = CuratorFrameworkFactory.builder().
                connectString(CONNECTION_STR).sessionTimeoutMs(50000000).
                retryPolicy(new ExponentialBackoffRetry(1000, 3)).build();
        curatorFramework.start();
        LeaderSelectorClient leaderSelectorClient=new LeaderSelectorClient("ClientA");
        LeaderSelector leaderSelector=new LeaderSelector(curatorFramework,"/leader",leaderSelectorClient);
        leaderSelectorClient.setLeaderSelector(leaderSelector);
        leaderSelectorClient.start(); //开始选举
        System.in.read();
    }
}

 

---

zab agreement Introduction

ZAB protocol includes two basic modes,

2. 1. Crash Recovery are broadcast atoms

When the entire cluster at startup, or when the leader node of a network outage occurs, the situation crashes, ZAB agreement will enter recovery mode and elected the new Leader, when the leader elected by the server, and cluster machines and more than half of the after the leader node completes data synchronization (sync data synchronization means is used to ensure that half of the cluster and the data be consistent machine state leader server), ZAB protocol exits the recovery mode. When the cluster node has completed more than half of Follower and Leader after synchronization status, then the whole cluster entered the news broadcast mode. This time, when the Leader node is working properly, start a new server to the cluster, it will go directly to the server data recovery mode, data synchronization and leader node. It can normally provide external handle non-transaction requests after the synchronization is complete. Note that: leader node can handle non-transaction requests and transaction requests, follower node can handle only non-transactional request, if the follower node receives a non-transactional request, it will forward the request to the server Leader

 

The principle message broadcasting

 

 

 

If we understand the distributed transaction 2pc and 3pc agreement, then (do not understand it does not matter, we'll talk about later), the message broadcast process is actually a simplified version of the two-phase commit process 1. leader receives a message request, the message assigned a globally unique 64-bit increment id, call: zxid, zxid compare the size of both the cause and effect can be achieved by this feature 2. leader ordered for each follower prepared a FIFO queue (implemented by the TCP protocol, in order to achieve the this is a global news and orderly features) will be with zxid as a proposal (proposal) distributed to all of the follower 3. when the follower receives a proposal, first proposal written to disk, leader again after the written reply to a successful ack 4 when the ACK leader receiving the valid number (more than half of nodes), Leader will, simultaneously executes the message locally to the follower 5. when sending the commit command to commit follower received command message, which will be submitted to eliminate

 

 

 

 

About ZXID

Has been mentioned earlier zxid, that is, the transaction id, id then this particular what role and how this id is generated, a simple explanation in order to ensure for everyone under the order of transactional consistency, zookeeper using increasing transaction id number (zxid ) to identify the transaction. All proposals (proposal) are proposed to be added when zxid. Zxid implementations is a 64-bit number, which is the high 32-bit epoch (ZAB policy change protocol to distinguish Leader epoch period by number) used to identify whether to change leader relationship, each time a leader is elected, it will have a the new epoch = (original epoch + 1), identifies the current part of the reign of the leader. 32 for the low counts.

 

 

------- be finishing ......