简介：当引入分布式系统之后， 面临的问题是分布式必然是一个集群，而集群中的节点就需要交互，网络又是一个不稳定的因素， 这时则需要在一致性和可用性上做一个权衡，其中BASE理论是对CAP理论的延伸，核心思想：即使无法做到强一致性（Strong Consistency），但我们的应用可以采用适合的方式达能够到最终一致性（Eventual Consitency）。

CAP阐述：

  C：一致性>Consistency;

      取舍：(强一致性、单调一致性、会话一致性、最终一致性、弱一致性)

  A：可用性>Availability;

  P：分区容错性>Partition tolerance;

一、ZK(文件系统+监听机制watcher<观察者模式>)：

  配置JAVA环境：java -version;

  下载解压zookeeper：

  wget http://mirror.bit.edu.cn/apache/zookeeper/stable/zookeeper-3.4.12.tar.gz;

  tar -zxvf zookeeper-3.4.12.tar.gz; *.sh start;

  重命名配置文件：cp conf/zoo_sample.cfg conf/zoo.cfg;

  vim conf/zoo.cfg

  dataDir=/usr/local/data/zookeeper-1

  clientPort=2181

  server.1=127.0.0.1:2888:3888

  server.2=127.0.0.1:2889:3889

  server.3=127.0.0.1:2890:3890

zoo.cfg复制两个配置文件（其只需修改dataDir和clientPort即可.） 

启动zk

创建集群根节点：/GroupMembers

服务提供与消费

public class ZkServiceConsumer implements Watcher {

    private static final Logger logger = LoggerFactory.getLogger(ZkServiceConsumer.class);

    private static CountDownLatch countDownLatch = new CountDownLatch(1);

    private static ZooKeeper zk = null;

    private static String root = "/GroupMembers";

    public static void main(String[] args) throws Exception {
        zk = new ZooKeeper("xxx.xxx.x.xx:2181", 5000, new ZkServiceConsumer());
        countDownLatch.await();
        List<String> childrenList = zk.getChildren(root, true);
        logger.info("服务Provider:{}", childrenList);
        childrenList.forEach(child -> {
            try {
                logger.info(child + ":" + new String(zk.getData(root + "/" + child, false, new Stat())));
            } catch (KeeperException e) {
                e.printStackTrace();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        Thread.sleep(Integer.MAX_VALUE);
    }

    @Override
    public void process(WatchedEvent event) {
        if (Event.KeeperState.SyncConnected == event.getState()) {
            if (event.getType() == Event.EventType.None && event.getPath() == null) {
                countDownLatch.countDown();
            } else if (event.getType() == Event.EventType.NodeChildrenChanged) {
                try {
                    List<String> childrenList = zk.getChildren(event.getPath(), true);
                    logger.info("更新服务提供者列表：{}", childrenList);
                    for (String child : childrenList) {
                        logger.info(child + new String(zk.getData(root + "/" + child, false, new Stat())));
                    }
                } catch (KeeperException e) {
                    e.printStackTrace();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

创建集群节点n1

创建集群节点n2

   同n1(port:8082)

public class ZkProSync implements Watcher {

    private static final Logger logger = LoggerFactory.getLogger(ZkProSync.class);

    private static CountDownLatch countDownLatch = new CountDownLatch(1);

    private static ZooKeeper zk = null;

    private static Stat stat = new Stat();

    public static void main(String[] args) throws Exception {
        String path = "/username";
        zk = new ZooKeeper("xxx.xxx.x.xx:2181", 5000, new ZkProSync());
        countDownLatch.await();
        logger.info(new String(zk.getData(path, true, stat)));
        Thread.sleep(Integer.MAX_VALUE);
    }

    @Override
    public void process(WatchedEvent event) {
        if (Event.KeeperState.SyncConnected == event.getState()) {
            if (event.getType() == Event.EventType.None && event.getPath() == null) {
                countDownLatch.countDown();
            } else if (event.getType() == Event.EventType.NodeDataChanged) {
                try {
                    logger.info("配置已更改为：{}", new String(zk.getData(event.getPath(), true, stat)));
                } catch (KeeperException e) {
                    e.printStackTrace();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

<其中Consistency：zk保证了最终一致性，Sync到各个节点.>

二、Eureka

  eureka不会有类似于zk选举leader的过程，若某台服务器宕机，客户端请求自动切换到新的eureka节点，当宕机的服务器恢复后，eureka则再次将其纳入到服务器集群管理之中，即同步新的服务注册信息。

1.CP VS 2.AP

ZK定位于分布式协调服务，在其管辖下的所有服务之间保持同步、一致(Zab算法，CP)，若作Service发现服务，其本身没有正确处理网络分割的问题<当多个zk之间网络出现问题-造成出现多个leader-脑裂>，即在同一个网络分区的节点数达不到zk选取leader的数目，它们就会从zk中断开，同时也不能提供Service发现服务l。

Eureka相对于ZK剔除了选取Leader或事务日志机制，它有独立的客户端程序库，同时提供心跳、服务健康监测、自动发布等服务与自动刷新缓存的功能，在网络分割故障发生时，每个节点会持续的对外提供服务，接收新的服务注册同时将它们提供给下游的服务发现请求(AP)l。

Consul

官网 下载
https://www.consul.io/downloads.html

./consul --version 查看版本

./consul agent -dev -ui -node=consul-dev -client=192.168.106.11  启动


192.168.106.11:8500  查看ui 

Eureka Zookeeper Consul 注册中心的区别

JAVA的锁

锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源。在线程级别中我们可以通过代码的方式来实现锁的功能，例如Lock接口和synchronized关键字，在并发场景中充斥这大量的锁问题（线程锁、数据库锁、进程锁）。

死锁

所谓死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
java 死锁产生的四个必要条件：

• 互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
• 不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
• 请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
• 循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

PS：死锁的概念是百度抄的，轻喷

分布式锁

在以前的开发中，我们是把所有的代码部署在一台服务器中，只有一个jvm虚拟机，所有的请求都是线程级别的，因此我们只需要通过java的锁即可实现线程安全。
在现在的分布式场景下，我们是将一个系统或者是一个功能模块部署在多台服务器中，即一个服务有多个节点。一个请求访问你的系统时，我们的Nginx或者网关会把请求分发给不同的节点中，这时候如果有共享的资源就会出现竞争问题（线程不安全），此时jvm的线程锁无法解决进程间的资源竞争问题，这样分布式锁就出现了。

CP模型的分布式锁

CP模型是保证了在分布式系统中的一致性。CP模型的分布式锁是基于zk或者Etcd来实现的，适用于需要保证数据一致性的场景中。无论是zk还是Etcd本身就是支持分布式场景的组件，在集群有相互同步数据的机制，选择CP模式的分布式锁会牺牲一些系统的性能来保证数据的一致性，CP模式的分布式锁会在主宕机的情况下变的不可用（需要重新选主），即无法保证可用性。

zk分布式锁的原理

zk的分布式锁实现主要是基于zk的节点。zk的节点一共是分为持久节点（PERSISTENT），持久顺序节点（PERSISTENT_SEQUENTIAL），临时节点（EPHEMERAL），临时顺序节点（EPHEMERAL_SEQUENTIAL）四种。持久节点的特点是节点创建之后会一直存在，用户不做删除操作节点不会消失。临时节点的特点是节点会与客户端的会话绑定，客户端的会话结束节点会自动消失。因此zk的分布式锁是基于zk的临时顺序节点来实现。当多个进程访问我们的共享资源时，会先在zk上创建一个临时的顺序节点，并监听上一个节点，在进入业务代码前判断当前创建的节点是否为最小值，如果是最小值则才能做后续的操作，否则不做操作，继续等待。

zk节点操作

创建持久节点：
create /path value
创建顺序持久节点：
create -s /path value
创建临时节点：
create -e /path value
创建顺序临时节点：
create -e -s /path value

zk分布式锁代码实现

代码比较简单做了一个切面，用的是一个zk的jar包中实现的zk锁。如下：

CP模式分布式锁总结

以上是我对zk实现的分布式锁的一些介绍。zk可以很好的保证数据的一直性，不会因为节点宕机而导致数据的丢失，在对数据一致性要求较高的场景中使用即可。但是zk并不是一个专门来做存储的组件，在正式的生产环境中多数是扮演了一个注册中心的角色，是整个系统的协调者，如果让zk来承担较多的数据存储从而实现分布式锁并不是一个很好的方案，因此大多数情况下我们会用Etcd来实现CP模式的分布式锁，Etcd的CAS机制对于分布式锁的存储更友好，后续再写一篇Etcd的分布式锁吧，如有不足望大家指正。