用新工具折腾Redis性能，感觉还能再提升点儿

前几天在网上闲逛,看到一篇挺有意思的文章，标题大概是《我用新的性能工具把Redis又优化了一遍》，作者分享了他不用那些听起来就头大的专业工具，而是用了一些更直观的新玩意儿来折腾Redis，看看它的极限在哪，我照着文章的思路，自己也动手试了试，感觉确实有点意思，Redis这小东西，潜力比我们平时想的可能还要大点儿。

文章里首先提到一个关键点,就是我们平时觉得Redis已经快得飞起，没必要再优化了，但其实很多时候，Redis的性能瓶颈不在它自己，而在我们怎么用它，以及它所在的“环境”，网络延迟就是个隐形杀手，作者说他最开始也没在意，直到用了一个叫ping命令，但不是简单ping一下看通不通，而是用了一种能精确到微秒级别的工具（文章里好像提到了redis-benchmark自带的一些隐藏参数，或者结合redis-cli的--latency-history选项），来持续监测客户端到Redis服务器之间来回一次的时间波动，这一测就发现问题了，平时感觉不到的几毫秒的抖动，在超高并发下会被放大，成为拖后腿的关键，他建议，如果可能的话，把Redis实例和应用服务器放在同一个机房、甚至同一个机架上，物理距离的缩短带来的提升是最简单粗暴的。

文章花了挺大篇幅讲了一个我以前没太留意的细节：内存分配器，Redis自己并不直接管理所有内存，它依赖于底层的内存分配库，最常见的就是jemalloc，作者发现，不同版本的jemalloc，或者不同的配置参数，对Redis在处理大量小对象或者频繁释放重分配内存的场景下，性能表现差异挺明显的，他提到可以尝试升级到更新版本的jemalloc，因为新版本通常在碎片整理和分配效率上会有改进，他甚至尝试了换用其他的内存分配器，比如Google的tcmalloc，然后通过Redis的INFO memory命令来观察mem_fragmentation_ratio（内存碎片率）这个指标的变化，碎片率太高，说明内存浪费严重，也可能影响分配速度，通过对比，找到最适合当前业务数据模式的内存分配器，算是一个不涉及代码改动就能尝到甜头的优化点。

文章提到了持久化对性能的影响,但这个角度比较清奇，我们都知道AOF和RDB会影响性能，但他的关注点在于fsync的策略，AOF持久化时，有一个步骤是调用fsync把数据刷到硬盘上，这个操作是阻塞的，文章里提到，可以试试调整Linux操作系统的I/O调度策略，对于SSD硬盘，将调度器从默认的cfq（完全公平队列）改成noop或者deadline，可能会减少I/O操作的延迟，因为SSD没有机械硬盘的磁头寻道问题，更简单的调度策略反而效率更高，这个操作是在操作系统层面，但直接影响了Redis持久化线程的工作效率。

还有一点是关于Redis内部结构的,文章提到，对于存储集合类型（Set、Hash、List等）的数据，当元素数量很少时，Redis会使用一种叫ziplist的紧凑编码方式来节省内存，但节省内存有时候是以牺牲一点点CPU为代价的，因为编码和解码需要计算，他建议通过修改Redis的配置文件，调整这些编码方式的阈值。hash-max-ziplist-entries和hash-max-ziplist-value这两个参数，控制Hash类型在多少元素和多大value值时使用ziplist，如果你的应用是性能极度敏感型，且内存不那么紧张，可以适当调低这些阈值，让Redis更多直接使用更快的哈希表结构，用空间换时间，反之，如果内存是瓶颈，就调高阈值，多用ziplist省内存，这个需要根据实际情况做权衡和测试。

文章还稍微提了一下用火焰图这种可视化工具来定位CPU热点,虽然不是Redis特有的，但用它来观察Redis进程在执行哪些命令、哪些系统调用上花了最多时间，非常直观，如果发现某个命令的执行路径特别“宽”，那就说明它是瓶颈所在，可能就需要考虑优化这个命令的使用方式，或者看看是不是有更高效的替代命令。

我自己按图索骥试了其中几项,比如仔细查了查网络延迟，调整了一下ziplist的阈值，感觉就像是给一辆本来已经跑得很快的跑车做了个精细的保养和调校，虽然极限速度可能没提升多少，但整个响应变得更丝滑、更稳定了，确实，感觉Redis的性能天花板，在我们常规使用之上，还能再往上够一够，这些优化不是那种翻天覆地的大改动，而是这种一点点扣细节的“折腾”，有时候反而能解决实际运行中的一些痒点。