公众号|松华说|Redis中容易踩的坑
  • 分享在京东工作的技术感悟,还有JAVA技术和业内最佳实践,大部分都是务实的、能看懂的、可复现的

扫一扫
关注公众号

Redis中容易踩的坑

博客首页文章列表 松花皮蛋me 2020-09-20 14:16


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集中过期、增量同步太慢引发快照同步,在这里我就不一一展开了,有兴趣的小伙伴可以自行查阅。好,到这里本文就要结束了,如果觉得有用,欢迎分享给你的朋友们,下期见!