最近一个 Spam 项目遇到个问题，有用户反馈无法点赞，查来查去是由于 Redis Key 没有过期时间，导致状态一直没有清除。这块代码逻辑涉及了事务操作。
业务逻辑
每个用户保存分钟，小时，天 三种维度的计数，当达到一定阈值后，就认为该用户频繁操作，属于 Spam 操作，涉及 redis 代码如下:
原业务逻辑
逻辑具体描述就是
1. 先对给定 Key 做 Incr 操作，取得自增后的 Value
2. 根据 Value 的值来判断是否为第一次设置
3. 如果为 1, 设置一定的过期时间
那么可以看到 Incr 和 SetTTL 原来是一个事务，套用 MySQL 的逻辑，就是这两个操作应该在 Start Transaction 和 End 事务之间。那么当前不是事务，很可能在这两个操作中间程序出问题，导致无 TTL 过期时间。
Cache集群问题
后端 Redis Cache 集群是 Twemproxy + Redis ，并且开启了 auto_eject_hosts, 查看日志，会发现偶尔 Twemproxy 会有踢出后端 Redis 又加进去的情况，很有可能在这个时候发生
1. 计数 Key 刚刚 Incr 完成，此时踢出
2. 判断返回 Value 为 1, 设置 TTL, 但此时 Key 的分布发生了变化
3. 后端 Redis 又被加回到 Proxy, Key 分布回到第 1 步时的位置, 当前 Key 丢失 TTL
改进
有了这几步论证，做出改进也容易多了，第一步使用 Redis-port 将所有无 TTL 的Key 全部清除，具体 Redis-port 如何使用，参照我的其它分享。第二步就是做多层判断。当时做了两种实现方式，方案一：
改进方案一
方案一会判断 Value 为 1～4时都设置 TTL, 假设一次设置失败的概率为 1%, 那么4次都失败的概率真就是1% * 1% * 1% * 1%, 这是典型的通过多次设置来覆盖失败率。
但是方案一属于模糊假设，对于百万级别的操作，发生无 TTL 的数量还是很可观，最终采用了方案二：
改进方案二
每次 Incr 后都获取 TTL，根据返回值来判断是否需要设置。这会导致每次业务请求多增加一次 Redis 操作，性能上完全可以接受。
Redis事务
肯定有小伙伴问能否使用 Redis 自身的事务，因为我们用了 Proxy 所以无法使用。并且 Redis 事务不完整，也很鸡肋。
粒度/频率控制服务
这类计数服务，当前实现为固定时间段的，理想情况应该使用时间滑动窗口的粒度/频率控制服务，这也是我们接下来要做的项目
后续
服务上线会发生各种意想不到的问题，也许，乐趣就来源于此。
网友评论