大家好，我是今天主人公小李，计算机专业毕业后顺利入职xx公司，而且老板好像也挺看重我的，还给我配了一个代码、职场经验都很丰富的老王做导师。

随着慢慢的融入到日常开发中，我感觉好像并不是一腔热血就能搞定的，下面就请大家看看小白码农的日常吧！

Day 1

小李：上周产品提了一个新 feature, 服务要加一层用户信息的缓存，这是我写的 MR 请王哥帮忙 review

老王：刚刚 Comment, 整体设计还可以问题不大，接口设计的不错，实现了依赖反转。多补几个 test case 吧。另外有两个地方需要修正：key 过期的时间不能是固定值，回源 DB 要做 singleflight …

小李：王哥为什么 expire time 不能是固定值？10分钟应该够用了

老王：你有没有想过极端的场景，大量用户同一时间过期，这时缓存都失效，会对 DB 造成多大的冲击？咱们用户大约 1kw, 哪怕这个极端场景是 1%, 就会有 10w qps 访问 DB, 想想是不是这个道理？

小李：hmm …. 好像是有这个情况，那怎么解决呢？expire + random 应该可以了吧？

老王：对哒，可以的。不过还有个优化点，咱们服务白天一般有 20个实例。如果同一个实例，同一个用户 cache 失效时，有大量回源 DB 操作，不同全部访问 DB，这会造成资源浪费，要做到 singleflight, 即同一个实例对同一个 key 只有一个访问 DB 的操作。这个优化在 CDN 行业中应用广泛

小李：学到了，谢谢王哥，优化一版，明天再帮我 review

Day 2

老王：小李 收到 pagertudy 报警没？线上接口变慢了，平时 p99 是 100ms, 现在接近 500ms

小李：看到了王哥，datadog 上看是 redis 变慢，应该和中午的 feature 有关

老王：先回滚，遇到问题第一时间回滚，线上恢复后再排查问题

小李：刚刚 dba 给出 slowlog, 最耗时的都卡在了 delete user:xxx:data 这类操作，很奇怪为什么这也能堵呢？

老王：你看下对应 value 有多大？slowlog 排行最前几个 user data

小李：这是一个 hset 结构，用户数据最多的有 1w 个 key, 量很大

老王：那么原因很清晰，删除大 key 导致单线程的 redis 堵了。需要两方面的优化：业务减少 hset fields 数据，同时看看咱们 redis 集群版本是多少？联系 dba 要不要升级到 bio 异步删除 key 的版本

小王：想起来了王哥，版本是 3.2.4, 上半年 dba 要求升级到 5.2 stable 版本，当时排期排不开，就一直没升

老王：又是技术债，这周你那的 feature 开发先放一放，协助升级 redis 吧…

小王：好的王哥

Day 3

小李：王哥，审计有一个需求，要所有的用户点击数据做审查。他们的开发负责人要求，咱们调他们的回调接口，感谢方案不是很好 …

老王：哦？说说为什么感觉方案不好？

小李：万一他们的服务出异常，这不就影响咱们服务了嘛？咱们写 redis list, 让他们异步读就够了

老王：可以的小王，你的思考很有深度，这叫做服务的解耦。但是写 redis list 不是好的选择

小李：听说 redis list 也可以当队列啊，lpush 入队，rpop 消费数据，而且咱们代码里有 redis client, 都不用写太多代码，可以直接用

老王：那你想的太少了。如果其它业务也想要这份数据，你还要写一份 redis? list 消费完了其它用户是取不到的，你去调研下 kafka fanout 和 consumer group 的概念。另外，如果 redis 内存不够用了怎么办？能落盘嘛？去调研下 kafka 吧，业界使用最广泛的消息队列

Day 4

小李：王哥，发现 redis 有好多 key 不像咱们业务的，是不是有人写错了？

老王：是嘛？那需要好好排查一下，另外，你是怎么发现的？

小李：redis-cli 连接线，然后 monitor 命令看到

老王：hmm …. 小李你这样很危险，尽可能不要直接操作线上 redis, 有需求找 dba 同学。像 monitor 命令在访问量超大的 redis 上有内存使用过多，导致 OOM 的可能

小李：这么严重啊王哥 …

老王：当然，线上还是要谨慎的。一些危险命令就更不能执行了，比如 flushall, save, bgsave 等等

小李：这点就不如 mysql 了，不同用户可以设置不同的权限，基本不会操作错误

老王：是啊，所以后来 redis 增加了 command rename 功能，但对线上还是要有敬畏之心，切记啊小李！！！

Day 5

小李：王哥，咱们 redis 使用这半年，积累了很多使用经验，我想在公司内部做一个分享，就叫 《Redis Best Practice》, 但有一件事情没想明白，为什么 redis 的坑那么多，咱们还用呢？我看 github 上有好多开源的分布式 KV 存储，看性能很好用

老王：可以啊，及时做总结，也能帮助公司其他团队。关于分布式 KV, 小李 有哪些吸引你的特性呢？

小李：协议完全兼容 redis, 同时存储容量 PB 级别的，不会受限于内存。有的 KV 还能模仿列存，看起来非常适合咱们业务

老王：是的，这些都是优点，能充分利用磁盘，节省公司成本。但这些产品问题也很大，每年都会有基于 rocksdb 的 kv 轮子造出来，一代目开发完 feature, 升职加薪跑路，留下一堆坑给二代目，数据一致性，rocksdb compaction cpu 消耗过高。咱们如果要用，不但需要专人来维护，还要懂开发，db 团队暂时没这个能力

小李：那咱们业务自己维护不可以嘛？听说部门里好几个懂分布式的大牛

老王：这… 就不是技术上的事情了。即然你这么感兴趣，建义业余时间多看看，万一下家公司用到了呢？

小李：好的，我研究研究，有不懂的还多请教王哥

小结

今天的分享就这些，如果对大家有所帮助和启发，请大家帮忙点击再看，点赞，分享 三连 ^_^