文章目录
- 概要
- String结构
- Hash结构
- List结构
- Set结构
- Zset结构
- bitmap位图类型
- geo地理位置类型
- 其他常用命令
概要
redis常用的5种不同数据结构类型之间的映射如下：
| 结构类型 | 结构存储的值 | 结构的读写能力 |
|---|---|---|
| STRING | 可以是字符串、整数或者浮点数 | key-value形式；对整数和浮点数执行自增或者自减操作 |
| LIST | 一个链表，链表上的节点都包含了字符串 | 链表两端插入或者弹出；对链表进行修建；读取单个或者多个元素；根据值查找或者删除 |
| SET | 元素不重复、无序的 collection | 添加、获取、删除单个元素；检查元素是否存在；计算交集、并集、差集；从集合中随机取 |
| HASH | HASH 包含字符串的无序散列表 | 添加、获取、移除单个键值对；获取所有键值对 |
| ZSET(有序集合) | 字符串成员与浮点数分值之间的有序映射，元素的排列顺序由分值决定 | 添加、获取、删除单个元素；根据分值范围(range)或者成员来获取元素 |
String结构
常用命令
SET SET key value 存入字符串键值对
MSET MSET key value [key value] 批量存储字符串键值对
SETNX SETNX key value 存入不存在的字符串键值对，存在返回false，不存在返回true
GET GET key 获取一个字符串键值
MGET MGET key [key] 批量获取字符串键值
DEL key [key] 删除一个键
EXPIPE key seconds 设置一个键的过期时间(秒)
原子加减
INCR key 将key中存储的值加1
DECR key 将key中存储的值减1
INCRBY key increment 将key中存储的值增加increment
DECRBY key decrement 将key中存储的值减少increment
应用场景举例：
- 如需要往redis中存储一个对象（数据库中的对象，也就是表中一行数据）
有两种方式：
# 方式一
SET user:1 value(json格式数据) # 将每一行数据json后 再进行存储 其中1表示这条数据的id
# 方式二
MSET user:1:name alai user:1:balance 1888 # 使用批量设值的方式
MGET user:1:name user:1:balance
- 计数器
比如，文章的阅读量
INCR article:readcount:{文章id}
GET article:readcount:{文章id}
- 分布式id
INCRBY orderId 1000 //redis批量生成序列号提升性能 先批量生成 存储在本地服务器
Hash结构
常用命令
HSET HSET key field value //存储一个哈希表key的键值
HSETNX HSETNX key field value //存储一个不存在的哈希表key的键值
HMSET HMSET key field value [field value ...]//在一个哈希表key中存储多个键值对
HGET HGET key field //获取哈希表key对应的field键值
HMGET HMGET key field [field ...] //批量获取哈希表key中多个field键值
HDEL HDEL key field [field ...] //删除哈希表key中的field键值
HLEN HLEN key //返回哈希表key中field的数量
HGETALL HGETALLkey //返回哈希表key中所有的键值
原子操作
HINCRBY HINCRBY key field increment //为哈希表key中field键的值加上增量increment
应用场景
- 存储对象：
HMSET user {userId}:name alai {userId}:balance 1888
HMSET user 1:name zhuge 1:balance 1888
HMGET user 1:name 1:balance
- 购物车
用redis维护用户的购物车信息，可以进行如下设值
● 以用户id为key
● 商品id为field
● 商品数量为value
# 添加商品
hset car:1001 10088 1 # 其中1001为用户id 10088为商品id 1为要添加的商品数量
# 商品数量增加
hincrby cart:1001 10088 1
# 查询商品总数
hlen car:1001
# 删除商品
hdel car:1001 10088
# 获取购物车中所有的商品
hgetall cart:1001
优点：
- 同类数据归类整合
- 相比string操作消耗内存与cpu更小
- 相比string储存更节省空间
缺点：
- 过期功能不能使用在field上，只能用在key上
- Redis集群架构下不适合大规模使用（数据很多的情况下，hash存储可能出现数据量偏移）
List结构
LPUSH key value [value ...] //将一个或多个值value插入到key列表的表头(最左边)
RPUSH key value [value ...] //将一个或多个值value插入到key列表的表尾(最右边)
LPOP key //移除并返回key列表的头元素
RPOP key //移除并返回key列表的尾元素
LRANGE key start stop //返回列表key中指定区间内的元素，区间以偏移量start和stop指定
BLPOP key [key ...] timeout //从key列表表头弹出一个元素，若列表中没有元素，阻塞等待
BRPOP key [key ...] timeout //从key列表表尾弹出一个元素，若列表中没有元素，阻塞等timeout秒
应用场景
- 微博和公众号的消息推送
# MacTalk发微博，消息ID为10086
LPUSH msg:{关注人-ID} 10086
# 查看最新5条发送信息
LRANGE msg:{关注人-ID} 0 5
Set结构
常用命令
SADD key member [member ...] //往集合key中存入元素，元素存在则忽略，若key不存在则新增
SREM key member [member ...] //从集合key中删除元素
SMEMBERS key //获取集合key中所有元素
SCARD key //获取集合key的元素个数
SISMEMBER key member //判断member元素是否存在于集合key中
SRANDMEMBER key [count] //从集合key中随机选出count个元素，元素不从key中删除
SPOP key [count] //从集合key中随机选出count个元素，元素从key中删除
运算操作
SINTER key [key ...] //交集运算
SINTERSTORE destination key [key ..] //将交集结果存入新集合destination中
SUNION key [key ..] //并集运算
SUNIONSTORE destination key [key ...] //将并集结果存入新集合destination中
SDIFF key [key ...] //差集运算
SDIFFSTORE destination key [key ...] //将差集结果存入新集合destination中
应用场景
- 微信抽奖小程序
# 点击参与抽奖加入集合
SADD key {userlD}
# 查看参与抽奖所有用户
SMEMBERS key
# 抽取count名中奖者(不移除集合中元素)
SRANDMEMBER key [count]
# 抽取count名中奖者(移除集合中的元素)
SPOP key [count]
- 点赞、收藏、标签场景
# 点赞
SADD like:{消息ID} {用户ID}
# 取消点赞
SREM like:{消息ID} {用户ID}
# 检查用户是否点赞过
SISMEMBER like:{消息ID} {用户ID}
# 获取点赞的用户列表
SMEMBERS like:{消息ID}
# 获取点赞用户数
SCARD like:{消息ID}
集合操作
# 三个集合的交集
SINTER set1 set2 set3 -> { c }
# 三个集合的并集
SUNION set1 set2 set3 -> { a,b,c,d,e }
# 以第1个集合为基准 跟其他集合不相同的元素
SDIFF set1 set2 set3 -> { a }
- 集合操作实现微博微信关注模型
# 张三关注的人
zhangsanSet ->{lisi,wangwu,cuihua}
# 李四关注的人
lisiSet -> {zhangsan,cuihua,wangwu,xiaohong}
# 小红关注的人
xiaohongSet -> {zhangsan,lisi,wangwu,heimazi}
# 张三和李四共同关注的人
SINTER zhangsanSet lisiSet ->{cuihua,wangwu}
# 张三到李四的主页 看到 “我关注的人也关注他（李四）” :
SISMEMBER wangwuSet lisi
SISMEMBER cuihuaSet lisi
# 我可能认识的人 (在张三访问了李四主页后的展示)
SDIFF lisiSet zhangsanSet ->{cuihua,xiaohong}
Zset结构
常用命令
ZADD key score member [[score member]…] //往有序集合key中加入带分值元素
ZREM key member [member …] //从有序集合key中删除元素
ZSCORE key member //返回有序集合key中元素member的分值
ZINCRBY key increment member //为有序集合key中元素member的分值加上increment
ZCARD key //返回有序集合key中元素个数
ZRANGE key start stop [WITHSCORES] //正序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES]//倒序获取有序集合key从start下标到stop下标的元素
集合操作
ZUNIONSTORE destkey numkeys key [key ...] //并集计算
ZINTERSTORE destkey numkeys key [key …] //交集计算
应用场景
# 点击新闻
ZINCRBY hotNews:20190819 1
# 展示当日排行前十
ZREVRANGE hotNews:20190819 0 10 WITHSCORES
# 七日搜索榜单计算
ZUNIONSTORE hotNews:20190813-20190819 7
hotNews:20190813 hotNews:20190814... hotNews:20190819
# 展示七日排行前十
ZREVRANGE hotNews:20190813-20190819 0 10 WITHSCORES
bitmap位图类型
bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某
个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
常用命令：setbit 、 getbit 、 bitcount 、 bitop
应用场景
适合需要保存状态信息（比如是否签到、是否登录…）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
# SETBIT 会返回之前位的值（默认是 0）这里会生成 7 个位
127.0.0.1:6379> setbit mykey 7 1
(integer) 0
127.0.0.1:6379> setbit mykey 7 0
(integer) 1
127.0.0.1:6379> getbit mykey 7
(integer) 0
127.0.0.1:6379> setbit mykey 6 1
(integer) 0
127.0.0.1:6379> setbit mykey 8 1
(integer) 0
# 通过 bitcount 统计被被设置为 1 的位的数量。
127.0.0.1:6379> bitcount mykey
使用场景一：用户行为分析 很多网站为了分析你的喜好，需要研究你点赞过的内容。
# 记录你喜欢过 001 号小姐姐
127.0.0.1:6379> setbit beauty_girl_001 uid 1
使用场景二：统计活跃用户
面试题：现在系统有亿级的活跃用户，为了增强用户粘性，该如何实现签到、日活统计
使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1
那么该如果计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只有有一天在线就称为活跃)，这是就用到了BITOP命令
对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
# BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数
BITOP operation destkey key [key ...]
初始化数据
127.0.0.1:6379> setbit 20210308 1 1
(integer) 0
127.0.0.1:6379> setbit 20210308 2 1
(integer) 0
127.0.0.1:6379> setbit 20210309 1 1
(integer) 0
统计 20210308~20210309 总活跃用户数: 1
127.0.0.1:6379> bitop and desk1 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk1
(integer) 1
统计 20210308~20210309 在线活跃用户数: 2
127.0.0.1:6379> bitop or desk2 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk2
(integer) 2
geo地理位置类型
Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维
坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬
度Hash等常见操作
应用场景：附近的人、摇一摇、附近的车、附近银行站点查询
GEO常用命令
Tips：
在学习geo命令时会使用到经纬度坐标信息，可以在百度地图的拾取坐标系统中获取测试坐标信息，网址：http://api.map.baidu.com/lbsapi/getpoint/index.html
geoadd命令
为了进行地理位置相关操作， 我们首先需要将具体的地理位置记录起来， 这一点可以通过执行 geoadd
命令来完成， 该命令的基本格式如下：
GEOADD location-set longitude latitude name [longitude latitude name ...]
此命令用于添加位置信息到集合中
以下代码展示了如何通过 GEOADD 命令， 将武汉、襄阳、宜昌、枝江、咸宁等数个湖北省的市添加到位置集合 hubeiCities 集合里面
geoadd hubeiCities 114.32538 30.534535 wuhan
geoadd hubeiCities 112.161882 32.064505 xiangyang 111.305197 30.708127 yichang
111.583717 30.463363 zhijiang 114.295174 29.885892 xianning
getpos命令
此命令用于根据输入的位置名称获取位置的坐标信息，基本语法如下
GEOPOS location-set name [name ...]
geopos hubeiCities xiangyang
--结果如下【1为经度 2为纬度】
1) "112.16188341379165649"
2) "32.06450528704699821"
geopos hubeiCities xiangyang wuhan
--襄阳的经纬度
1) 1) "112.16188341379165649"
2) "32.06450528704699821"
--武汉的经纬度
2) 1) "114.32538002729415894"
2) "30.53453492166421057"
geodist命令
此命令用于计算两个位置之间的距离，基本语法如下
GEODIST location-set location-x location-y [unit]
可选参数 unit 用于指定计算距离时的单位， 它的值可以是以下单位的其中一个：
m 表示单位为米。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。
案例：分别以默认距离单位和指定距离单位计算襄阳和武汉的距离
--不指定距离单位
127.0.0.1:6381> geodist hubeiCities xiangyang wuhan
"266889.7642"
--指定距离单位km
127.0.0.1:6381> geodist hubeiCities xiangyang wuhan km
"266.8898"
georadius命令和georadiusbymember命令
这两个命令都可以用于获取指定范围内的元素，也即查找特定范围之内的其他存在的地点。
比如找出地点A范围200米之内的所有地点，找出地点B范围50公里之内的所有地点等等。
这两个命令的作用一样， 只是指定中心点的方式不同： georadius 使用用户给定的经纬度作为计算范围时的中心点， 而 georadiusbymember 则使用储存在位置集合里面的某个地点作为中心点。
以下是这两个命令的基本语法
GEORADIUS location-set longitude latitude radius m|km|ft|mi [WITHCOORD]
[WITHDIST] [ASC|DESC] [COUNT count]
GEORADIUSBYMEMBER location-set location radius m|km|ft|mi [WITHCOORD] [WITHDIST]
[ASC|DESC] [COUNT count]
这两个命令的各个参数的意义如下：
m|km|ft|mi 指定的是计算范围时的单位；
如果给定了WITHCOORD，那么在返回匹配的位置时会将位置的经纬度一并返回；
如果给定了WITHDIST ， 那么在返回匹配的位置时会将位置与中心点之间的距离一并返回；
在默认情况下， GEORADIUS 和 GEORADIUSBYMEMBER 的结果是未排序的， ASC 可以让查找结果根据距离从近到远排序， 而 DESC 则可以让查找结果根据从远到近排序；
COUNT参数用于指定要返回的结果数量。
下面通过案例分别演示georadius命令和georadiusbymember命令
GEORADIUS案例：
在hubeiCities位置集合中查找距离经纬度为112.927076 28.235653（长沙）500km以内的位置信息，
查找结果中应包含不超过5个位置的坐标信息，距离信息，并按距离由近到远排序。
127.0.0.1:6381> georadius hubeiCities 112.927076 28.235653 500 km withcoord
withdist asc count 5
-- 咸宁 距离目标位置226.67公里
1) 1) "xianning"
2) "226.6716"
3) 1) "114.29517298936843872"
2) "29.88589217282589772"
-- 枝江 距离目标位置279.91公里
2) 1) "zhijiang"
2) "279.9154"
3) 1) "111.58371716737747192"
2) "30.46336248623112652"
-- 武汉 距离目标位置289.38公里
3) 1) "wuhan"
2) "289.3798"
3) 1) "114.32538002729415894"
2) "30.53453492166421057"
-- 宜昌 距离目标位置316.68公里
4) 1) "yichang"
2) "316.6777"
3) 1) "111.30519658327102661"
2) "30.70812783498269738"
-- 襄阳 距离目标位置432.18公里
5) 1) "xiangyang"
2) "432.1767"
3) 1) "112.16188341379165649"
2) "32.06450528704699821"
GEORADIUSBYMEMBER案例：
在hubeiCities位置集合中查找距离襄阳200km以内的位置信息【这里指定的目标位置只能是hubeiCities中存在的位置，而不能指定位置坐标】，查找结果中应包含不超过2个位置的坐标信息，距离信息，并按距离由远到近排序。
查询代码如下：
127.0.0.1:6381> georadiusbymember hubeiCities xiangyang 200 km withcoord
withdist desc count 2
-- 枝江 距襄阳186.38km
1) 1) "zhijiang"
2) "186.3784"
3) 1) "111.58371716737747192"
2) "30.46336248623112652"
-- 宜昌 距襄阳171.40km
2) 1) "yichang"
2) "171.3950"
3) 1) "111.30519658327102661"
2) "30.70812783498269738"
其他常用命令
help
查看命令得查考文档
127.0.0.1:6379> help set
SET key value [EX seconds|PX milliseconds|EXAT timestamp|PXAT milliseconds-timestamp|KEEPTTL] [NX|XX] [GET]
summary: Set the string value of a key
since: 1.0.0
group: string
127.0.0.1:6379> help @set
SADD key member [member ...]
summary: Add one or more members to a set
since: 1.0.0
SCARD key
summary: Get the number of members in a set
since: 1.0.0
SDIFF key [key ...]
summary: Subtract multiple sets
since: 1.0.0
SDIFFSTORE destination key [key ...]
summary: Subtract multiple sets and store the resulting set in a key
since: 1.0.0
SINTER key [key ...]
summary: Intersect multiple sets
since: 1.0.0
SINTERSTORE destination key [key ...]
summary: Intersect multiple sets and store the resulting set in a key
since: 1.0.0
SISMEMBER key member
summary: Determine if a given value is a member of a set
since: 1.0.0
SMEMBERS key
summary: Get all the members in a set
since: 1.0.0
SMISMEMBER key member [member ...]
summary: Returns the membership associated with the given elements for a set
since: 6.2.0
SMOVE source destination member
summary: Move a member from one set to another
since: 1.0.0
SPOP key [count]
summary: Remove and return one or multiple random members from a set
since: 1.0.0
SRANDMEMBER key [count]
summary: Get one or multiple random members from a set
since: 1.0.0
SREM key member [member ...]
summary: Remove one or more members from a set
since: 1.0.0
SSCAN key cursor [MATCH pattern] [COUNT count]
summary: Incrementally iterate Set elements
since: 2.8.0
SUNION key [key ...]
summary: Add multiple sets
since: 1.0.0
SUNIONSTORE destination key [key ...]
summary: Add multiple sets and store the resulting set in a key
since: 1.0.0
scan
SCAN cursor [MATCH pattern] [COUNT count]
scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。
如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的。
127.0.0.1:6379> help scan
SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]
summary: Incrementally iterate the keys space
since: 2.8.0
group: generic
127.0.0.1:6379> scan 0 match name*
1) "0"
2) 1) "name"
2) "name5"
3) "name3"
4) "name7"
5) "name9"
6) "name8"
7) "name6"
8) "name4"
9) "name2"
info
查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:
Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息
127.0.0.1:6379> help info
INFO [section]
summary: Get information and statistics about the server
since: 1.0.0
group: server
127.0.0.1:6379> info
# Server
redis_version:6.2.6
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:366abd42dd8e835e
redis_mode:standalone
os:Linux 3.10.0-1160.11.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:11383
process_supervised:no
run_id:b0cd72bf94e42a7b4c3060b2ac1d9dbdaeb5f0a1
tcp_port:6379
server_time_usec:1639613720733391
uptime_in_seconds:259211
uptime_in_days:3
hz:10
configured_hz:10
lru_clock:12223768
executable:/usr/local/developer/redis/single_redis/redis-6.2.6/src/redis-server
config_file:/usr/local/developer/redis/single_redis/redis-6.2.6/redis.conf
io_threads_active:0
# Memory
used_memory:874784
used_memory_human:854.28K
used_memory_rss:9609216
used_memory_rss_human:9.16M
used_memory_peak:3928792
used_memory_peak_human:3.75M
used_memory_peak_perc:22.27%
used_memory_overhead:831304
used_memory_startup:810256
used_memory_dataset:43480
used_memory_dataset_perc:67.38%
allocator_allocated:918584
allocator_active:1196032
allocator_resident:3571712
total_system_memory:3973308416
total_system_memory_human:3.70G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.30
allocator_frag_bytes:277448
allocator_rss_ratio:2.99
allocator_rss_bytes:2375680
rss_overhead_ratio:2.69
rss_overhead_bytes:6037504
mem_fragmentation_ratio:11.55
mem_fragmentation_bytes:8777176
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:20520
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0
# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:8
rdb_bgsave_in_progress:0
rdb_last_save_time:1639612880
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:2256896
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0
# Stats
total_connections_received:207
total_commands_processed:100037
instantaneous_ops_per_sec:0
total_net_input_bytes:4503497
total_net_output_bytes:574039
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:2264
evicted_keys:0
keyspace_hits:1
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:526
total_forks:3
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:160
dump_payload_sanitizations:0
total_reads_processed:100396
total_writes_processed:100189
io_threaded_reads_processed:0
io_threaded_writes_processed:0
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:4a1e1bd6aed8fd6abbb4a698705848bdff201afb
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# CPU
used_cpu_sys:69.649760
used_cpu_user:94.304227
used_cpu_sys_children:0.003025
used_cpu_user_children:0.003087
used_cpu_sys_main_thread:69.644654
used_cpu_user_main_thread:94.300740
# Modules
# Errorstats
errorstat_ERR:count=160
# Cluster
cluster_enabled:0
# Keyspace
db0:keys=10,expires=0,avg_ttl=0
其中的参数说明：
# Clients
connected_clients:1 # 正在连接得客户端
maxclients:10000 # 允许连接得最大客户端数量
# Stats
instantaneous_ops_per_sec:0 # 每秒执行多少次指令
# Memory
used_memory:874784 # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内存
used_memory_human:854.28K # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内
used_memory_rss:9609216 # 向操作系统申请的内存大小(Mb)（这个值一般是大于used_memory的，因为Redis的内存分配策略会产生内存碎片）
used_memory_rss_human:9.16M # redis的内存消耗峰值(byte)
used_memory_peak:3928792 # redis的内存消耗峰值(KB)
used_memory_peak_human:3.75M
maxmemory:0 # 配置中设置的最大可使用内存值(byte),默认0,不限制
maxmemory_human:0B
maxmemory_policy:noeviction 当达到maxmemory时的淘汰策略
