redis

场景说明 设计秒杀活动时，因需要保证在高并发场景下库存不会超卖，或 抢券不会超量抢券的情况，可使用redis的decr功能 ，但是如果仅仅简单的使用decr，针对以下场景会有问题 剩余数量为1 线程1 decr 数量剩余0 线程2 decr 数量剩余-1 响应失败 线程1 因后续功能异常通过incr 归还数量 线程3 decr 数量剩余-1 响应失败 上述场景中，最后一个库存未使用便已不可用，在高并发场景下浪费的库存会较多，针对以上问题有以下两个方案 方案 方案1 当decr 结果小于0时，通过incr归还数量后返回失败 此方案的弊端是需要调用两次redis

连接 telnet 10.85.172.48 30901 get get limit:652824:639247269906973726:1166102 set set limit:652824:639247269906973726:1166102 '["java.util.ArrayList",[{"@class":"com.wujie.limit.domain.

使用redisson的原因 比zk性能要好 比使用redis.setnx的优势 使用redis.setnx时，如果系统挂掉，会一直锁住 redisson将ttl和set 通过lua脚本原子性批量执行 实现 Lock lock = redisson.getLock("test"); lock.lock(); 源码 RLock锁API public interface RLock { //----------------------Lock接口方法----------------------- /** * 加锁 锁的有效期默认30秒 */ void lock(); /** * tryLock()方法是有返回值的，它表示用来尝试获取锁，

问题描述 程序运行过程中，莫名其妙的找不到value,程序代码一切正常，该值设置了过期时间，但是未到过期时间 原因 [root@VM-3-11-centos ~]# redis-cli -h 10.3.x.xx 10.3.9.19:6379[2]> config get maxmemory 1) "maxmemory" 2) "1073741824"

作用 键空间通知使得客户端可以通过订阅频道或模式， 来接收那些以某种方式改动了 Redis 数据集的事件。 事件通过 Redis 的订阅与发布功能（pub/sub）来进行分发， 因此所有支持订阅与发布功能的客户端都可以在无须做任何修改的情况下， 直接使用键空间通知功能。 因为 Redis 目前的订阅与发布功能采取的是发送即忘（fire and forget）策略， 所以如果你的程序需要可靠事件通知（reliable notification of events）， 那么目前的键空间通知可能并不适合你： 当订阅事件的客户端断线时， 它会丢失所有在断线期间分发给它的事件。 开启键空间通知 因为开启键空间通知功能需要消耗一些 CPU ， 所以在默认配置下， 该功能处于关闭状态。

redis数据类型 string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合) string string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。 redis 127.0.0.1:6379> SET name "runoob"