搜索
快速掌握Redis性能优化目录•Redis简介•Redis特性•Redis性能数据指标•常见性能问题分析•性能优化方案•性能测试Redis简介•Redis是一个开源的高性能Nosql数据库，也是基于内存的Key-Value存储系统，可以用作数据库、缓存和消息中间件•支持多种数据结构：字符串、哈希表、列表、集合、有序集合、位图、Hyperloglogs•内置了复制，LUA脚本，LRU数据淘汰，事务和不同级别的磁盘持久化等功能•通过Sentinel哨兵和Cluster自动分片集群提供高可用性Redis特性•基于单线程模型实现，一个线程服务所有客户端请求，采用非阻塞式IO•线程安全，所有操作都是原子的，不会因并发产生数据异常•速度非常快，大部分命令算法时间复杂度都是O(1)•使用高耗时Redis命令很危险，会占用唯一线程的大量处理时间，导致所有的请求都被拖慢Redis性能数据指标•通过Redis-cli命令行界面访问到Redis服务器，使用info命令获取丰富的Redis性能数据指标•info命令输出的数据可分为10个类别，分别是：serverclientsmemorypersistencestatsreplicationcpucommandstatsclusterkeyspace重要性能指标memory•输入infomemory命令，只返回与内存相关的数据•常用内存数据指标1.used_memory：已使用内存2.used_memory_rss：从操作系统上显示已经分配的内存总量3.mem_fragmentation_ratio：内存碎片率4.used_memory_lua：Lua脚本引擎所使用的内存大小5.mem_allocator：在编译时指定的Redis使用的内存分配器，可以是libc、jemalloc、tcmalloc以上指标都是以字节（byte）为单位重要性能指标CPU•used_cpu_sys:55.09--Redis服务器耗费的系统CPU•used_cpu_user:26.16--Redis服务器耗费的用户CPU•used_cpu_sys_children:0.02--后台进程耗费的系统CPU•used_cpu_user_children:0.01--后台进程耗费的用户CPU重要性能指标Clients记录了已连接客户端的信息•connected_clients:1--已连接客户端的数量（不包括通过从属服务器连接的客户端）•client_longest_output_list:0--当前连接的客户端当中，最长的输出列表•client_biggest_input_buf:0--当前连接的客户端当中，最大输入缓存•blocked_clients:0--正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量重要性能指标Stats•记录了一般统计信息•total_connections_received:782640--服务器已接受的连接请求数量•total_commands_processed:6401614--服务器已执行的命令数量•instantaneous_ops_per_sec:7--服务器每秒钟执行的命令数量•latest_fork_usec:475--最近一次fork()操作耗费的毫秒数重要性能指标Commandstats记录了各种不同类型的命令的执行统计信息记录命令执行的次数、命令耗费的CPU时间、执行每个命令耗费的平均CPU时间等等常见性能问题分析一生产系统刚开始运行阶段，系统稳定。但是运行一段时间后，发现部分时间段系统接口响应变慢。查看客户端日志经常会出现这样的错误：redis.clients.jedis.exceptions.JedisConnectionException:java.net.SocketTimeoutException:Readtimedout执行slowlog查看慢查询语句，发现有大量的keys命令操作，keys命令在大量并发情况下性能非常差正式环境中，尽量避免使用keys，接下来找出使用keys的代码做优化，至此，timeout问题解决常见性能问题分析二生产环境长时间的运行后，经常会有接口返回数据失败的情况，或者是从监控上发现数据库压力某一时间暴增。查看客户端日志发现这样的错误：redis.clients.jedis.exceptions.JedisConnectionException:Couldnotgetaresourcefromthepool执行clientlist命令，发现大量的client的idle时间特别长检查配置发现timeout和tcp-keepalive均未启用（均为0），redis服务端没有有效的机制来确保服务端已经建立的连接是否已经失效当服务器和客户端网络出现闪断，导致tcp连接中断，这种情况下的client将会一直被redis服务端所持有，就会出现上idle时间特长的client连接设置timeout和tcp-keepalive来清理失效的连接常见性能问题分析三突然间服务不能访问，返回错误：redis.clients.jedis.exceptions.JedisDataException:MISCONFRedisisconfiguredtosaveRDBsnapshots,butiscurrentlynotabletopersistondisk.Commandsthatmaymodifythedatasetaredisabled.PleasecheckRedislogsfordetailsabouttheerror.查看redis日志，发现有这个错误：Can’tsaveinbackground:fork:CannotallocatememoryRedis在保存内存的数据到磁盘时，为了防止主进程假死，会Fork一个子进程来完成这个保存操作，这个Fork的子进程会需要分配和主进程相同的内存，这时候就相当于需要的内存double了，如果这时候可用内存不足以分配需要的内存，将会导致Fock子进程失败而无法保存数据到磁盘。修改linux内核参数：vm.overcommit_memory=1，问题解决优化措施总结1.结合实际使用场景，考虑是否需要用到redis的持久化，如果单纯用来做应用层的缓存（在缓存未命中的情况下访问数据库），可以关闭持久化2.缓存模式下，尽量为每块缓存设置时效性，避免冷数据长时间占用资源3.生产环境中尽量避免使用keys操作，由于redis是单线程模式，大量的keys操作会阻塞其他的命令执行4.设置合理的内存回收策略，保证内存可用性的同时能适当的提供缓存的命中率5.提前计算出系统可能会用的内存大小，合理的分配内存。需要注意在开启持久化模式下，需要预留更多的内存提供给Fock的子进程做数据磁盘flush操作性能优化方案•关键参数优化•长耗时命令优化•延迟因素优化•内存管理优化•操作系统优化•读写分离机制•Redis集群关键参数优化•客户端最大连接数（maxclients）•可能的错误信息：maxnumberofclientsreached•默认为0，即不限制，一般不需要更改，所以客户端连接限制，取决于操作系统参数ulimit-n（maxopenfiles），可通过修改/etc/security/limits.conf文件以永久生效。关键参数优化•主从响应策略（repl-ping-slave-period/repl-timeout）•slave会每隔repl-ping-slave-period(默认10秒)ping一次master，如果超过repl-timeout(默认60秒)都没有收到响应，就会认为Master挂了。如果Master明明没挂但被阻塞住了也会报这个错。可以适当调大repl-timeout关键参数优化•客户端输出缓冲区（client-output-buffer-limit）•当使用主从复制时，性能压测下，数据量会急剧增长，导致从节点需要复制的数据很大，消耗时长增加。slave没挂但被阻塞住了，比如正在loadingMaster发过来的RDB，Master的指令不能立刻发送给slave，就会放在outputbuffer中，在配置文件中有如下配置：client-output-buffer-limitslave256mb64mb60这是说负责发数据给slave的client，如果buffer超过256m或者连续60秒超过64m，就会被立刻强行关闭所以此时应该相应调大数值，否则就会出现很悲剧的循环：Master传输一个很大的RDB给Slave，Slave努力地装载，但还没装载完，Master对client的缓存满了，再来一次关键参数优化客户端最大连接数（maxclients）•限制非预期的连接数增长，保持Redis的性能最优•应设置为预期连接数峰值的110%到150之间，若是连接数超出这个数字后，Redis会拒绝并立刻关闭新来的连接•默认情况下，尽量不要让Redis实例的客户端连接数超出5000长耗时命令优化•*不要把List当做列表使用，仅当做队列来使用•*通过机制严格控制Hash、Set、SortedSet的大小•*可能的话，将排序、并集、交集等操作放在客户端执行•*绝对禁止使用KEYS命令•*避免一次性遍历集合类型的所有成员，而应使用SCAN类的命令进行分批的，游标式的遍历长耗时命令优化SlowLog可以自动记录耗时较长的命令配置参数：•slowlog-log-slower-thanxxx#执行时间慢于xxx微秒的命令计入SlowLog•slowlog-max-lenxxx#SlowLog的长度，即最大记录多少条SlowLogSLOWLOGGET[number]命令，获取最近进入SlowLog的number条命令SLOWLOGRESET命令，重置SlowLog延迟因素优化网络引发的延迟•通常千兆网络环境中，TCP/IP网络延迟是200us(微秒)，Unix域Socket可以低到30us减少网络往返时间RTT(Round-TripTime)，官方优化建议：*长连接：不要频繁连接/断开到服务器的连接，尽可能保持长连接*域Socket：客户端与Redis服务端在同一台机器上，应使用Unix域Socket*多参数命令：相比管道，优先使用多参数命令，如mset/mget/hmset/hmget等*管道化：使用管道pipeline将连续执行的命令组合执行，减少RTT*LUA脚本：对于有数据依赖而无法使用管道的命令，可以考虑在Redis服务端执行LUA脚本延迟因素优化数据淘汰引发的延迟•当同一秒内有大量key过期时，会引发Redis的延迟，尽量错开key的失效时间•随机化设置过期时间，避免同一时间超过25%的Key过期导致的Redis阻塞Redis剔除过期Key的两种方式：•被动：当客户端访问到Key时，发现已经过期，则剔除•主动：每100ms剔除一批Key，假如过期Key超过25%则反复执行延迟因素优化Swap引发的延迟当Linux将Redis所用的内存分页移至swap空间时，将会阻塞Redis进程，导致Redis出现不正常的延迟/proc/pid/smaps文件中会保存进程的swap记录，通过查看这个文件，能够判断Redis的延迟是否由Swap产生。如果这个文件中记录了较大的Swapsize，则说明延迟很有可能是Swap造成的延迟因素优化数据持久化引发的延迟Redis的数据持久化工作本身就会带来延迟，需要根据数据的安全级别和性能要求制定合理的持久化策略RDB持久化通常会提供比使用AOF更高的性能，但每次RDB快照和AOFRewrite都需要Redis主进程进行fork操作，fork操作本身可能会产生较高的耗时根据具体情况合理配置RDB快照和AOFRewrite时机，避免过于频繁的fork带来的延迟可以通过INFO命令返回的latest_fork_usec字段查看上一次fork操作的耗时（微秒）内存管理优化