从Redis的架构看Redis使用优化方面的几个要点

最近的一些优化和运维项目中都有Redis，看样子不论是互联网架构的应用还是传统架构的应用，都已经意识到了访问频繁，数据结构简单的热数据使用合理的访问方式是十分重要的。既然客户有需求，我们就需要去深入的研究一下怎么把Redis用好，优化好。做一个运维对象的分析其实也是有套路的，并不一定都是需要从十年八年的积累中才可以获得，特别是针对Redis这样比较简单的内存数据库。

一般来说，对于这类相对简单的运维对象，我们在学习和梳理其要点的时候会首先从管理类、配置类、技术类三方面去了解它。把这些东西搞清楚了，这个运维对象的一些基本的运维，管理，优化就差不多了。当然要做这些事情之前的，一个十分重要的工作就是理解这个运维对象的架构。我觉得理解一个运维对象的架构对于今后去运维管理，做优化都是十分关键的。我和很多使用Redis开发应用系统的人聊过，他们大多数都没有关注过Redis的架构，反正给我变成接口，告诉我一些基本的操作，我就开干了，架构啥的我不关注。事实上，一个想把Redis用好的程序员，也是需要去深入的理解Redis的架构的。

Redis是一个轻量级的内存缓冲组件，被广泛的用作内存数据库、缓冲、消息代理、消息队列等。Redis可以提供亚毫秒级的响应时间，支持数十万甚至上百万级别的并发访问。不过很可能很多朋友都没有关注到，Redis的核心从本质上来说是单线程架构的。

这是网上都可以找到的十分典型的Redis单实例架构的逻辑架构图，是不是显得太简单了一点，不过事实上Redis就是这样的，十分简单。实际上大多数内存数据库，哪怕是timesten这样的内存关系型数据库，都会和普通的磁盘库在体系架构上有巨大的不同，这是因为内存与磁盘访问在延时上有成千上万倍的不同。Redis作为一种内存KV数据库，更需要十分简单的方式来充分利用内存的低延时特性，提供高吞吐量的访问。可能还是有朋友无法理解为什么Redis设计之初不设计成多线程架构，让Redis可以具有更高的吞吐能力。这个争论早在5、6年前就有过了，最典型的是2014年在Quora上针对Redis架构的争论，我看过之后受益良多。其实在多线程架构的数据库中，锁冲突是十分高开销的争用。相对于磁盘的IO延时来说，Enqueue的开销可能还可以接受，而对于内存的访问速度来说，锁争用带来的负面影响可能远超多线程带来的好处。因此Redis在设计之初就选择了无锁的串行单线程访问数据的架构。甚至最初的Redis整体都是单线程架构的。随着Redis的发展，Redis也出现了一些多线程的特性，比如4.0开始，延迟大键的删除操作，采用单独的后台进程来处理，另外多线程也被用于一些较满的IO操作。不管怎么发展Redis的核心数据访问还是串行单线程，无锁方式的访问。这种单线程的架构也让应用开发变得十分简单，因为无需考虑锁的问题，也不需要考虑回滚和提交。

这种单线程架构决定了Redis是不怎么消耗CPU的，因此你无需为单个的Redis实例配置过多的CPU，一般来说，2-4颗逻辑CPU线程就完全足够应付任何场景的并发访问了。

不过对于这种单线程架构，命令是串行执行的，因此平均每条命令执行的时间长度决定了单个Redis实例的并发访问量，比如我们一条命令平均延时为20ns，那么一秒钟有1000000ns,执行命令的总数理论上限是1000000/20=5万。比如下面的这个例子：

从报告上可以看出，平均每秒可以执行2万多条命令，而这些命令的执行中位数是35ns，算起来20106*35大概是0.7秒左右。

从单线程架构上我们也可以看出，Redis的并发访问是需要串行排队的，因此相同的命令，其执行时间是不稳定的，如果前面排队的命令比较多，那么排在前面的这条命令的总体执行时间比排在队伍后面的快十倍也是很正常的。因此对于Redis应用的性能分析，不能看单次的执行时间，更重要的是要看平均时间，中位数时间，90分位时间等指标。如果你的应用的中位数执行时间超过100ns，或者99分位数执行时间超过2毫秒，那么你的应用的性能是不能接受的，这会大大影响整个Redis实例上的应用的性能。如果说普通的数据库某条SQL慢点可能影响面有限，对于单线程的Redis来说，某些特别慢的命令是不能接受的，必须进行优化或者进行隔离，否则一颗老鼠屎可能会坏了一锅汤。

从Redis的单线程架构，也给我们的应用的横向扩展能力提出了要求。刚才我们也计算过了，单一的Redis实例的最大并发量是有限的，我们能够对应用做的优化也是有极限的。因此使用Redis的应用，如果需要支撑较大的并发量的话，一定要能够很方便的横向扩展的。我们可以通过Redis Cluster来做分片处理，通过多个Redis的集群来成倍的扩充Redis服务的并发量。

从Redis的单线程架构上来看，Redis数据库是内存敏感的，我们一定要确保Redis服务器的操作系统内存的充足，Redis也提供了大了的监控信息来帮我们分析内存是否足够。当服务器内存不足的时候，OOM KILLER要杀的肯定是Redis服务，因此我们也要确保Redis服务不会成为首先被杀的对象。

mem_fragmentation_ratio是一个十分值得关注的指标，这个指标出现异常，会引发REDIS的性能问题。如果这个指标超过1.5，说明Redis数据库存在较大的碎片，碎片会引起内存访问性能问题，从而影响数据库的总体性能。而如果这个指标小于1，说明数据库中有一部分内存被放入swap了，这更会引发更大的Redis性能问题。我们这台服务器上除了跑Redis外还有我们的一些其他的应用，包括postresql数据库、tomcat服务器等，最近总会出现内存不足的情况，swap使用率经常超过50%。可以看出，某些时段里，Redis出现了mem_fragmentation_ratio小于1的情况。如果你们的生产系统出现这种情况，那么给服务器或者虚拟机扩内存是十分必要的。

另外一点，从Redis是单线程的内核态访问为主的应用，那么其CPU资源消耗上，应该大部分的CPU都是可心态的访问，因此对于一台只是跑Redis数据库的服务器来说，sys的cpu比例应该很高。

在这个监控指标中，我们看出sys和user差不多，这是因为我们的服务器上还有PG数据库的原因。如果我们在自己的Redis服务器上发现了这种现象，那么就需要分析一下到底哪些非Redis实例在消耗CPU资源了。