Redis开发与运维学习笔记
《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文件只保留最终数据的写入命令
多条写命令可以合并成一个
