redis list如何判断键是否存在 redis如何判断key是否存在

1.购票占座

11车 7D的一位只能被一个人使用

java可以使用sync实现，但是占座服务可能多个jvm同时抢座位，sync只能给一个jvm中的资源加锁。

分布式锁 redis

Redis统一管理一把锁抢到锁的再进行统一的操作

setnx 判断加锁成功和锁的互斥

expire 设置锁的过期时间

这样客户端中断30s 锁会释放

单纯这俩命令不完美

解决方案：1. Set lock “1234” EX 1000NX/PX s/ms

要么都成功 要么都失败 具有原子性

2. lua 脚本 lua中无论有多少命令都认为是一个任务 同时成功 失败

参数解析：

1.EX 设置的时间 单位为秒

2.PX 设置的时间 单位为毫秒

3.NX 不存在设置值 eg：“123”

4.XX 不存在设置值 eg：“123” -> “1234”

具有原子性，设置锁和失效时间同时完成

EVAL script numkeys key [key …] arg [arg …]

lua脚本的意思是，返回KEYS[1], KEYS[2] ,ARGV[1],ARGV[2] 2个key k1,k2

,ARGV[1],ARGV[2] a1,a2

第二行意思是 返回KEYS[1], KEYS[2] ,ARGV[1],ARGV[2] 3个key k1,k2 a1

ARG[1] 为a2 ARGV【2】没有值

Test2 这个锁可以得到

1.没有判断是否是我的锁

2. get 和 到delete之前有时间差
   要保障解锁的原子性

严禁就都用原子性

锁的时长是30s，10s的时候客户端1申请锁后成功获得锁，可以去修改文件，但是35s的时候发生了STW fullGC，40时候锁到期之后，60s时候客户端2申请锁并获得锁，并去写入文件，当75s时STW结束，继续修改文件发生错误

STW引起的锁过期的问题，网络波动也会造成

解决方式：

1.采用乐观锁的方式，侵入代码中增加版本号

2.用watch dog将锁自动延期

侵入代码加入版本号，客户端1第一次得到锁的时候编写文件的version=33，之后发生STW，在STW期间，失去锁，客户端2获得锁并且在写入文件的过程中将version改变成了34，当客户端1完成STW之后先要继续操作文件的时候发现version已经是34了，不能继续编辑文件

redis中锁重构的功能比较单薄

锁是可以重入的，一个线程可以进入多次

redisson已经想好了一些场景和需要的锁

可以实现基本数据类型 String，List，Hash

@Test
public void testRBucketExamples() {
    // RList 继承了 java.util.List 接口
    RBucket<String> rstring = client.getBucket("redission:test:bucket:string");
    rstring.set("this is a string");

    RBucket<UserDTO> ruser = client.getBucket("redission:test:bucket:user");
    UserDTO dto = new UserDTO();
    dto.setToken(UUID.randomUUID().toString());
    ruser.set(dto);
    System.out.println("string is: " + rstring.get());
    System.out.println("dto is: " + ruser.get());

    client.shutdown();
}


@Test
public void testListExamples() {
    // 默认连接上 127.0.0.1:6379
    // RList 继承了 java.util.List 接口
    RList<String> nameList = client.getList("redission:test:nameList");
    nameList.clear();
    nameList.add("张三");
    nameList.add("李四");
    nameList.add("王五");
    nameList.remove(-1);//删除王五


    System.out.println("List size: " + nameList.size());


    boolean contains = nameList.contains("李四");
    System.out.println("Is list contains name '李四': " + contains);

    nameList.forEach(System.out::println);


    client.shutdown();
}

Redisson实现分布式锁

@Test
    public void testLockDemo() {
        RLock disLock = client.getLock("DISLOCK");
        boolean isLock = false;
        try {
            disLock.lock(); //默认30s
//            isLock = disLock.tryLock(20000, 1500000, TimeUnit.MILLISECONDS);
            System.out.println(isLock);
            if (isLock) {

                //TODO if get lock success, do something;
                Thread.sleep(15000);
            }
        } catch (Exception e) {
        } finally {
            // 无论如何, 最后都要解锁
            //disLock.unlock();
        }
    }

默认时间是30s

isLock = disLock.tryLock(20000, 1500000, TimeUnit.MILLISECONDS)

锁互斥的理论 key相同的锁不会

@Test
public void testLockDemo2() {
    RLock disLock = client.getLock("DISLOCK");
    boolean isLock = false;
    try {
        isLock = disLock.tryLock(2000, 1500000, TimeUnit.MILLISECONDS);
        isLock = disLock.tryLock(2000, 1500000, TimeUnit.MILLISECONDS);
        isLock = disLock.tryLock(2000, 1500000, TimeUnit.MILLISECONDS);

    } catch (Exception e) {
    } finally {
        // 无论如何, 最后都要解锁
        disLock.unlock();
        disLock.unlock();
        disLock.unlock();

    }
}

加锁一次value增加1，解锁一次-1，最后锁失效

1.获取锁：生成锁1.先生成“DISLOCK”，生成UUID，设置过期时间

2.判断key是否存在，不存在设置字段值为1，此过程就是生成锁

3.key存在，判断字段是否存在，也就是判断是不是自己的锁

4.key不存在，字段不存在，锁互斥

5.key存在，锁重构，字段值+1

existe 存在

hexists 都存在

hincrby 增加值

pexpire 生存时间 毫秒

KEYS[1] = DISLOCK 锁的名称

KEYS[2] ：订阅DISLOCK锁的状态，只要释放就可以占用

ARGV[1]：0 状态

ARGV[2]：生存时间

ARGV[3]：UUID

1.key不存在直接广播消息，锁不存在

2.key字段存在，字段值-1

3.字段值大于0，重新设置过期时间

4.字段值小于0，直接广播消息，锁不存在

发布0 这样订阅的都可以获得锁

只对

disLock.lock();

有用 ，每10s监听一次，没有完成重回30s。

分120段每段5个库存，这样5*120 = 600，就达到了每秒600订单的吞吐量

根据skuid和分段去减

抢占分段锁，随机到一个分段

1.抢占成功，秒杀下单

2.抢占失败 ，是否超时，未超时，尝试下一个分段

3.抢占成功，秒杀下单

4.抢占失败，回到2

5.超时抢锁失败

1，3，5 结束