技术好文每日推荐01 #java面试（技术好文每日推荐01+#java面试技巧）

技术好文每日一读。

技术文章多如牛毛，树哥帮你精挑细选。今天想和大家分享的一篇文章来自于滴滴技术的公众号。为什么reds内部使用不同编码？这篇文章从一个线上慢查询请求的报警入手，结合现象逐步分析排查，最终定位到redis对象内部。不同编码的查询时间复杂度差异由现象到本质，介绍了基础知识背景和背后的底层原理以及不同编码在查询数据上的时间复杂度区别。

接下来我为大家做了一个简单的总结。文章主要分为三个部分。

·第一部分介绍案发现场和基本现象。首先引入了一个现场慢查询的报警，在这个时候也发现redis集群内部有部分实例出现了cpu使用率上升的问题，慢查询也集中在这几个实例中。

在结合业务判断是少量的热k访问导致了部分redis实例负在变高，继而开始排查从故障期间的线上入手。线索如下：发现出问题的实例a中这几个热k是哈士数据结构里面存储的每个k都有四百多个元素，与此同时同样的业务逻辑。另外一个实例b中也存在类似的热k且qps比故障实例还要高，每个k的元素比故障实例也要多，但是却没有出现耗时高的问题。

·第三个现象就是热k上大部分命令都是h exists，出问题的热k内部编码是see pleased，没出问题的实例中内部编码是哈士table，由此猜测可能是由于编码不同引起的慢查询。

文章第二部分主要介绍redis编码的基础知识和不同编码之间的差异。首先介绍一下哈士对象的两种内部编码和差异以及两种编码方式数据结构，然后从命令执行入手介绍了对两种编码结构的处理逻辑。在介绍完这些背景知识以后开始比较两种编码的查询时间复杂度，由此猜测是由于时间复杂度的差异导致了a中的慢查询。

接下来就给了一波测试方案进行验证，从测试结果来看cpu的使用率和耗时还是相差比较大的。

·最后第三部分给出了一波优化思路，主要有三个方面。

→第一个就是release服务端的优化调整配置项，从而控制zip list的元素数量相对较少。

→第二点就是业务侧的优化方式针对单个的k做一个优化。

→第三部分是业务上的优化就避免落t。

整体上这篇文章从一个线上报警入手，然后从背景知识和底层实现去解释了一下造成这个现象的原因，个人感觉还是比较有收获的。

今天的视频就到这里，让我们下期再见。