使用Redis缓存淘汰策略和事务实现乐观锁的方法
Redis Assistant 是一款为Redis设计的高效可视化管理与监控工具，提供多种操作模式，高效处理服务器数据。日常使用里的持续防护和信息管理会更突出，适合把安全控制放进长期使用流程中的场景。
缓存淘汰策略标题LRU原理LRU（Leastrecentlyused，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。最常见的实现是使用一个链表保存缓存数据，详细算法实现如下：新数据插入到链表头部；每当缓存命中（即缓存数据被访问），则将数据移到链表头部；当链表满的时候，将链表尾部的数据丢弃。在Java中可以使用LinkHashMap去实现LRU利用哈希链表实现：标题Redis缓存淘汰策略设置最大缓存在redis中，允许用户设置最大使
缓存淘汰策略
标题LRU原理
LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。
最常见的实现是使用一个链表保存缓存数据，详细算法实现如下：
新数据插入到链表头部；
每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
当链表满的时候，将链表尾部的数据丢弃。
在Java中可以使用LinkHashMap去实现LRU利用哈希链表实现：
标题Redis缓存淘汰策略
设置最大缓存
在 redis 中，允许用户设置最大使用内存大小maxmemory，默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一定要设置。
redis 内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。
淘汰策略
redis淘汰策略配置：maxmemory-policy voltile-lru，支持热配置
redis 提供 6种数据淘汰策略：
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据
Redis事务
Redis事务介绍
Redis 的事务是通过 MULTI 、 EXEC 、 DISCARD 和 WATCH 、UNWATCH这五个命令来完成的。
Redis 的单个命令都是原子性的，所以这里需要确保事务性的对象是命令集合。
Redis 将命令集合序列化并确保处于同一事务的命令集合连续且不被打断的执行
Redis 不支持回滚操作。 事务命令
MULTI
用于标记事务块的开始。 Redis会将后续的命令逐个放入队列中，然后使用EXEC命令原子化地执行这个命令序列。
语法：
multi
EXEC
在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态
语法：
exec
DISCARD
清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。
语法：
discard
WATCH
当某个[事务需要按条件执行]时，就要使用这个命令将给定的[键设置为受监控]的状态。
语法：
watch key [key…]
注意事项：使用该命令可以实现 Redis 的乐观锁。
UNWATCH
清除所有先前为一个事务监控的键
语法：
unwatch
命令图解：
事务演示：
127.0.0.1:6379> multi OK 127.0.0.1:6379> set s1 111 QUEUED 127.0.0.1:6379> hset set1 name zhangsan QUEUED 127.0.0.1:6379> exec 1) OK 2) (integer) 1 127.0.0.1:6379> multi OK 127.0.0.1:6379> set s2 222 QUEUED 127.0.0.1:6379> hset set2 age 20 QUEUED 127.0.0.1:6379> discard OK 127.0.0.1:6379> exec (error) ERR EXEC without MULTI 127.0.0.1:6379> watch s1 OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> set s1 555 QUEUED 127.0.0.1:6379> exec # 此时在没有exec之前，通过另一个命令窗口对监控的s1字段进行修改 (nil) 127.0.0.1:6379> get s1 111
Redis 不支持事务回滚（为什么呢）
大多数事务失败是因为语法错误或者类型错误，这两种错误，在开发阶段都是可以预见的Redis 为了性能方面就忽略了事务回滚。
Redis乐观锁
乐观锁基于CAS（Compare And Swap）思想（比较并替换），是不具有互斥性，不会产生锁等待而消耗资源，但是需要反复的重试，但也是因为重试的机制，能比较快的响应。因此我们可以利用redis来
实现乐观锁。具体思路如下：
利用redis的watch功能，监控这个redisKey的状态值
获取redisKey的值
创建redis事务
给这个key的值+1
然后去执行这个事务，如果key的值被修改过则回滚，key不加1
public void watch() {
try {
String watchKeys = "watchKeys";
//初始值 value=1
jedis.set(watchKeys, 1);
//监听key为watchKeys的值
jedis.watch(watchkeys);
//开启事务
Transaction tx = jedis.multi();
//watchKeys自增加一
tx.incr(watchKeys);
//执行事务，如果其他线程对watchKeys中的value进行修改，则该事务将不会执行
//通过redis事务以及watch命令实现乐观锁
ListRedis乐观锁实现秒杀
public class RedisLock {
public static void main(String[] arg) {
//库存key
String redisKey = "stock";
ExecutorService executorService = Executors.newFixedThreadPool(20);
try {
Jedis jedis = new RedisProperties.Jedis("127.0.0.1", 6378);
// 可以被秒杀的库存的初始值，库存总共20个
jedis.set(redisKey, "0");
jedis.close();
} catch (Exception e) {
e.printStackTrace();
}
for (int i = 0; i < 1000; i++) {
executorService.execute(() -> {
Jedis jedis1 = new Jedis("127.0.0.1", 6378);
try {
jedis1.watch(redisKey);
String redisValue = jedis1.get(redisKey);
int valInteger = Integer.valueOf(redisValue);
String userInfo = UUID.randomUUID().toString();
// 没有秒完
if (valInteger < 20) {
Transaction tx = jedis1.multi();
tx.incr(redisKey);
List list = tx.exec();
// 秒成功 失败返回空list而不是空
if (list != null && list.size() > 0) {
System.out.println("用户：" + userInfo + "，秒杀成 功！当前成功人数：" + (valInteger + 1));
}
// 版本变化，被别人抢了。
else {
System.out.println("用户：" + userInfo + "，秒杀失 败");
}
}
// 秒完了
else {
System.out.println("已经有20人秒杀成功，秒杀结束");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
jedis1.close();
}
});
}
executorService.shutdown();
}
} 
在Docker环境下为PHP安装Redis扩展：手动编译需下载源码、安装phpize、配置编译并安装，生成redis.so并在php.d目录新建redis.ini加载，重启PHP-FPM；也可直接yum安装php72w-pecl-redis，免手动编译。
配置PHP的Redis扩展：先安装Redis服务，从GitHub下载phpredis源码，用phpize编译安装，修改php.ini添加extension=redis.so，重启php-fpm或Apache，通过phpinfo验证并连接Redis。
C++结构体无法直接序列化为RESP协议，需手动将字段映射为*N数组嵌套$lenbulkstring形式。整数需转换为字符串并加:前缀，空字符串用$0\r\n，null用$-1\r\n。长度计算需精确到字节数，特别注意二进制安全，同时确保字段顺序与结构体定义一致。
Redis作为跨服务临时状态枢纽，需按消息队列、缓存和原子状态三重角色设计。选型用List实现任务分发及延迟重试，Stream用于事件广播与位点回溯。go-redis/v8需配置MinIdleConns、MaxRetries及超时。数据写入应JSON序列化并带type标签、设合理TTL、将关键字段提至顶层。消费通过原子GET+DEL或processedkey
在高并发秒杀场景下，利用Redis的减库存原子操作预扣减库存拦截超卖请求，再通过数据库乐观锁（版本号与库存校验）确保最终一致性，异常时回滚Redis库存并借助Lua脚本保证原子性，从而有效防止库存超卖。
在Go中使用go-redis执行Lua脚本可借助原子性解决竞态问题，通过redis.Script封装脚本并自动处理SHA1缓存与重试。需注意KEYS必须为非空切片且所有键在Cluster模式下落在同一slot，ARGV以字符串传入并由tonumber转换。返回值需先检查错误再调用Val()，避免panic。
先看一个典型场景：电商秒杀、库存扣减、定时任务重复调度——这些并发冲突在 TP6 应用里屡见不鲜。用 Redis 的 SETNX 做互斥锁，确实是轻量又直接的方案，但“能用”和“稳妥”之间，隔着三层硬功夫：原子加锁、身份校验、合理超时。这三条，差一条就翻车。 很多人第一次上手，直接写 SETNX 加
高并发抢购中，Redis的DECR原子操作可安全扣库存；配合think-queue异步削峰，接口仅扣库存和推消息；分布式锁需用SETNXEX加唯一标识，释放时用Lua脚本校验；成功资格后须以数据库事务双写为准，失败时补回Redis库存。
基于Redis的ZSET实现延时队列需解决并发重复消费、失败重试混乱、精度不足及内存爆炸等问题。通过Lua脚本保证取删原子性，使用毫秒级时间戳，对临时错误采用指数退避重试，永久错误记入独立哈希表，并限制最大延迟、定期清理过期任务、使用紧凑序列化格式。
操作 Redis 的时候，改个 Key 的过期时间其实是个高频场景。特别是做运维排查或者临时调试那会儿，谁也不想反复切命令行窗口、背那些命令参数。好在 RedisInsight 这个图形工具把这事儿做得很顺手——三种方式任选，总有一种合你胃口。 在动手前，先确认一下 Key 当前的 TTL 状态是个
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
