文章目录
概要
redis常用的5种不同数据结构类型之间的映射如下：
| 结构类型 | 结构存储的值 | 结构的读写能力 |
|---|---|---|
| STRING | 可以是字符串、整数或者浮点数 | key-value形式；对整数和浮点数执行自增或者自减操作 |
| LIST | 一个链表，链表上的节点都包含了字符串 | 链表两端插入或者弹出；对链表进行修建；读取单个或者多个元素；根据值查找或者删除 |
| SET | 元素不重复、无序的 collection | 添加、获取、删除单个元素；检查元素是否存在；计算交集、并集、差集；从集合中随机取 |
| HASH | HASH 包含字符串的无序散列表 | 添加、获取、移除单个键值对；获取所有键值对 |
| ZSET(有序集合) | 字符串成员与浮点数分值之间的有序映射，元素的排列顺序由分值决定 | 添加、获取、删除单个元素；根据分值范围(range)或者成员来获取元素 |
String结构
常用命令
java
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 设置一个键的过期时间(秒)原子加减
java
INCR key 将key中存储的值加1
DECR key 将key中存储的值减1
INCRBY key increment 将key中存储的值增加increment
DECRBY key decrement 将key中存储的值减少increment应用场景举例：
- 如需要往redis中存储一个对象（数据库中的对象，也就是表中一行数据）
有两种方式：
java
# 方式一
SET user:1 value(json格式数据) # 将每一行数据json后 再进行存储 其中1表示这条数据的id
# 方式二
MSET user:1:name alai user:1:balance 1888 # 使用批量设值的方式
MGET user:1:name user:1:balance- 计数器
比如，文章的阅读量
java
INCR article:readcount:{文章id}
GET article:readcount:{文章id}- 分布式id
java
INCRBY orderId 1000 //redis批量生成序列号提升性能 先批量生成 存储在本地服务器Hash结构
常用命令
java
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中所有的键值原子操作
java
HINCRBY HINCRBY key field increment //为哈希表key中field键的值加上增量increment应用场景
- 存储对象：
java
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
shell
# 添加商品
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结构
java
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秒
应用场景
- 微博和公众号的消息推送
java
# MacTalk发微博，消息ID为10086
LPUSH msg:{关注人-ID} 10086
# 查看最新5条发送信息
LRANGE msg:{关注人-ID} 0 5Set结构
常用命令
java
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中删除运算操作
java
SINTER key [key ...] //交集运算
SINTERSTORE destination key [key ..] //将交集结果存入新集合destination中
SUNION key [key ..] //并集运算
SUNIONSTORE destination key [key ...] //将并集结果存入新集合destination中
SDIFF key [key ...] //差集运算
SDIFFSTORE destination key [key ...] //将差集结果存入新集合destination中应用场景
- 微信抽奖小程序
shell
# 点击参与抽奖加入集合
SADD key {userlD}
# 查看参与抽奖所有用户
SMEMBERS key
# 抽取count名中奖者(不移除集合中元素)
SRANDMEMBER key [count]
# 抽取count名中奖者(移除集合中的元素)
SPOP key [count]- 点赞、收藏、标签场景
java
# 点赞
SADD like:{消息ID} {用户ID}
# 取消点赞
SREM like:{消息ID} {用户ID}
# 检查用户是否点赞过
SISMEMBER like:{消息ID} {用户ID}
# 获取点赞的用户列表
SMEMBERS like:{消息ID}
# 获取点赞用户数
SCARD like:{消息ID}集合操作
shell
# 三个集合的交集
SINTER set1 set2 set3 -> { c }
# 三个集合的并集
SUNION set1 set2 set3 -> { a,b,c,d,e }
# 以第1个集合为基准 跟其他集合不相同的元素
SDIFF set1 set2 set3 -> { a }- 集合操作实现微博微信关注模型
java
# 张三关注的人
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结构
常用命令
shell
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下标的元素
集合操作
java
ZUNIONSTORE destkey numkeys key [key ...] //并集计算
ZINTERSTORE destkey numkeys key [key ...] //交集计算应用场景
shell
# 点击新闻
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 WITHSCORESbitmap位图类型
bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某
个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
常用命令：setbit 、 getbit 、 bitcount 、 bitop
应用场景
适合需要保存状态信息（比如是否签到、是否登录...）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
java
# 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使用场景一：用户行为分析 很多网站为了分析你的喜好，需要研究你点赞过的内容。
shell
# 记录你喜欢过 001 号小姐姐
127.0.0.1:6379> setbit beauty_girl_001 uid 1使用场景二：统计活跃用户
面试题：现在系统有亿级的活跃用户，为了增强用户粘性，该如何实现签到、日活统计
使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1
那么该如果计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只有有一天在线就称为活跃)，这是就用到了BITOP命令
shell
对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
# BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数
BITOP operation destkey key [key ...]初始化数据
shell
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
shell
127.0.0.1:6379> bitop and desk1 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk1
(integer) 1统计 20210308~20210309 在线活跃用户数: 2
shell
127.0.0.1:6379> bitop or desk2 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk2
(integer) 2geo地理位置类型
Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维
坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬
度Hash等常见操作
应用场景：附近的人、摇一摇、附近的车、附近银行站点查询
GEO常用命令
Tips：
在学习geo命令时会使用到经纬度坐标信息，可以在百度地图的拾取坐标系统中获取测试坐标信息，网址：http://api.map.baidu.com/lbsapi/getpoint/index.html
geoadd命令
为了进行地理位置相关操作， 我们首先需要将具体的地理位置记录起来， 这一点可以通过执行 geoadd
命令来完成， 该命令的基本格式如下：
java
GEOADD location-set longitude latitude name [longitude latitude name ...]此命令用于添加位置信息到集合中
以下代码展示了如何通过 GEOADD 命令， 将武汉、襄阳、宜昌、枝江、咸宁等数个湖北省的市添加到位置集合 hubeiCities 集合里面
java
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 xianninggetpos命令
此命令用于根据输入的位置名称获取位置的坐标信息，基本语法如下
java
GEOPOS location-set name [name ...]
java
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命令
此命令用于计算两个位置之间的距离，基本语法如下
java
GEODIST location-set location-x location-y [unit]可选参数 unit 用于指定计算距离时的单位， 它的值可以是以下单位的其中一个：
m 表示单位为米。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。
案例：分别以默认距离单位和指定距离单位计算襄阳和武汉的距离
shell
--不指定距离单位
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 则使用储存在位置集合里面的某个地点作为中心点。
以下是这两个命令的基本语法
shell
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个位置的坐标信息，距离信息，并按距离由近到远排序。
shell
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个位置的坐标信息，距离信息，并按距离由远到近排序。
查询代码如下：
shell
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
查看命令得查考文档
shell
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.0scan
shell
SCAN cursor [MATCH pattern] [COUNT count]scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。
如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的。
shell
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 个块分别是:
java
Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息
shell
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其中的参数说明：
shell
# 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时的淘汰策略