[TOC] redis-cli +命令 直接执行命令 `redis-cli client list |grep -v "omem=0"` 这是配合了Linux命令，执行了redis命令 > * redis是单线程架构，所有的读写操作都是在是在一 条主线程上完成的。 > * 大的数据结构的拆分，避免使用keys ，sort命令 > * config set 动态的设置redis参数 > * redis bind 配置是连接redis绑定的网卡，如果绑定内网卡，则只能由内网卡对应的IP访问，外网同理。 * * * * * ### 1. 阻塞 1. 对于较大数据进行复杂度O（n）的操作 slowlog get<n> 查询出最近n条慢查询命令。解决办法： 1）修改为复杂度低的操作，禁用keys、sort等命令 2）查分较大的数据结构 2. 持久化造成的阻塞 1）fork阻塞 在RDB和AOF重写时，fork创建子进程，fork操作时间过长导致主线程的阻塞。info stats命令查看状态。 2）AOF 文件刷盘操作每秒执行一次，如果超过2秒，则阻塞后台进程直到fsync操作完成。 * * * * * ### 2. CPU、内存 * 单线程的Redis处理命令时只能使用一个CPU。而CPU 饱和是指Redis把单核CPU使用率跑到接近100%。使用 top命令很容易识别出对应Redis进程的CPU使用率。 * redis对内存的消耗主要包括：自身内存+对象内存+内存碎片 * redis是典型的cpu密集型应用，最好不要和其他多核密集型应用部署到一起。 * 为了充分利用多核CPU，通常一台机器部署多台redis实例。为了充分利用多核CPU，通常一台机器部署多台redis实例。子进程重写时对单核CPU使用率通常在90%以上，父进程与子进程将产生激烈CPU竞争，极大影响Redis稳定性。因此对于开启了持久化或参与复制的主节点不建议绑定CPU。 * * * * * #### 2.1内存信息 * redis使用内存分为进程和子进程消耗两块 * info memory 命令获取内存使用相关信息，下面是执行命令得到的结果 ~~~ 127.0.0.1:6379> info memory Memory used_memory:2154128 ---由 Redis 分配器分配的内存总量，以字节（byte）为单位，redis存储的所有数据所占内存 used_memory_human:2.05M ---直观可读的内存总量 used_memory_rss:4263936---从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小） used_memory_rss_human:4.07M used_memory_peak:2301128 used_memory_peak_human:2.19M total_system_memory:2098147328 total_system_memory_human:1.95G used_memory_lua:37888---Lua 引擎所使用的内存大小（以字节为单位） used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:1.98---used_memory_rss和used_memory以及它们的比值 mem_allocator:libc ~~~ 说明： * 当mem_fragmentation_ratio>1时说明used_memory_rss-used_memory多出来的内存没有用于数据存储，而是别内存碎片消耗，越大说明碎片越严重。 * 当mem_fragmentation_ratio<1时说明这种情况一般出现在操作系统把Redis内存交换（Swap）到硬盘导致，由于硬盘速度远远慢于内存，Redis性能会变得很差，甚至僵死。 #### 内存划分  > 1. 对象内存：key对象和value对象 > 2. 缓冲内存：客户端缓冲区、复制积压缓冲区和AOF缓冲区 * * * * * #### 2.2内存占用 * 对象内存是占用redis内存最大的，存储着用户的数据。 * 缓冲内存（客户端缓冲、复制积压缓冲、AOF缓冲） #### 2.3内存管理 1. 设置内存上限 通过设置maxmemory参数限制最大可用内内存，或者config set maxmemory进行动态修改。 1）用于缓存：当超出内存上限maxmemory时，使用2）LRU等删除策略释放空间 3）防止所用内存超过服务器内存 4）方便实现一台服务器部署多个redis进程的内存控制 2. 内存回收 1）删除过期键对象 redis的所用键都可以设置过期属性，内部保存在过期字典中。 2）内存溢出控制 当redis所用内存达到maxmemory上限时会触发相应的溢出控制策略。 * * * * * #### 2.4 内存优化 * redisObject结构体： redis存储的所有值对象在内部定义为redisObject结构体。redisObject对象包含以下属性 1）type ：表示当前对象使用的数据类型redis主要支持五种数据类型（string、hash、List、set、zset） 2) encode：表示当前对象采用哪种数据结构实现 3）lru：记录对象最后一次被访问的时间 4）refcount：记录当前对象被引用次数，当refcount=0时，可以安全回收对象空间。 5）ptr：对象的数据内容相关，如果是整数，直接存储数据，否则是指针 * 开发时尽量少对字符串频繁修改操作，例如append、setrange，用set 修改字符串，降低预分配带来的内存浪费和内存碎片。 * 利用hash结构对大规模的键进行重构，使用zipList编码可以减少内存消耗，如果是用hashtable编码反而会增加内存的消耗。---ziplist+hash优化keys 1. 如果有多个redis实例，尽量保证同一时刻只有一个子进程在工作 2. 避免大量写入时，子进程做重写操作，这样到这父进程维护大量的副本，造成内存消耗。 * * * * * ### 3. 数据持久化 * redis是内存数据库，所有运行时的数据都存在于内存中，如果redis服务器被关闭或者重启，所有数据将会消失，所以对数据进行持久化操作在某些环境下是非常必要的。redis的持久化操作有两种： 1）RDB（redis DB）:在磁盘上以二进制文件的形式保存所有redis数据，文件名dump.rdb。 2）AOF（append only file）：保存命令，文件名appendonly.aof。 * * * * * #### 3.1 RDB * 读取RDB恢复数据较快，由于数据量大，无法实时持久化。 将redis数据写到磁盘，覆盖原来的dump.rdb文件，这种数据的写入可以手工的触发，也可以通过配置文件自动执行。 1. 手动触发写入磁盘 1）save 命令：执行这个命令会阻塞redis服务器，服务器不能处理客户端请求。 2）bgsave：会创建子进程完成写入磁盘操作，会阻塞redis服务，阻塞时间为fork子进程所花费的时间，虽然时间可能很短，在高并发的业务场景下，可能也会拖慢数万条命令的执行。但是写入速度慢于save命令。 * rdb采用LZF算法存储，所有dump.rdb文件比内存中的数据小的多 * rdbacompression ：yes表示开启压缩，no，不压缩 #### 3.2 fork进程开销 * info stats 命令  ~~~ total_connections_received:7 # redis一共服务了多少个连接 total_commands_processed:41 # redis处理多少个命令 latest_fork_usec:209 # 最近一次fork子进程所花费的时间（微秒） ~~~ * save命令适合于在客户端请求少的情况下使用，很快的完成数据的备份，bgsave虽然备份速度较慢但是不会阻塞redis服务器，应该根据实际的情况选择不同的备份命令。 2. 配置文件的方式备份 在redis的配置文件中redis.conf中默认开启了RDB备份模式。文件中有如下配置 save 900 1 save 300 10 save 60 10000 save <秒> <操作次数> * 表示在规定秒数内，如果有N个键值对发生变化，则触发备份，上面的条件任意一个满足就会触发，并且这些条件不会叠加。在完成一次备份产生dump.rdb文件后，时间和次数计数器将会被清零。 * * * * * #### 3.3 AOF * AOF在redis.conf配置文件中默认默认不开启--- ~~~ appendonly no ---yes 开启 appendfsync everysec ---默认每秒持久化一次 auto-aof-rewrite-percentage 100 --- .aofwen文件大小超过一倍时发生重写 auto-aof-rewrite-min-size 64mb ---.aof文件大小超过64M发生重写 no-appendfsync-on-rewrite ~~~ #### 3.4 改善fork消耗性能 1. 优先使用物理机或者高效支持虚拟化的技术，避免使用Xen。 2. 控制redis实例最大可用内存，fork耗时和内存成正比，线上redis实例内存控制在10G以内。 > * no-appendfsync-on-rewrite：指定是否在后台aof文件rewrite期间调用fsync，默认为no，表示要调用fsync（无论后台是否有子进程在刷盘）。Redis在后台写RDB文件或重写afo文件期间会存在大量磁盘IO，此时，在某些linux系统中，调用fsync可能会阻塞。 * AOF重写：为了控制appendonly.aof文件的大小，redis提供了重写功能，重写会重整一些命令，减少命令的数量，并且使得数据不发生改变也不会阻塞redis服务。 * AOF持久化会将命令追加到appendonly.aof文件的末尾，只要redis重新执行这些命令就可以还原数据，在一些由于误操作导致数据丢失，可以将appendonly.aof文件中的操作删掉来恢复数据。最开始命令被写入内存缓冲区中，等到缓冲区被填满或者用户调用fsync、fdatasync命令才将命令写入到磁盘文件。触发命令持久化有三种方式always、everysec、no。 1. always：redis服务器每当接受一条命令都会调用fdatasync命令，将缓冲区的命令追加到文件中。这种方式可以保证数据的零丢失。 2. everysec：redis服务器每秒钟都会调用fdatasync命令，将缓冲区的命令追加到文件中。这种方式可以最多会丢失一秒钟的数据。 3. no：服务器不主动调用fdatasync命令，由操作系统决定何时将缓冲区的命令追加到文件当中去，所以发生意外的时候丢失的数据是无法预料的。 * 这两种持久化方式可以同时使用，根据需要判断，但是还原数据时优先使用AOF持久化。可见，从持久化角度讲，always是最安全的。从效率上讲，no是最快的。而redis默认设置进行了折中，选择了everysec。合情合理。 bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。 现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。 ### 3.4 持久化对性能的影响 > * 它的运行过程主要涉及CPU、内存、硬盘三部分 的消耗。 * CPU * 子进程在把内存数据向硬盘持久化时，属于CPU的密集操作，对于单核CPU利用率会达到90%左右。会和父进程产生单核资源竞争。 所以不要把redis和其他CPU密集型服务放在一起，CPU竞争太激烈。 * info Persistence 查看持久化信息，是否发生阻塞redis，AOF如果持久化距离上次持久化超过2秒，主线程将阻塞，直到同步操作完成。如果AOF发生延迟，可能是磁盘压力较大，使用iotop定位消耗IO资源的进程。 * * * * * ### 4.Linux系统对Redis服务的影响 * overcommit： Linux对大部分内存的请求都回复yes，以便能够运行更多的程序，但是申请内存后并不会马上使用内存，这种技术叫做overcommit。overcommit_memory对应有三个值，分别是0,1，2 0：Linux内核会检查内存是否足够，内存足够的话内存申请就会通过，否则失败并把错误返回给应用程序。 1：允许超量使用内存，知道用完为止。、 2：内核不会过量使用内存，系统整个内存地址空间不会超过swap+50%RAM。 * swap 交换分区 Linux在内存不足时会使用磁盘充当内存使用，解决一定内存紧缺的问题。 * * * * * ### 5.Pipeline * redis客户端执行一条命令经过以下四个过程 1)发送命令 2）命令排队 3）命令执行 4）返回结果 其中1）+4）称为RoundTripTime（RTT，往返时间）。 * Redis提供了批量操作命令（例如mget、mset等），有效地节约RTT。但大部分命令是不支持批量操作的，例如要执行hgetall命令，并没有相关的批处理命令 * Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端------Java支持Pipeline * redis批命令与Pipeline对比 1）原生批量命令是原子的，Pipeline是非原子的。 2）原生批量命令是一个命令对应多个key，Pipeline支持多个命令。·原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现。 * * * * * ### 6. 客户端管理 #### 6.1 client list、info clients > * client list 会列出与redis服务端连接所有客户端连接信息。  > * clientlist中的age和idle分别代表当前客户端已经连接的时间和最近一次的空闲时间 > 1. id： 客户端连接唯一标识，ID随着redis客户端的连接而自增长。redis重启后重置为0 > 2. addr： 客户端连接的IP和端口号 > 3. fd： socket的文件描述符，与lsof命令结果中的fd是同一个，如果fd=-1代表当前客户端不是外部客户端，而是Redis内部的伪装客户端。 > 4. qbuf、qbuf-free ：输入缓冲区 redis为每个客户端发来的命令分配输入缓冲区，临时保存命令。redis会从输入缓冲区中拉去命令然后执行。qbuf、qbuf-free代表输入缓冲区大小，输入缓冲区剩余 > * 输入缓冲区的大小会根据实际情况动态的分配，不能配置，但是大小不会超过1G，`否则这个客户端将会被关闭。` > 5. cmd 客户端执行的命令 * info clients：查看redis集群连接状态  可以查看连接的总数，阻塞的连接总数，最大输入缓冲区的连接。 client_ longest_ output_ list: 最大的客户端连接的输出缓冲区对象个数 * * * * * #### 6.2 输入缓冲区的问题 1. 一旦某个客户端的输入缓冲区超过1G，这个客户将会被关闭。 2. 输入缓冲区不受maxmemory控制，假设一个Redis实例设置了maxmemory为4G，已经存了2G数据，但是如果此时输入缓冲区使用了3G，已经超过maxmemory限制，可能会产生数据丢失、键值淘汰、OOM等情况。 * 输入缓冲区过大的原因 1. redis的处理速度跟不上输入缓冲区的输入命令速度。 2. 输入缓冲区中包含大量的bigkey 3. redis发生了阻塞，短时间内不能处理缓冲区的命令，导致了堆积。 * * * * * #### 6.3 解决输入缓冲区的办法 1. 定期执行client list，收集输入缓冲区记录，分析出有问题的客户端连接。 2. 通过 info clients 找到最大的输入缓冲区，client_biggest_input_buf,可以设置超过10m就报警。  #### 6.4 输出缓冲区 * 为客户端的命令执行结提供缓冲，和输入缓冲区对应。 与输入缓冲区不同的是，输出缓冲区的容量可以通过参数client-output-buffer-limit来进行设置，并且输出缓冲区做得更加细致，按照客户端的不同分为三种：普通客户端、发布订阅客户端、slave客户端。 > * 配置规则 ~~~ client- output- buffer- limit < class> < hard limit> < soft limit> < soft seconds> ~~~ `config set client-output-buffer-limit normal 20mb 10mb 120` > 表示超过10mb，并且连接了120秒，立即连接，如果超过20mb，也立即关闭。把普通客户端输入缓冲区控制起来，防止错误发生。 <class>：客户端类型，分为三种。 a）normal：普通客户端； b）slave：slave客户端，用于复制； c）pubsub：发布订阅客户端。 <hardlimit>：如果客户端使用的输出缓冲区大于<hardlimit>，客户端会被立即关闭。 <softlimit>和<softseconds>：如果客户端使用的输出缓冲区超过了<softlimit>并且持续了<softlimit>秒，客户端会被立即关闭 clientlist中的obl代表固定缓冲区的长度，oll代表动态缓冲区列表的长度，omem代表使用的字节数。例如下面代表当前客户端的固定缓冲区的长度为0，动态缓冲区有4869个对象，两个部分共使用了133081288字节=126M * 输出缓冲区可能造成内存的抖动。  #### 6.5 动态设置最大连接数 ~~~ config set maxclients 500 # 动态设置同一时间最大连接数。 config get maxclients # 查询最大连接数 ~~~ #### 6.6 客户端超时时间 * 执行 `client list`  age：表示客户端已经连接时间 idle：最近一次空闲时间 * 如果发现jedis的idle时间过长，肯定有问题，没有关闭连接。可以设置timeout超时时间，超时就断开连接。redis默认配置idle超时时间为0； * 如果设置了超时时间，注意对jedis pool 客户端的影响。  ### 7.主从复制 1. 主从架构中，数据由主节点流向从节点（单向） 2. 主节点和从节点的数据复制的偏移量正常应该一致（info replication） 3. 主从关系首次建立后，主从连接正常，主会把全部数据发送给从节点，此时特别消耗性能。  问题： > 当主从节点网络中断后，从节点再次连上主节点时会发送psync{offset}{runId}命令请求部分复制，如果请求的偏移量不在主节点的积压缓冲区内，则无法提供给从节点数据，因此部分复制会退化为全量复制。全量复制导致性能下降 #### 7.1 repl-disable-tcp-nodelay：默认关闭  * 当关闭时，主节点产生的命令会及时发送给从节点，增加了网络消耗 * 当开启时，主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux的内核，一般默认为40毫秒. #### 7.2 复制积压区 * 这个缓冲区可用于，主从复制数据丢失恢复  > 复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区， ~~~ role:master connected_slaves:1 slave0:ip=192.168.56.130,port=6379,state=online,offset=381567,lag=0 # slave复制偏移量，正常与master相等 master_repl_offset:381567 # master自身复偏移量 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:381566 # redis所有数据偏移量，参考master和slave复制偏移量，查看问题 ~~~  #### 7.3 复制注意问题 1. 在首次建立主从复制关系后，主节点会执行bgsave命令，产生dump.rdb文件保存到本地，然后给 从节点发送rdb文件，之后异步的发送修改命令给从节点达到数据同步。 所有即使在没有开启RBD的情况下，也会产生rdb文件。 * 主节点没有没开启自动save  * 开启了AOF  * 主节点的data目录，下多了dump文件  * * * * * * 主从数据同步超时 > * 针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。例如对于千兆网卡的机器，网卡带宽理论峰值大约每秒传输100MB，在不考虑其他进程消耗带宽的情况下，6GB的RDB文件至少需要60秒传输时间，默认配置下，极易出现主从数据同步超时。 * 复制客户端缓冲区 > * 对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置为client-output-buffer-limitslave256MB64MB60，如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB 时， 主节点将直接闭复制客户端连接， 造成全量同步失败。对应日志如下： #### 7.4 引起全量复制的原因 1. 刚建立主从关系，第一次复制。这是无法避免的，所以注意建立主从关系的时机。 2. 节点运行ID不匹配。如果主节点重启后，runID发生改变，从节点记录的是以前的主节点ID，认为是新主，所以引发全量复制。建议开启哨兵服务。 3. 复制积压缓冲区不足：当主从复制中断后，再次复制，如果请求的偏移量不在复制积压缓冲区中，引起全量复制。在高并发的场景下，增加缓冲区大小，默认是1M。 ### 8.bigkeys * 能在从节点做，尽量在从节点做。 ~~~ # -h 127.0.0.1 -p 6379 redis-cli --bigkeys ~~~  * * * * * ### 9. 慢查询 ~~~ # 设置慢查询时间，单位微妙 config set slowlog-log-slower-than 200 # 超过200微妙为慢查询 config set slowlog-max-len 1000 # 设置保存慢查询记录条数 slowlog get 4 # 查询四条慢查询 slowlog len # 显示有多少条慢查询 slowlog reset # 清空慢查询 ~~~  > * 每条慢查询四个属性 > * * * * * > 1. 慢查询表示id > 2. 查询发生时间撮 > 3. 查询消耗时间 > 4. 查询命令、参数 * 图中显示，系统保存128条慢查询记录  * * * * * ### 10. 实时监控命令 * 实时监控redis数据库库信息，数据库键信息，占用内存，连接信息。。。 `redis-cli --stat`  * * * * * ### 11. 误操作恢复 * 如果持久化是AOF的，并且在误操作后没有发生过重写，则修改屌误操作记录，然后使用 redis- check- aof 检查AOF格式是否正确，修复。然后重启redis `sudo redis-check-aof --fix appendonly.aof` * * * * * ### 12. 命令 #### 1.redis-cli ~~~ redis-cli 【option】【command】 ~~~ * option > 1. -r：（repeat），代表将命令重复执行 > redis-cli -r 3 ping  > 2. -i : (interval),代表每隔几秒执行一次命令，必须和-r 一起使用 ~~~ tuna@docker02:/etc/init.d$ redis-cli -r 3 -i 2 ping PONG PONG PONG ~~~ > 3. -x，读取标准输入 ~~~ tuna@docker01:~$ echo 'hello' | redis-cli -x set x OK ~~~ > 4. -c：连接redis集群时使用 > 5. -a：加入redis密码 > 6. `--slave`：把客户端模拟成所连接redis节点的从节点，获得数据库更新信息。  > 7. `--latency`：测试客户端到redis服务器的网络延迟。 > 8. `--state`：实时查看redis信息，包括客户端连接数量，redis占用内存。。。  > 9.` --raw`：返回格式化后的结果，`--no-raw`：返回原始格式  ~~~ redis-cli shutdown # 关闭redis，自动持久化，shutdown 后可加nosave|save显示指定是否持久化 ~~~ #### 2. redis-benchmark > 测试redis并发量 > * -c：模拟出的客户端数量（默认50） > * -n：模拟出客户端请求总数量（默认100000） > * ` --csv`按照格式导出，便于后续处理，如导入到Excel > * -t：指定测试的命令，如测试set、get等操作性能 ~~~ redis-benchmark redis-benchmark -c 100 -n 10000 # 显示的指出测试数量 ~~~ > `redis-benchmark `  如图，完成10万次操作用了4.94秒，由于用的是虚拟机，慢很多 * 指定测试操作命令，并格式化