原文：

https://mp.weixin.qq.com/s/xcd8NWYMzpVJ3UKlGPIt9g

Java中的锁可以简单的理解为多线程情况下访问临界资源的一种线程同步机制。《Java多线程核心技术》

各样的锁的概念：公平锁、非公平锁、自旋锁、可重入锁、偏向锁、轻量级锁、重量级锁、读写锁、互斥锁等。

为什么使用分布式锁？

我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！

注意这是单机应用，也就是所有的请求都会分配到当前服务器的JVM内部，然后映射为操作系统的线程进行处理！而这个共享变量只是在这个JVM内部的一块内存空间！

后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图：

上图可以看到，变量A存在JVM1、JVM2、JVM3三个JVM内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象，例如：UserController控制器中的一个整形类型的成员变量），如果不加任何控制的话，变量A同时都会在JVM分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同JVM内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的！

如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题！

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。在单机环境中，Java中提供了很多并发处理相关的API。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁应具备的条件

1、互斥性在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、这把锁要是一把可重入锁（避免死锁）；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

不会发生死锁：有一个客户端在持有锁的过程中崩溃而没有解锁，也能保证其他客户端能够加锁
这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）
有高可用的获取锁和释放锁功能
获取锁和释放锁的性能要好

三种实现方式

1.数据库锁

基于数据库表

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。
当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

当我们想要锁住某个方法时，执行以下SQL：

因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为

操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

当方法执行完毕之后，想要释放锁的话，需要执行以下Sql:

上面这种简单的实现有以下几个问题：

1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

方案：搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

方案：只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。

3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

方案：搞一个while循环，直到insert成功再返回成功。

4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

方案：在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

使用基于数据库的这种实现方式很简单，但是对于分布式锁应该具备的条件来说，它有一些问题需要解决及优化：

1、因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换；

2、不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据，所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；

3、没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；

4、不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取。

5、在实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑。

基于数据库的排它锁

除了可以通过增删操作数据表中的记录以外，其实还可以借助数据库中自带的锁来实现分布式的锁。

我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

public void unlock(){
      connection.commit();
}

通过connection.commit()操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点和可重入问题。

总结：

总结一下使用数据库来实现分布式锁的方式，这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。
数据库实现分布式锁的优点: 直接借助数据库，容易理解。
数据库实现分布式锁的缺点: 会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。
操作数据库需要一定的开销，性能问题需要考虑。

1.1 乐观锁

乐观锁假设认为数据一般情况下不会造成冲突，只有在进行数据的提交更新时，才会检测数据的冲突情况，如果发现冲突了，则返回错误信息

实现方式：

时间戳（timestamp）记录机制实现：给数据库表增加一个时间戳字段类型的字段，当读取数据时，将timestamp字段的值一同读出，数据每更新一次，timestamp也同步更新。当对数据做提交更新操作时，检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，若相等，则更新，否则认为是失效数据。
若出现更新冲突，则需要上层逻辑修改，启动重试机制
同样也可以使用version的方式

性能对比

1、悲观锁实现方式是独占数据，其它线程需要等待，不会出现修改的冲突，能够保证数据的一致性，但是依赖数据库的实现，且在线程较多时出现等待造成效率降低的问题。一般情况下，对于数据很敏感且读取频率较低的场景，可以采用悲观锁的方式
2、乐观锁可以多线程同时读取数据，若出现冲突，也可以依赖上层逻辑修改，能够保证高并发下的读取，适用于读取频率很高而修改频率较少的场景
3、由于库存回写数据属于敏感数据且读取频率适中，所以建议使用悲观锁优化

2.基于redis的分布式锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的，可以解决单点问题。

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

互斥性。在任意时刻，只有一个客户端能持有锁。
不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。！！！
具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

加锁就一行代码：==jedis.set(String key, String value, String nxxx, String expx, int time)==，这个set()方法一共有五个形参：

第一个为key，我们使用key来当锁，因为key是唯一的。
第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

加锁代码满足我们可靠性里描述的三个条件。首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，代表加锁的客户端请求标识，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。由于我们只考虑Redis单机部署的场景，所以容错性我们暂不考虑。

错误实例

使用jedis.setnx()和jedis.expire()组合实现加锁

setnx()方法作用就是SET IF NOT EXIST，expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样，然而由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现，是因为低版本的jedis并不支持多参数的set()方法。

解锁：

首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）
使用缓存实现分布式锁的优点
- 通过超时时间来控制锁的失效时间并不是十分的靠谱。
- 使用缓存实现分布式锁的缺点
- 性能好，实现起来较为方便。

总结：

可以使用缓存来代替数据库来实现分布式锁，这个可以提供更好的性能，同时，很多缓存服务都是集群部署的，可以避免单点问题。并且很多缓存服务都提供了可以用来实现分布式锁的方法，比如redis的setnx方法等。并且，这些缓存服务也都提供了对数据的过期自动删除的支持，可以直接设置超时时间来控制锁的释放。

1、选用Redis实现分布式锁原因：

（1）Redis有很高的性能；
（2）Redis命令对此支持较好，实现起来比较方便

2、使用命令介绍：

（1）SETNX：SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。

（2）expire：expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。

（3）delete：delete key：删除key

在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。

3、实现思想：

（1）获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。

（2）获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。

（3）释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。

4、分布式锁的简单实现代码：

<dependency>
     <groupId>com.icloudbus</groupId>
     <artifactId>common-redis</artifactId>
     <version>1.0-SNAPSHOT</version>
</dependency>

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Transaction;
import redis.clients.jedis.exceptions.JedisException;

import java.util.List;
import java.util.UUID;

/**
 * 分布式锁的简单代码实现
 */
public class DistributeLock {

    private final JedisPool jedisPool;

    public DistributeLock(JedisPool jedisPool) {
        this.jedisPool = jedisPool;
    }

    /**
     * 加锁
     *
     * @param lockName       锁的key
     * @param acquireTimeout 获取超时时间
     * @param timeout        锁的超时时间
     * @return 锁标识
     */
    public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
        Jedis conn = null;
        String retIdentifier = null;
        try {
            //获取连接
            conn = jedisPool.getResource();
            //随机生成一个value
            String indentifier = UUID.randomUUID().toString();
            //key值
            String lockKey = "lock:" + lockName;
            //设置超时时间，上锁后超过此时间自动释放锁
            int lockExpire = (int) (timeout / 1000);
            //获取锁的超时时间，超过这个时间则放弃获取锁
            long end = System.currentTimeMillis() + acquireTimeout;
            while (System.currentTimeMillis() < end) {
                if (conn.setnx(lockKey, indentifier) == 1) {
                    conn.expire(lockKey, lockExpire);
                    //返回value值，用于释放锁时间确认
                    retIdentifier = indentifier;
                    return retIdentifier;
                }
                //返回-1代表key没有设置超时时间，为key设置一个超时时间
                //当 key 不存在时，返回 -2 。 当 key 存在但没有设置剩余生存时间时，返回 -1 。
                //否则，以毫秒为单位，返回 key 的剩余生存时间。
                if (conn.ttl(lockKey) == -1) {
                    conn.expire(lockKey, lockExpire);
                }
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    //当线程阻塞时，调用interrupt方法后，该线程会得到一个interrupt异常，
                    //可以通过对该异常的处理而退出线程,对于正在运行的线程，没有任何作用！
                    Thread.currentThread().interrupt();
                }
            }
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retIdentifier;
    }

    /**
     * 释放锁
     *
     * @param lockName   锁的key
     * @param identifier 释放锁的标识
     * @return
     */
    public boolean releaseLock(String lockName, String identifier) {
        Jedis conn = null;
        String lockKey = "lock:" + lockName;
        Boolean retFlag = false;
        try {
            conn = jedisPool.getResource();
            while (true) {
                //监视lock，准备开始事务
                conn.watch(lockKey);
                //通过前面返回的value值判断是不是该锁，若是该锁，则删除，释放锁
                if (identifier.equals(conn.get(lockKey))) {
                    //事务开始
                    Transaction transaction = conn.multi();
                    transaction.del(lockKey);
                    //事务提交
                    List<Object> results = transaction.exec();
                    if (null == results) {
                        continue;
                    }
                    retFlag = true;
                }
                conn.unwatch();
                break;
            }
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retFlag;
    }

}

5、测试刚才实现的分布式锁

例子中使用50个线程模拟秒杀一个商品，使用–运算符来实现商品减少，从结果有序性就可以看出是否为加锁状态。

模拟秒杀服务，在其中配置了jedis线程池，在初始化的时候传给分布式锁，供其使用。

import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class Service {
    private static JedisPool pool = null;

    private DistributeLock distributeLock = new DistributeLock(pool);

    int n = 500;

    static {
        JedisPoolConfig config = new JedisPoolConfig();
        //最大连接数
        config.setMaxTotal(200);
        //最大空间数
        config.setMaxIdle(8);
        //最大等待时间
        config.setMaxWaitMillis(1000 * 100);
        //在borrow一个jedis实例时，是否需要验证，若为true，则所有的jedis实例均是可用的
        config.setTestOnBorrow(true);
        pool = new JedisPool(config, "127.0.0.1", 6379, 123456);
    }

    public void seckill() {
        //返回锁的value值，供释放锁的时候进行判断
        String identifier = distributeLock.lockWithTimeout("resource", 5000, 1000);
        System.out.print(Thread.currentThread().getName() + "获得了锁");
        System.out.println(--n);
        distributeLock.releaseLock("resource", identifier);
    }

}

模拟线程进行秒杀服务：

public class ThreadA extends Thread{
    private Service service;

    public ThreadA(Service service){
        this.service = service;
    }


    @Override
    public void run() {
        service.seckill();
    }
}

public class Test {
    public static void main(String[] args) {
        Service service = new Service();
        for (int i = 0; i < 50; i++) {
            ThreadA threadA = new ThreadA(service);
            threadA.start();
        }
    }
}

结果如下，有序的：

Thread-32获得了锁    499
Thread-19获得了锁    498
Thread-43获得了锁    497
Thread-44获得了锁    496
Thread-13获得了锁    495
Thread-40获得了锁    494
Thread-27获得了锁    493
.................

若注释掉使用锁的部分：

   public void seckill() {
        //返回锁的value值，供释放锁的时候进行判断
//        String identifier = distributeLock.lockWithTimeout("resource", 5000, 1000);
        System.out.println(Thread.currentThread().getName() + "获得了锁    " + --n);
//        distributeLock.releaseLock("resource", identifier);
    }

从结果可以看出，有一些是异步进行的：

Thread-3获得了锁    498
Thread-4获得了锁    499
Thread-5获得了锁    497
Thread-6获得了锁    496
Thread-16获得了锁    495
Thread-10获得了锁    494
Thread-7获得了锁    493
Thread-15获得了锁    492
Thread-11获得了锁    491
Thread-12获得了锁    490
Thread-19获得了锁    489
.................

3.基于Zookeeper实现分布式锁

大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。

优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。

缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。

锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。
Zookeeper实现的分布式锁其实存在一个缺点，那就是性能上可能并没有缓存服务那么高。

因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同不到所有的Follower机器上。

使用Zookeeper实现分布式锁的优点: 有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。实现起来较为简单。
使用Zookeeper实现分布式锁的缺点 : 性能上不如使用缓存实现分布式锁。需要对ZK的原理有所了解。

4.三种方案的比较

从理解的难易程度角度（从低到高）: 数据库 > 缓存 > Zookeeper
从实现的复杂性角度（从低到高）: Zookeeper >= 缓存 > 数据库
从性能角度（从高到低）: 缓存 > Zookeeper >= 数据库
从可靠性角度（从高到低）: Zookeeper > 缓存 > 数据库

在实践中，当然是从以可靠性为主。所以首推Zookeeper。

分布式CAP理论

分布式系统架构理论，定义了三种指标，理论说我们最多只能满足两个。

## 分布式系统

首先我们这个理论所说的分布式系统，是指系统内会共享数据，互相有连接有交互，才能完成系统功能的的分布式系统。而这个理论的关注点是**数据**的读写。

## 三种指标

- Consistency 一致性:

这里的一致性是针对于分布式读写的。对于一个分布式系统，当一条数据写成功，那么无论我怎么使用这个系统，我都应当能马上读取到这条最新的数据。

不一致性的例子:我更新了一条微博，而我的关注者还不能看到。

- Avalilability 可用性:

是指系统应当随时可用，在reasonable的时间内返回reasonable的结果。

一个反例:我更新了一条微博，我的关注者在刷我微博的时候显示对方正在更新微博，请稍后再试，或者显示一直在读取中。

- Partition Toleranc 分区容忍性:

分布式环境中数据必然会被划分成多个区分到不同的机器上，不同的机器之间会有数据交换。

而机器一多某台机器发生发生故障的概率就会比较高，而且机器间数据的交换依赖于网络，网络也很有可能会有延时、丢包之类的问题。

分区容忍性就要求在分布式系统要考虑到分布式环境的复杂性的前提下能正常提供服务。

（原版cap中的p其实指的是网络分区现象[参考Wiki network partition] ，只由于网络设备的影响，分布式集群被划分成多个子网，但这样理解我始终想不通，可能这样解释更合理）

## 三种指标的意义

- CAP-P:

首先我们来看分区容忍性，由于我们讨论的就是分布式环境，我们的系统肯定不能被这网络环境机器环境所影响，分区容忍性就是个公认的前提，要么你就是很多个单机提供服务，但那不是分布式。为了实现分区容忍性，就需要我们设计多个数据副本，多个副本还不能在同一台机器上，甚至要在多个机房、多个地区存放副本。如果有必要机器之间的网络也需要多个通道，防止网络通路出现问题。

- CAP-CA:

前提环境保证了，我们就来讨论下读写功能。系统的功能无外乎输出输出，也就是读写操作咯。对于读写操作我们需要在一致性和可用性之间有所取舍，当然并不是完全舍去另一方，而是我们不能完美的同时实现C和A。

为啥呢，前提P已经说了我们需要多副本分布在多机器上，这副本之间同步数据是会有延时，其次如何保证在写的同时（副本未同步完成）我的读操作可能会发生在各个副本上，那我应该如何返回正确的数据。所以C和A只能完美保证一个。

## 例子

- 舍C保A(AP)的例子：

比如刚刚的微博这个例子，我们更新了一条微博，不是所有的人都能马上刷出来的，对于哪些还只能刷出旧的微博数据的人来说数据就和我真实的操作不一致了。然而这种业务也不需要要求我们强一致性，没有刷出我的最新微博，也不是什么大事，大不了认为我没有更新而已，对业务影响很小。但是呢也不能一直都不一致是吧，所以C还是不能丢的，可以迟到。

- 舍A保C(CP)的例子：

比如银行账户的例子，大家生活中也许也已经注意到了，银行转账需要几个小时甚至几天，都会显示正在转账中。这时就是视作一种丢失可用性的状态。当然这是业务决定的。

- 舍P保C又保A的场景：

不是分布式的场景的话，我们可以选择CA，比如我是个小银行，我的转账功能可以设计为多地账户不互通，只能本地转账，只在一台服务器上操作，保证可用性和一致性。但整体来看可用性和一致性都丢失了。

# 思考 acid

通用的关系型数据库设计理论，需要满足四种指标:

- Atomicity 原子性:

- Consistency 一致性:

- Isolation 独立性:

- Durability 持久性:

分布式锁解决并发三种方案

为什么使用分布式锁？

分布式锁应具备的条件

三种实现方式

1.数据库锁

1.1 乐观锁

2.基于redis的分布式锁

3.基于Zookeeper实现分布式锁

4.三种方案的比较

分布式CAP理论

Java7 Java 8 HashMap ConcurrentHashMap源碼解讀

Springboot集成kafka

redis--

SpringBoot利用cancl監聽mysql的binlog日誌通過kafja實時同步數據到es

分佈式鎖解決併發三種方案

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結