一次库存超发，我们把手写的 setnx 锁全换成了 Redisson 3 月底的一次促销活动，某款商品库存 200 件，实际卖出 213 件。超发 13 件。客服赔了 13 张 50 元券，加上运营的抱怨，够我记很久。 查下来是分布式锁失效。我们当时用的是自己封装的 setnx 锁，问题出在一个很隐
故障演练那天，我们丢了 400 多条缓存 key 公司 7 月底做了一次故障演练，运维在预发环境把 Redis 主节点的进程 kill 掉，看哨兵能不能自动切换。切是切成功了，但演练结束后比对数据，主库的 key 数量是 12,480,331，切过去之后新主库只有 12,479,905，少了 426
宿主机重启，Redis 丢了 5 分钟的数据 4 月 20 号凌晨，云厂商的一台宿主机异常重启，我们的 Redis 主节点正好在上面。进程恢复之后，运营来反馈：03:12 到 03:17 之间领取的优惠券，用户端显示"未领取"，但业务库里记录是有的。 核对下来丢了 2347 条。我们 Redis 5
code review 时，我们为一个顺序吵了半小时 一月中旬，同事小王提了个 PR，商品改价接口里他这么写的： @Transactional public void updatePrice(Long skuId, BigDecimal newPrice) { redisTemplate.d
我一度以为 Redis 就是个能过期的 String 字典 刚接触 Redis 那两个月，我写的缓存代码全是这个画风： // 用户信息缓存 redisTemplate.opsForValue().set("user:" + userId, JSON.toJSONString(user), 1, Ti
同一笔订单被扣了两次款：我写的分布式锁形同虚设 十月下旬，财务对账发现 7 笔订单重复扣款。查下来是用户点了两次支付按钮，两个请求几乎同时打到两台不同的应用Ubuntu 服务器上，都通过了库存和状态校验，各扣了一次。 我当时的第一反应是"加个锁不就行了"，然后写出了这一版： public boole
凌晨两点的告警：Redis used_memory 撞到了 maxmemory 我们的 Redis 是 4.0.2，主从各 4G。某天凌晨收到告警，used_memory 冲到 3.9G，然后业务开始大面积报： redis.clients.jedis.exceptions.JedisDataExce
六月十三号上午，MySQL 被 3 万 QPS 打挂了 那天早上 9:07，我还在地铁上，DBA 的电话就打过来了："你们的库 CPU 100%，连接数打满，赶紧看看是不是缓存挂了。" 到公司一看监控，数据库 QPS 从平时的 800 飙到 31000，CPU 100%，连接数 500 打满，大量请
