《Redis开发与运维》读书笔记

一、初始Redis

1、Redis特性与优点

• 速度快。redis所有数据都存放于内存；是用C语言实现，更加贴近硬件；使用了单线程架构，避免了多线程竞争问题
• 基于键值对的数据结构，支持的数据结构丰富。它主要提供了5种数据结构： 字符串、 哈希、 列表、 集合、 有序集合， 同时在字符串的基础之上演变出了位图（Bitmaps） 和HyperLogLog两种神奇的“数据结构”， 并且随着LBS（Location Based Service， 基于位置服务） 的不断发展， Redis3.2版本中加入有关GEO（地理信息定位） 的功能
• 功能丰富。键过期功能，用来实现缓存；提供了发布订阅功能，实现消息系统；支持Lua脚本；提供简单的事务功能；提供了Pipeline，一次性将一批命令传给redis服务器，减小了网络开销
• 简单，稳定。源码少，3.0版本源代码只有5w行左右
• 客户端语言多。
• 持久化。两种持久化方式： RDB和AOF
  
• 主从复制。复制功能是分布式Redis的基础

• 高可用和分布式。2.8版本提供了高可用实现Redis Sentinel， 它能够保证Redis节点的故障发现和故障自动转移。 Redis从3.0版本正式提供了分布式实现Redis Cluster， 它是Redis真正的分布式实现， 提供了高用、 读写和容量的扩展性。

2、应用场景

• 缓存。
• 排行榜系统。redis提供了列表和有序集合支持。
• 计数器应用。
• 社交网络。
• 消息队列系统。redis提供了订阅发布和阻塞队列功能，虽然和专业的消息队列软件比不够强大，但是可以满足一般的消息队列需求

3、redis常用操作

• 服务端启动。配置文件启动，redis-server  /opt/redis/redis.conf
• 客户端启动。redis-cli -h 127.0.0.1  -p 6379
• 停止redis服务。redis-cli shutdown nosave|save  关闭过程：断开与客户端的连接；持久化文件生成。不建议kill -9 暴力杀进程，极端下会造成丢失数据的情况

二、API的理解和使用

1、全局命令

• 查看所有键。【keys *】会遍历所有键，禁用
• 键总数。【dbsize】不会遍历所有键，直接获取redis内置的键总数
• 检查键是否存在。【exists key】存在返回1，不存在返回0
• 删除键。【del key】返回结果为成功删除的键的个数
• 设置键过期。【expire key seconds】秒级别；【expireat key timestamp 】秒级时间戳；【pexpire key milliseconds】毫秒级过期 ；【pexpireat key milliseconds-timestamp 】毫秒级时间戳
  
• 检查键过期。【ttl key】返回键的剩余过期时间，秒级；【pttl key】毫秒级；-1，键没设置过期时间；-2 键不存在；
• 清除过期时间。【persist】；对于字符串类型键，执行set命令也会去掉过期时间；setex命令作为set+expire的组合， 不但是原子执行， 同时减少了一次网络通讯的时间
• 查看键的类型。【type key】键不存在，返回none
• 键重命名。rename key newkey。如果在rename newkey之前，newkey已经存在，newkey的值会被覆盖。防止被覆盖，提供了renamenx命令。重命名期间会删除原来的key，如果key对应的值过大，存在阻塞redis的可能。
• 随机返回一个键。randomkey。

2、数据结构和内部编码

每种数据结构都有底层的内部编码实现，而且是多种实现，redis会在合适的场景下选择合适的内部编码。

3、单线程架构

• Redis使用了单线程架构和IO多路复用模型（epoll作为多路复用技术的实现，非阻塞IO）来实现。
• 每次客户端的请求都会经过发送命令、执行命令、返回结果三个阶段。
• 所有客户端命令都会放入到同一个队列中，然后逐个被执行。
• 单线程避免了线程切换和竞态产生的消耗

4、字符串，最大不能超过512M

（1）命令

• 设置值。set key value [ex seconds] [px milliseconds] [nx|xx]。其中setnx可以作为分布式锁的实现
• 获取值。 get key。不存在返回 nil（空）
• 批量设置值，mset key value [key value ...] ；批量获取值，mget key [key ...] 。一次请求的网络时间大于命令处理时间。学会使用批量操作，能减少大量的网络消耗。提高业务处理效率。但是一次批量操作过多，有可能导致Redis阻塞或者网络拥堵
  
• 计数。incr、decr、incrby、decrby、incrbyfloat。很多其他的语言和存储系统通过cas实现计数，会有一定的cpu开销。redis单线程模型，完全不存在这个问题。
• 追加值。append key value。
• 字符串长度。strlen key。每个中文占用三个字节，也就是三个长度。
• 设置并返回原值。getset key value
• 设置指定位置的字符。setrange key offset value
• 获取部分字符串。getrange key start end。时间复杂度O（n）

（2）内部编码，有三种

• int。8个字节的长整型
• embstr。小于等于39个字节的字符串
• raw。大于39个字节的字符串

（3）应用场景

• 缓存
• 计数
• 共享session
• 限速。每个用户的请求频率，每个ip的请求频率

5、哈希

（1）命令

• 设置field值。hset key field value。hsetnx，和setnx作用相同，只不过作用域由键变为field
• 获取field值。hget key field。如果field不存在，返回nil
• 删除field。hdel key field [field ...] 
• 计算field个数。hlen key
• 批量设置和获取field-value。hmget key field [field ...] ；hmset key field value [field value ...] 。
  
• 判断field是否存在。hexists key field。存在返回1，不存在返回0
• 获取所有field。hkeys key
• 获取所有value。hvals key
• 获取所有field-value。hgetall key。如果获取的元素比较多，可能会阻塞Redis。
  
• hincrby key field；hincrbyfloat key field
  
• 计算value的字符串长度。hstrlen key field

（2）内部编码

• ziplist（压缩列表）。当哈希类型元素个数小于hash-max-ziplist-entries
  配置（默认512个） 、 同时所有值都小于hash-max-ziplist-value配置（默认64
  字节） 时， Redis会使用ziplist作为哈希的内部实现， ziplist使用更加紧凑的
  结构实现多个元素的连续存储， 所以在节省内存方面比hashtable更加优秀 
• hashtable（哈希表）。当哈希类型无法满足ziplist的条件时，Redis会使用hashtable作为哈希的内部实现

6、列表。列表中的每个字符串称为元素（element），一个列表最多存储2^32-1个元素。可以充当栈和队列，比较灵活。列表中的元素是有序的且可重复的，可以通过下标获取某个元素

（1）命令

• 添加操作。从右边插入数据 rpush key value [value ...]；从左边插入数据  lpush key value [value ...]；向某个元素前或后插入数据 linsert key before|after pivot value
  
• 查找。获取指定范围的元素列表 lrange key start end（包含end）；获取指定下标的元素 lindex key index（-1为最后一个元素）；获取列表长度 llen key
• 删除。从左侧弹出元素 lpop key；从右侧弹出元素 rpop key；删除指定元素 lrem key count value（count>0 从左到右，删除最多count个元素；count<0 从右到左；count=0，删除所有）；按照索引范围修剪列表 ltrim key start end
• 修改。修改执行索引下标的元素 lset key index newValue；
• 阻塞操作。blpop key [key ...] timeout ；brpop key [key ...] timeout 。需要注意两点：第一点，如果blpop多个key，一旦有一个键能弹出元素，立刻给客户端返回；第二点，如果多个客户端对同一个key执行blpop，那么最先执行blpop的客户端可以获取到弹出的值。
  

（2）内部编码

• ziplist（压缩列表）。当列表的元素个数小于list-max-ziplist-entries配置（默认512个），同时列表中每个元素的值都小于list-max-ziplist-value配置时（默认64字节），Redis会选用ziplist来作为列表的内部实现来减少内存的使用
• linkedlist（链表）：当列表类型无法满足ziplist的条件时， Redis会使用linkedlist作为列表的内部实现。
• Redis3.2版本提供了quicklist内部编码，简单地说它是以一个ziplist为节点的linkedlist，它结合了ziplist和linkedlist两者的优势，为列表类型提供了一种更为优秀的内部编码实现

（3）应用场景

• 消息队列。Redis的lpush+brpop命令组合即可实现阻塞队列， 生产者客户端使用lrpush从列表左侧插入元素， 多个消费者客户端使用brpop命令阻塞式的“抢”列表尾部的元素， 多个客户端保证了消费的负载均衡和高可用性。
• 文章列表。哈希存储每篇文章的详细信息。列表存储每个人的文章列表。支持分页获取，如果列表较大，获取列表中间元素的性能会变差，可以使用redis3.2版本的quicklist内部编码实现。
• lpush+lpop=Stack（栈） ；lpush+rpop=Queue（队列） ；lpush+brpop=Message Queue（消息队列，阻塞队列）； lpush+ltrim=Capped Collection（有限集合）
  

7、集合（set）。不允许有重复元素，无序，不能通过索引下标获取元素。一个集合最多可以存储2^32-1个元素。支持集合内的增删改查，集合的交集、并集、差集。

（1）命令。集合内操作。

• 添加元素。sadd key element [element ...]
• 删除元素。srem key element [element ...]
  
• 计算元素个数。scard key 。时间复杂度O（1），不会遍历集合。
  
• 判断元素是否在集合中。sismember key element 。在集合内返回1，不在返回0
  
• 随机从集合中返回指定个数元素。srandmember key [count]
  
• 从集合随机弹出指定个数的元素。spop key  [count] 
  
• 获取所有元素。smembers key 。如果元素过多，存在阻塞redis的可能。可以用sscan来完成。

（2）命令，集合间操作。

• 求多个集合的交集。sinter key [key ...]
  
• 求多个集合的并集。suinon key [key ...]
  
• 求多个集合的差集。sdiff key [key ...] 
• 将集合操作的结果保存。sinterstore/suionstore/sdiffstore  destination key [key ...] 

（3）内部编码

• intset（整数集合） ： 当集合中的元素都是整数且元素个数小于set-maxintset-entries配置（默认512个）时， Redis会选用intset来作为集合的内部实现，从而减少内存的使用。
• hashtable（哈希表） ： 当集合类型无法满足intset的条件时， Redis会使用hashtable作为集合的内部实现。

（4）使用场景

• 标签（tag）。使用sinter命令计算用户的共同兴趣。
• 生成随机数，抽奖

8、有序集合。元素可以排序，每个元素设置一个分数（score）作为排序的依据。集合成员不能重复，但是每个元素的score可以重复

（1）命令。集合内的命令。

• 添加成员。zadd key score member [score member ...] 

  ·Redis3.2为zadd命令添加了nx、 xx、 ch、 incr四个选项：
  ·nx： member必须不存在， 才可以设置成功， 用于添加。
  ·xx： member必须存在， 才可以设置成功， 用于更新。
  ·ch： 返回此次操作后， 有序集合元素和分数发生变化的个数
  ·incr： 对score做增加， 相当于后面介绍的zincrby。

• 计算成员个数。zcard key
  
• 计算某个成员的分数。zscore key member
  
• 计算成员排名。zrank key member （分数由低到高）；zrevrank key member （分数由高到低）
  
• 删除成员。zrem key member [member ...]
  
• 增加成员分数。zincrby key increment member
  
• 返回指定排名范围的成员。zrange key start end [withscores] （排名由低到高）；zrevrange key start end [withscores] （排名由高到低）
  
• 返回指定分数范围的成员。zrangebyscore key min max [withscores] [limit offset count] 。其中zrangebyscore按照分数从低到高返回， zrevrangebyscore反之。 例如
  下面操作从低到高返回200到221分的成员， withscores选项会同时返回每个
  成员的分数。 [limit offset count]选项可以限制输出的起始位置和个数 。同时min和max还支持开区间（小括号） 和闭区间（中括号） ， -inf和
  +inf分别代表无限小和无限大。
  
• 返回指定分数范围成员个数。zcount key min max
  
• 删除指定排名内的升序元素。zremrangebyrank key start end
  
• 删除指定分数范围的成员。zremrangebyscore key min max 

（2）命令，集合间的操作

• 交集。zinterstore destination numkeys key [key ...] [weights weight [weight ...]][aggregate sum|min|max]
• destination： 交集计算结果保存到这个键。
  ·numkeys： 需要做交集计算键的个数。
  ·key[key...]： 需要做交集计算的键。
  weights weight[weight...]： 每个键的权重， 在做交集计算时， 每个键中
  的每个member会将自己分数乘以这个权重， 每个键的权重默认是1。
  ·aggregate sum|min|max： 计算成员交集后， 分值可以按照sum（和） 、
  min（最小值） 、 max（最大值） 做汇总， 默认值是sum 
• 并集。zunionstore destination numkeys key [key ...] [weights weight [weight ...]][aggregate sum|min|max] 。

（3）内部编码

• ziplist（压缩列表） ： 当有序集合的元素个数小于zset-max-ziplistentries配置（默认128个） ， 同时每个元素的值都小于zset-max-ziplist-value配置（默认64字节） 时， Redis会用ziplist来作为有序集合的内部实现， ziplist
  可以有效减少内存的使用 
• skiplist（跳跃表） ： 当ziplist条件不满足时， 有序集合会使用skiplist作为内部实现， 因为此时ziplist的读写效率会下降。 

（4）使用场景

• 排行榜

9、键管理

（1）键迁移

• dump+restore可以实现在不同的Redis实例之间进行数据迁移的功能， 整个迁移的过程分为两步：
  1） 在源Redis上， dump命令会将键值序列化， 格式采用的是RDB格式。
  2） 在目标Redis上， restore命令将上面序列化的值进行复原， 其中ttl参数代表过期时间， 如果ttl=0代表没有过期时间。
  第一， 整个迁移过程并非原子性的，而是通过客户端分步完成的。 第二， 迁移过程是开启了两个客户端连接， 所以dump的结果不是在源Redis和目标Redis之间进行传输

• migrate命令也是用于在Redis实例间进行数据迁移的， 实际上migrate命令就是将dump、 restore、 del三个命令进行组合， 从而简化了操作流程。
  migrate命令具有原子性， 而且从Redis3.0.6版本以后已经支持迁移多个键的功能， 有效地提高了迁移效率， migrate在10.4节水平扩容中起到重要作用。
  第一， 整个过程是原子执行的， 不需要在多个Redis实例上开启客户端的， 只需要在源Redis上执行migrate命令即可。
  第二， migrate命令的数据传输直接在源Redis和目标Redis上完成的。
  第三， 目标Redis完成restore后会发送OK给源Redis， 源Redis接收后会根据migrate对应的选项来决定是否在源Redis上删除对应的键。
  migrate host port key|"" destination-db timeout [copy] [replace] keys key1 key2 key3
  key|""。要迁移的键，多个键此处为""。
  keys key1 key2 key3。迁移多个键

（2）键遍历

• 全量遍历键。keys pattern。支持pattern匹配。如果非要使用，在一个不对外提供服务的Redis从节点上执行， 这样不会阻塞到客户端的请求， 但是会影响到主从复制

• 渐进式遍历。每次执行scan， 可以想象成只扫描一个字典中的一部分键， 直到将字典中的所有键遍历完毕。
  scan cursor [match pattern] [count number]
  ·cursor是必需参数， 实际上cursor是一个游标，第一次遍历从0开始，每次scan遍历完都会返回当前游标的值，直到游标值为0，表示遍历结束。
  ·match pattern是可选参数，它的作用的是做模式的匹配，这点和keys的模式匹配很像。
  ·count number是可选参数，它的作用是表明每次要遍历的键个数，默认值是10，此参数可以适当增大。
  除了scan以外，Redis提供了面向哈希类型、集合类型、有序集合的扫描遍历命令，解决诸如hgetall、 smembers、 zrange可能产生的阻塞问题，对应的命令分别是hscan、 sscan、 zscan，它们的用法和scan基本类似
  渐进式遍历可以有效的解决keys命令可能产生的阻塞问题，但是scan并非完美无瑕，如果在scan的过程中如果有键的变化（增加、 删除、 修改），scan并不能保证完整的遍历出来所有的键

（3）数据库管理

• 切换数据库。select db。各个数据库之间没有联系，可以存在相同的键。redis是单线程的，多个数据库使用同一个cpu，彼此至今还是会受影响。
• 清除数据库。flushdb/flushall。如果当前数据库键值数量比较多，flushdb/flushall存在阻塞Redis的可能性

三、小功能，大用处

1、慢查询分析

（1）慢查询只是统计的命令执行的时间，不包括客户端发送命令、命令排队、返回结果的时间。

• slowlog-log-slower-than预设阀值，它的单位是微秒（1秒=1000毫秒=1000000微秒），默认值是10000。slowlog-log-slower-than=0会记录所有的命令，slowlog-log-slowerthan<0对于任何命令都不会进行记录。
• 实际上Redis使用了一个列表来存储慢查询日志，slowlog-max-len就是列表的最大长度
• 在Redis中有两种修改配置的方法， 一种是修改配置文件， 另一种是使用config set命令动态修改。如果要Redis将配置持久化到本地配置文件，需要执行config rewrite命令
• 获取慢查询日志。slowlog get [n] ，n可以指定条数。每个慢查询日志有4个属性组成， 分别是慢查询日志的标识id、 发生时间戳、 命令耗时、 执行命令和参数 
• 获取慢查询日志当前的列表长度，slowlog len。
  
• 慢查询日志列表清空。slowlog reset。

（2）最佳实践

• slowlog-max-len配置建议： 线上建议调大慢查询列表， 记录慢查询时Redis会对长命令做截断操作， 并不会占用大量内存。 增大慢查询列表可以
  减缓慢查询被剔除的可能， 例如线上可设置为1000以上。
• slowlog-log-slower-than配置建议： 默认值超过10毫秒判定为慢查询，需要根据Redis并发量调整该值。 由于Redis采用单线程响应命令， 对于高流量的场景， 如果命令执行时间在1毫秒以上， 那么Redis最多可支撑OPS不到1000。 因此对于高OPS场景的Redis建议设置为1毫秒。 
• 慢查询只记录命令执行时间， 并不包括命令排队和网络传输时间。 因此客户端执行命令的时间会大于命令实际执行时间。 
• 定期执行slow get命令将慢查询日志持久化到其他存储中（例如MySQL） ， 然后可以制作可视化界面进行查询

2、Redis  Shell

（1）Redis-cli

• -h 服务端ip
• -p 端口
• -r （repeat）将命令执行多次。redis-cli -r 3 ping
  
• -i （interval）每个几秒执行几次。redis-cli -r 5 -i 1 ping 
• -a （auth）密码
• --slave。将当前客户端模拟成服务端的从节点。
• --rdb。生成RDB持久化文件，保存到本地。可用来做持久化文件的定期备份
• --eval。执行lua脚本
• --latency。测试客户端到目标redis服务的网络延迟；--latency-history，每隔多久输出一次网络延迟；--latency-dist，使用统计图表的形式从控制台输出延迟统计信息
  
• --stat。实时获取redis的重要统计信息。key的数量、内存占用量、客户端数量、请求数量、连接数量

（2）redis-server

• redis-server --test-memory 1024。检测当前操作系统能否稳定地分配指定容量的内存给Redis。整个内存检测的时间比较长。该功能更偏向于调试和测试

（3）redis-benchmark。可以为Redis进行基准性能测试

• -c。代表客户端的并发数量（默认是50） 
• -n（num） 。代表客户端请求总量（默认是100000） 。redis-benchmark-c100-n20000代表100各个客户端同时请求Redis， 一共执行20000次 
• -r（random） 选项， 可以向Redis插入更多随机的键
• --csv选项会将结果按照csv格式输出， 便于后续处理， 如导出到Excel等

3、Pipeline。

（1）概述。Redis客户端执行一次命令，需要经历发送命令、命令排队、命令执行、返回结果四个过程。4个过程统称为一次Round Trip Time ，往返时间。

         Pipeline（流水线）机制能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端

（2）性能测试。执行速度一般比逐条执行要快，客户端和服务端的网络延迟越大，Pipeline的效果越明显

（3）原生批量命令和Pipeline对比。

• 原生批量命令是原子的，Pipeline是非原子的。
• 原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
• 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现。

（4）最佳实践

• 一次组装Pipeline数据量过大， 一方面会增加客户端的等待时间， 另一方面会造成一定的网络阻塞， 可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成
• Pipeline只能操作一个Redis实例

4、事务与lua

（1）事务

• 简单事务功能，multi和exec命令之间的命令，能够原子顺序执行。如果事务之中存在命令拼写错误，整个事务不会执行；如果存在运行时错误，事务并不会回滚
• watch命令，是事务执行之前，确保事务中的key没有被其他客户端修改过，修改过的话就不执行事务。类似于乐观锁
• Redis的事务比较简单，无法保证事务回滚，无法实现事务内命令之间的逻辑运算

（2）lua用法简述。由c语言实现，许多应用选用它作为脚本语言。尤其在游戏领域

（3）Redis中使用lua

• eval 执行lua脚本。eval 脚本内容 key个数 key列表 参数列表。对应 jedis.eval
• evalsha 执行lua脚本。

  script load命令可以将脚本内容加载到Redis内存中，返回SHA1。对应jedis.scriptLoad
  evalsha 脚本SHA1值 key个数 key列表 参数列表

• lua 的Redis API。

  使用redis.call函数实现对Redis的访问。例如：redis.call("set", "hello", "world")；redis.call("get", "hello")
  还可以使用redis.pcall函数实现对Redis的调用，如果redis.call执行失败，那么脚本执行结束会直接返回错误，而redis.pcall会忽略错误继续执行脚本

• 开发提示

  Lua可以使用redis.log函数将Lua脚本的日志输出到Redis的日志文件中，但是一定要控制日志级别。
  Redis3.2提供了Lua Script Debugger功能用来调试复杂的Lua脚本

• Redis管理Lua脚本

  script load 将Lua脚本加载到Redis内存中
  scripts exists sha1 [sha1 …] 判断sha1是否已经加载到Redis内存中
  script flush 清除Redis内存已经加载的所有Lua脚本
  script kill 用于杀掉正在执行的Lua脚本。如果此时lua脚本阻塞redis了，可以使用此命令快速将脚本杀掉。如果正在执行的是写操作，script kill 将不会生效，只能通过shutdown save停掉redis服务。

5、Bitmaps

（1）概述。Bitmaps本身的数据结构就是字符串，支持对字符串的位进行操作。

（2）每个独立用户是否访问过网站存放在Bitmaps中，将访问的用户记做1，没有访问的用户记做0，用偏移量作为用户的id

• 设置值。setbit key offset value 。初始化的时候，如果偏移量非常大，整个初始化过程会非常慢，可能会造成redis阻塞。
  
• 获取值。gitbit key offset 。返回0说明没有访问过
  
• 获取Bitmaps指定范围值为1的个数 。bitcount [start][end] 。
• Bitmaps间的运算 。bitop op destkey key[key....] 。做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中
• 计算Bitmaps中第一个值为targetBit的偏移量。bitpos key targetBit [start] [end]

（3）Bitmaps分析

假设网站有1亿用户， 每天独立访问的用户有5千万， 如果每天用集合类型和Bitmaps分别存储活跃用户。
集合类型内存量：64位*50000000=400M。
Bitmaps内存量：1位*50000000=12.5M。

6、HyperLogLog

• Redis中hyperloglog是用来做基数统计的，其优点是：在输入元素的数量或者体积非常非常大的时候，计算基数所需的空间总是固定的，并且是很小的。在Redis里面，每个Hyperloglog键只需要12Kb的大小就能计算接近2^64个不同元素的基数，但是hyperloglog只会根据输入元素来计算基数，而不会存储元素本身，所以不能像集合那样返回各个元素本身
• pfadd key element [element …]。添加操作。如果添加成功返回1
• pfcount key [key …]。求一个或多个key的基数，计算独立用户数
• pfmerge destkey sourcekey [sourcekey ...]。合并。pfmerge可以求出多个HyperLogLog的并集并赋值给destkey
• HyperLogLog内存占用量小得惊人， 但是用如此小空间来估算如此巨大的数据， 必然不是100%的正确， 其中一定存在误差率。 Redis官方给出的数字是0.81%的失误率

7、发布订阅

• 发布消息。publish channel message 。
  
• 订阅消息。subscribe channel [channel ...]。多个客户端订阅同一个频道，都会受到消息推送，类似于广播。
• 取消订阅。unsubscribe [channel [channel ...]]
• 按照模式订阅和取消订阅。psubscribe pattern [pattern...]；punsubscribe [pattern [pattern ...]]
• 订阅查询。pubsub channels [pattern]，查看活跃的频道；pubsub numsub [channel ...]，查看频道订阅数；pubsub numpat，查看模式订阅数

8、GEO

• 增加地理位置信息。geoadd key longitude latitude member [longitude latitude member ...]。longitude、 latitude、 member分别是该地理位置的经度、 纬度、 成员。添加和更新都是用此命令，可以同时添加多个地理位置信息。
• 获取地理位置信息。geopos key member [member ...]
• 获取两个地址位置的距离。geodist key member1 member2 [unit]。unit代表返回结果的单位，m（meters） 代表米、km（kilometers） 代表公里、mi（miles） 代表英里、ft（feet） 代表尺

• 获取指定位置范围内的地理信息位置集合。georadius key longitude latitude/georadiusbymember key member radiusm|km|ft|mi [withcoord] [withdist][withhash] [COUNT count] [asc|desc] [store key] [storedist key]
  都是以一个地理位置为中心算出指定半径内的其他地理信息位置

• 获取geohash。geohash key member [member ...]。Redis使用geohash将二维经纬度转换为一维字符串。
  GEO的数据类型为zset， Redis将所有地理位置信息的geohash存放在zset中
  字符串越长， 表示的位置更精确， 例如geohash长度为9时， 精度在2米左右
  两个字符串越相似， 它们之间的距离越近， Redis利用字符串前缀匹配算法实现相关的命令
  geohash编码和经纬度是可以相互转换的

• 删除地理位置信息。zrem key member。GEO没有提供删除成员的命令， 但是因为GEO的底层实现是zset， 所以可以借用zrem命令实现对地理位置信息的删除。

 四、客户端

1、客户端通讯协议

通讯协议是建立在TCP协议之上的。Redis制定了RESP（REdis Serialization Protocol， Redis序列化协议） 实现客户端与服务端的正常交互

2、Java客户端Jedis

基本使用、Jedis连接池、Pipeline用法、执行Lua脚本等功能

3、客户端管理

（1）客户端API。client .. 命令

• client list。列出与Redis服务端相连的所有客户端连接信息。输出结果的每一行代表一个客户端的信息， 可以看到每行包含了十几个属性
  id： 客户端连接的唯一标识， 这个id是随着Redis的连接自增的， 重启Redis后会重置为0
  addr： 客户端连接的ip和端口。
  fd： socket的文件描述符， 与lsof命令结果中的fd是同一个， 如果fd=-1代表当前客户端不是外部客户端， 而是Redis内部的伪装客户端。
  name： 客户端的名字
  age和idle分别代表当前客户端已经连接的时间和最近一次的空闲时间。当age等于idle时，说明连接一直处于空闲状态
  flag是用于标识当前客户端的类型， 例如flag=S代表当前客户端是slave客户端、 flag=N代表当前是普通客户端， flag=O代表当前客户端正在执行monitor命令

• 输入缓冲区： qbuf（总容量）、 qbuf-free（剩余容量）。
  redis为每个客户端分配了输入缓冲区， 它的作用是将客户端发送的命令临时保存， 同时Redis从会输入缓冲区拉取命令并执行， 输入缓冲区为客户端发送命令到Redis执行命令提供了缓冲功能
  输入缓冲区会根据输入内容大小的不同动态调整， 只是要求每个客户端缓冲区的大小不能超过1G， 超过后客户端将被关闭。输入缓冲区过大主要是因为Redis的处理速度跟不上输入缓冲区的输入速度

• 输入缓冲使用不当会产生两个问题：
  ·一旦某个客户端的输入缓冲区超过1G， 客户端将会被关闭。
  ·输入缓冲区不受maxmemory控制，一旦超过maxmemory限制， 可能会产生数据丢失、 键值淘汰、 OOM等情况

• 监控输入缓冲区异常的方法有两种：
  通过定期执行client list命令，收集qbuf和qbuf-free找到异常的连接记录并分析，最终找到可能出问题的客户端。能精准定位客户端，但是执行速度较慢，频繁指定可能阻塞redis
  通过info命令的info clients模块，找到最大的输入缓冲区，client_biggest_input_buf代表最大的输入缓冲区，可以设置超过10M（阈值）就进行报警。定位不精准，执行速度快。

• 输出缓冲区： obl、 oll、 omem。
  Redis为每个客户端分配了输出缓冲区， 它的作用是保存命令执行的结果返回给客户端， 为Redis和客户端交互返回结果提供缓冲。
  输出缓冲区由两部分组成： 固定缓冲区（16KB） 和动态缓冲区， 其中固定缓冲区返回比较小的执行结果， 而动态缓冲区返回比较大的结果
  client list中的obl代表固定缓冲区的长度， oll代表动态缓冲区列表的长度， omem代表使用的字节数
  监控输出缓冲区的方法同输入缓冲区监控方法

• 输出缓冲区的容量可以通过参数client-outputbuffer-limit来进行设置，输出缓冲区也不会受到maxmemory的限制
  配置规则：client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
  <class>： 客户端类型， 分为三种。 a） normal： 普通客户端； b）slave： slave客户端， 用于复制； c） pubsub： 发布订阅客户端。
  <hard limit>： 如果客户端使用的输出缓冲区大于<hard limit>， 客户端会被立即关闭。
  <soft limit>和<soft seconds>： 如果客户端使用的输出缓冲区超过了<softlimit>并且持续了<soft limit>秒， 客户端会被立即关闭

• 输出缓冲区出现异常的概率相对会比较大，如何预防；
  进行上述监控， 设置阀值， 超过阀值及时处理
  限制普通客户端输出缓冲区的， 把错误扼杀在摇篮中
  适当增大slave的输出缓冲区的，master节点写入较大， slave客户端的输出缓冲区可能会比较大， 一旦slave客户端连接因为输出缓冲区溢出被kill， 会造成复制重连
  限制容易让输出缓冲区增大的命令， 例如， 高并发下的monitor命令就是一个危险的命令。
  及时监控内存， 一旦发现内存抖动频繁， 可能就是输出缓冲区过大。

• client setName和client getName。client setName用于给客户端设置名字， 这样比较容易标识出客户端的来源。
• client kill ip:port。此命令用于杀掉指定IP地址和端口的客户端。

• client pause timeout(毫秒)。client pause命令用于阻塞客户端timeout毫秒数，在此期间客户端连接将被阻塞。生产环境中，暂停客户端成本非常高
  该命令可以在如下场景起到作用：
  client pause只对普通和发布订阅客户端有效，对于主从复制（从节点内部伪装了一个客户端）是无效的，也就是此期间主从复制是正常进行的，此命令可以用来让主从复制保持一致
  client pause可以用一种可控的方式将客户端连接从一个Redis节点切换到另一个Redis节点。

• monitor命令用于监控Redis正在执行的命令
  每个客户端都有自己的输出缓冲区， 既然monitor能监听到所有的命令， 一旦Redis的并发量过大，monitor客户端的输出缓冲会暴涨， 可能瞬间会占用大量内存

（2）客户端相关配置

• Redis提供了maxclients参数来限制最大客户端连接数， 一旦连接数超过maxclients， 新的连接将被拒绝。
  可以通过info clients来查询当前Redis的连接数
  axclients默认值是10000，可以通过config set maxclients对最大客户端连接数进行动态设置

• Redis提供了timeout（单位为秒）参数来限制连接的最大空闲时间，一旦客户端连接的idle时间超过了timeout，连接将会被关闭。默认的timeout是0，动态设置config set timeout 30
• tcp-keepalive：检测TCP连接活性的周期，默认值为0，也就是不进行检测，如果需要设置，建议为60，那么Redis会每隔60秒对它创建的TCP连接进行活性检测，防止大量死连接占用系统资源
• tcp-backlog：TCP三次握手后，会将接受的连接放入队列中，tcpbacklog就是队列的大小，它在Redis中的默认值是511。通常来讲这个参数不需要调整，但是这个参数会受到操作系统的影响

（3）客户端统计片段

info clients命令

• connected_clients：代表当前Redis节点的客户端连接数，需要重点监控，一旦超过maxclients，新的客户端连接将被拒绝。
• client_longest_output_list： 当前所有输出缓冲区中队列对象个数的最大值。
• client_biggest_input_buf： 当前所有输入缓冲区中占用的最大容量。
• blocked_clients：正在执行阻塞命令（例如blpop、 brpop、brpoplpush）的客户端个数。

info stats  命令

• total_connections_received： Redis自启动以来处理的客户端连接数总数
• rejected_connections： Redis自启动以来拒绝的客户端连接数， 需要重点监控

4、客户端常见异常

（1）无法从连接池获取到连接

• JedisPool中的Jedis对象个数是有限的， 默认是8个。如果连接池中没有空闲Jedis对象，新的请求就需要进行等待（例如设置了maxWaitMillis>0）
  在maxWaitMillis时间内仍然无法获取到Jedis对象就会抛出异常：JedisConnectionException: Could not get a resource from the pool
  如果设置了blockWhenExhausted=false， 那么调用者发现池子中没有资源时， 会立即抛出异常不进行等待

• 造成没有资源的原因非常多：
  客户端： 高并发下连接池设置过小， 出现供不应求
  客户端： 没有正确使用连接池， 比如没有进行释放
  客户端： 存在慢查询操作， 这些慢查询持有的Jedis对象归还速度会比较慢，造成池子满了
  服务端： 客户端是正常的， 但是Redis服务端由于一些原因造成了客户端命令执行过程的阻塞

（2）客户端读写超时，SocketTimeoutException: Read timed out

造成该异常的原因也有以下几种：
·读写超时间设置得过短。
·命令本身就比较慢。
·客户端与服务端网络不正常。
·Redis自身发生阻塞。

（3）客户端连接超时，SocketTimeoutException: connect timed out

造成该异常的原因也有以下几种：
连接超时设置得过短， 可以通过下面代码进行设置：jedis.getClient().setConnectionTimeout(time);
Redis发生阻塞， 造成tcp-backlog已满， 造成新的连接失败。
客户端与服务端网络不正常。

（4）客户端缓冲区异常

造成这个异常的原因可能有如下几种：
输出缓冲区满。
长时间闲置连接被服务端主动断开
不正常并发读写： Jedis对象同时被多个线程并发操作， 可能会出现上述异常

（5）Lua脚本正在执行

如果Redis当前正在执行Lua脚本， 并且超过了lua-time-limit， 此时Jedis调用Redis时， 会收到下面的异常。

JedisDataException: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE. 

（6）Redis正在加载持久化文件

Jedis调用Redis时， 如果Redis正在加载持久化文件， 那么会收到下面的异常：
JedisDataException: LOADING Redis is loading the dataset in memory

（7）Redis使用的内存超过maxmemory配置

Jedis执行写操作时， 如果Redis的使用内存大于maxmemory的设置， 会收到下面的异常， 此时应该调整maxmemory并找到造成内存增长的原因
JedisDataException: OOM command not allowed when used memory > 'maxmemory'.

（8）客户端连接数过大

• 如果客户端连接数超过了maxclients， 新申请的连接就会出现如下异常：
  JedisDataException: ERR max number of clients reached
• 一般来说可以从两个方面进行着手解决：
  如果应用方是分布式结构的话，可以通过下线部分应用节点（例如占用连接较多的节点），使得Redis的连接数先降下来。从而让绝大部分节点可以正常运行，此时再通过查找程序bug或者调整maxclients进行问题的修复。
  果此时客户端无法处理， 而当前Redis为高可用模式（例如Redis Sentinel和Redis Cluster） ， 可以考虑将当前Redis做故障转移。
  但是无论从哪个方面进行处理， 故障的快速恢复极为重要， 当然更为重要的是找到问题的所在， 否则一段时间后客户端连接数依然会超过maxclients。

 5、客户端案例分析

（1）Redis主节点内存陡增

• 服务端现象： Redis主节点内存陡增， 几乎用满maxmemory， 而从节点内存并没有变化
• 客户端现象： 客户端产生了OOM异常， 也就是Redis主节点使用的内存已经超过了maxmemory的设置， 无法写入新的数据

• 分析原因：
  确实有大量写入， 但是主从复制出现问题： 查询了Redis复制的相关信息， 复制是正常的， 主从数据基本一致。主从的键个数基本一致，使用dbsize命令
  其他原因造成主节点内存使用过大： 排查是否由客户端缓冲区造成主节点内存陡增， 使用info clients命令发现客户端输出缓冲区不正常，client_longest_output_list:225698
  通过client list命令找到omem不正常的连接， 一般来说大部分客户端的omem为0，redis-cli client list | grep -v "omem=0"
  最后发现是因为有客户端在执行monitor命令造成的

（2）客户端周期性超时

• 客户端现象： 客户端出现大量超时， 经过分析发现超时是周期性出现的
• 服务端现象： 服务端并没有明显的异常， 只是有一些慢查询操作

• 原因分析：
  网络原因： 服务端和客户端之间的网络出现周期性问题， 经过观察网络是正常的
  客户端： 由于是周期性出现问题， 就和慢查询日志的历史记录对应了一下时间， 发现只要慢查询出现， 客户端就会产生大量连接超时， 两个时间点基本一致
  最终找到问题是慢查询操作造成的， 通过执行hlen发现有200万个元素， 这种操作必然会造成Redis阻塞， 有定时任务代码每5分钟执行一次hgetall操作

五、持久化

1、RDB。RDB持久化是把当前进程数据生成快照保存到硬盘的过程， 分为手动触发和自动触发

（1）触发机制

• 手动触发：save命令。阻塞当前Redis服务器，直到RDB过程完成。线上环境不建议使用
• 手动触发：bgsave命令。Redis进程执行fork操作创建子进程，RDB持久化由子进程负责。阻塞只发生在fork阶段，时间很短。
• 自动触发：使用save相关配置：“save m n”，表示m秒内发生了n次数据修改，自动触发bgsave。
• 自动触发：从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件，发给从节点
• 自动触发：执行debuge reload命令重新加载Redis时，会自动触发save操作
• 自动触发：执行shutdown命令时，如果没有开启AOF功能，会自动触发bgsave

（2）流程说明

• 监测是否存在正在执行的子进程，如RDB/AOF进程，如果存在直接返回
• 父进程创建子进程，fork过程中父进程会阻塞，通过info stats 命令查看latest_fork_usec选项查看最近一次fork的耗时，单位为微秒
• 父进程fork完成后，返回“Backgroung saving started”，不在阻塞父进程，开始响应其他命令
• 子进程创建RDB文件，根据父进程内存生成快照，完成后对原有文件进行原子替换
• 子进程发送信号给父进程表示完成，父进程更新统计信息

（3）RDB文件的处理

• RDB文件保存在dir配置的路径下，名字为dbfilename配置。可以通过命令动态修改 config set dir；config set dbfilename
• Redis采用默认的LZF算法对生成的RDB文件进行压缩，默认开启，虽然压缩过程会消耗cpu，但是可以大幅降低压缩后的文件体积，方便保存到磁盘和通过网络传输到从节点，线上建议开启
• 如果Redis加载损坏的RDB文件时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件生成对应的错误报告

 （4）RDB的优缺点

• 优点：RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的快照。适用于备份、全量复制等场景。
• 优点：Redis加载RDB恢复数据的速度远远快于AOF的方式
• 缺点：RDB没有办法做到实时持久化
• 缺点：REB文件使用特定的二进制格式保存，存在老版本的服务器无法兼容新版RDB格式的问题。

2、AOF。以独立日志的形式记录每次写命令。重启时再重新执行AOF文件中的命令，达到恢复数据的目的

（1）配置

• 开启AOF功能需要设置配置： appendonly yes， 默认不开启。 AOF文件名通过appendfilename配置设置， 默认文件名是appendonly.aof。 保存路径同RDB持久化方式一致， 通过dir配置指定。
• 工作流程操作： 命令写入（append） 、 文件同步（sync） 、 文件重写（rewrite） 、 重启加载（load）

（2）命令写入缓存

• 写入的命令内容直接是文本协议格式，会把内容追加到缓冲区。文本协议具有很好的兼容性
• 先写入缓冲区，避免了每次的命令直接追加到硬盘，提高性能。

（3）文件同步到磁盘，由参数appendfsync控制。设置不同值含义不同

• always。命令写入缓冲区之后，调用系统fsync命令同步到磁盘，fsync完成后线程返回
• everysec。命令写入缓冲区之后，调用系统的write操作，write操作完成后线程返回。fsync同步操作由专门的线程每秒调用一次
• no。命令写入缓冲区之后，调用系统的write操作，不进行fsync操作。同步到硬盘由操作系统负责，通常同步周期最长30秒
• write操作会触发延迟写（delayed write）机制，Linux内核提供页缓冲区提高硬盘IO性能。write写入系统缓冲区之后直接返回。同步硬盘操作依赖于操作系统调度机制
• fsync操作，针对单个文件操作，强制磁盘同步。将阻塞直到写入硬盘完成后返回。
• always配置太耗费性能，只能支持大约几百tps并发写入；no配置，每次系统不同周期不可控；everysec，建议采用的同步策略，也是默认配置

 （4）AOF文件重写。把Redis进程内的数据转化成写命令同步更新到新的AOF文件，AOF重新降低了占用空间，更小的AOF文件可以更快的被Redis加载

• 重写之后的AOF文件变小的原因 ：
  进程内已经超时的数据不在写入文件
  旧的AOF文件中含有无效命令，新的AOF文件只保留最终数据的写入命令
  多条写命令可以合并成一个

 

十、集群

1、数据分布