Redis中容易啋的坑

你好，我是梁松华，今天的话题是Redis中容易啋的坑。

Redis内存数据库是一把双刃剑，用得好的话就合家欢喜，否则就是深陷泥潭。所以我今天来谈一谈使用它时容易碰到的坑，帮你探探路。

我们在申请上游读接口调用权限时，往往会多问一句，这接口是否支持批量查询。正所谓，能批量绝不单个，能异步绝不串行。而读接口的底层大部分是通过Redis的批量Mget查询实现，没有人敢放心地将数据库查询暴露给非内部的系统。

但是，每次查询Key的个数如果不加以控制的话，将是一个隐患。比如，元素数目从10增长到100这个过程中，Mget性能下降非常明显。

因为，Mget是一个多Key的操作命令，但是一次操作的N个Key不在同一个分片上的话，就会将Mget命令拆分成多个Mget命令，也就是说一个请求将会被放大再合并。这是底层实现引起的限制。这就好比，在分库分表的场景中，如果你想对不在一个数据库的多表进行事务操作，神仙也无能为力。唯一的办法就是只有场景合适时才使用，或者努力创造机会。比如，算出Key对应的节点，将Mget操作手动分成多个操作，减少在Redis系统中的Merge操作。

说完常见的批量查询问题，再来看看第二个常见问题，也就是Lua脚本的使用。

市面上有些资料会告诉你不要使用Lua脚本，他们会告诉你Lua脚本维护成本高。但是弱弱地说一句，使用Lua脚本能轻松实现分布式锁或者分布式漏斗限流，它能保证多个指令执行是原子性的，另外，使用Lua脚本也能轻松实现系统运维中的自适应保护，当检测到容器CPU达到某个阀值时自动进行限流。这些方案在我们公司核心流程中都有落地，所以我是不认同因为维护成本高才不推荐使用的。

事实上，在工作中，我发现Redis集群在进行扩容、迁移、故障恢复操作时，Lua脚本没有同步给新实例。当调用Evalsha命令对缓存在服务器中的脚本进行求值运行时，抛出了ScriptNotFoundException异常。这或许是Redis中Lua脚本隐藏的彩蛋吧。这就要求我们必须手动捕获异常做一些补偿措施。

和Lua脚本问题类似的是阻塞队列的使用。

在一些场景中，部署和维护一套Kafka消息引擎，有点杀猪用牛刀那味。Redis虽然不能实现消息多播，但是充当中转队列还是绰绰有余的。利用列表可以实现先进先出的队列或者先进后出的栈。

不过呢，当列表为空时，客户端如果一直无脑轮询进行空运转的话，浪费资源。列表中有值能主动通知客户端来取就好了，类似并发编程模型的生产者和消费者模型。幸运的是，Redis就提供了这种特性，借助Blpop命令，可以移出并获取列表的第一个元素， 如果列表没有元素会阻塞等待。

但是，线程一直阻塞在那里的话，客户端连接就会成为闲置连接，闲置过久，服务一般会主动断开连接，这个时候再操作就会抛出异常。所以，在使用阻塞队列时，要考虑等待超时的问题。

前面介绍了Mget批量查询问题、Lua脚本问题、阻塞队列问题，接下来再看下最后一个吧，他们都是用着用着突然某一天就会爆出来的雷。

Redis这种单线程模型能达到这么高的性能，很多功劳都是内存贡献的，但是我们也不能无视某些内存机制对性能的影响。

我们知道，虚拟地址和内存地址是需要转换的，转换过程要查映射表，CPU通过内建快表TLB加速这个查表过程。如果虚拟页越大，表的条目数就越小，命中率就越高。所以，主流操作系统都提供了内存大页机制Huge Page，允许我们定制超过4K的大内存页。

但是，对于Redis这种需要Fork子进程的系统来说并不友好。Redis主从同步是异步进行的，保证了最终一致性，而Fork子进程那个瞬间是阻塞主流程的。如果映射表和内存页太大，拷贝就会很慢，阻塞时间将变得更长。因此，在生产环境，通常会关闭内存大页机制。

其实，Redis中还有很多很多需要注意的地方，包括Keys命令、大Key问题、大批量Key集中过期、增量同步太慢引发快照同步，在这里我就不一一展开了，有兴趣的小伙伴可以自行查阅。好，到这里本文就要结束了，如果觉得有用，欢迎分享给你的朋友们，下期见！