热门标签
热门文章
- 1python 获取本机ipv6 （中国运营商）_python 获取ipv6地址
- 2文件扩展名大全_扩展名.pro和扩展名dfr
- 3win10下安装sql2000_win10安装sql2000
- 4在idea中使用git_idea利用git进行开发
- 5CondaHTTPError: HTTP 000 CONNECTION FAILED for url ＜https://repo.anaconda.co
- 6在新电脑安装Python3.12.2_python 3.12.2
- 706 - 分析docker run hello-world_hello world卡在pulling
- 8prometheus监控redis（无metric接口）_prometheus 监控非metrics_普罗米修斯监控redis
- 9腾讯云EdgeOne为什么能让客户降本增效？
- 10【Linux】进程通信实战 —— 进程池项目
当前位置: article > 正文
redis基本数据结构与应用
作者：不正经 | 2024-05-29 02:18:19
赞
踩
redis基本数据结构与应用
概要
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 设置一个键的过期时间(秒)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
原子加减
INCR key 将key中存储的值加1
DECR key 将key中存储的值减1
INCRBY key increment 将key中存储的值增加increment
DECRBY key decrement 将key中存储的值减少increment
- 1
- 2
- 3
- 4
应用场景举例：
- 如需要往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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 计数器
比如，文章的阅读量
INCR article:readcount:{文章id}
GET article:readcount:{文章id}
- 1
- 2
- 分布式id
INCRBY orderId 1000 //redis批量生成序列号提升性能 先批量生成 存储在本地服务器
- 1
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中所有的键值
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
原子操作
HINCRBY HINCRBY key field increment //为哈希表key中field键的值加上增量increment
- 1
应用场景
- 存储对象：
HMSET user {userId}:name alai {userId}:balance 1888
HMSET user 1:name zhuge 1:balance 1888
HMGET user 1:name 1:balance
- 1
- 2
- 3
- 购物车
用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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
优点：
- 同类数据归类整合
- 相比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秒
- 1
- 2
- 3
- 4
- 5
- 6
- 7
应用场景
- 微博和公众号的消息推送
# MacTalk发微博，消息ID为10086
LPUSH msg:{关注人-ID} 10086
# 查看最新5条发送信息
LRANGE msg:{关注人-ID} 0 5
- 1
- 2
- 3
- 4
- 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中删除
- 1
- 2
- 3
- 4
- 5
- 6
- 7
运算操作
SINTER key [key ...] //交集运算
SINTERSTORE destination key [key ..] //将交集结果存入新集合destination中
SUNION key [key ..] //并集运算
SUNIONSTORE destination key [key ...] //将并集结果存入新集合destination中
SDIFF key [key ...] //差集运算
SDIFFSTORE destination key [key ...] //将差集结果存入新集合destination中
- 1
- 2
- 3
- 4
- 5
- 6
应用场景
- 微信抽奖小程序
# 点击参与抽奖加入集合
SADD key {userlD}
# 查看参与抽奖所有用户
SMEMBERS key
# 抽取count名中奖者(不移除集合中元素)
SRANDMEMBER key [count]
# 抽取count名中奖者(移除集合中的元素)
SPOP key [count]
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 点赞、收藏、标签场景
# 点赞
SADD like:{消息ID} {用户ID}
# 取消点赞
SREM like:{消息ID} {用户ID}
# 检查用户是否点赞过
SISMEMBER like:{消息ID} {用户ID}
# 获取点赞的用户列表
SMEMBERS like:{消息ID}
# 获取点赞用户数
SCARD like:{消息ID}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
集合操作
# 三个集合的交集
SINTER set1 set2 set3 -> { c }
# 三个集合的并集
SUNION set1 set2 set3 -> { a,b,c,d,e }
# 以第1个集合为基准 跟其他集合不相同的元素
SDIFF set1 set2 set3 -> { a }
- 1
- 2
- 3
- 4
- 5
- 6
- 集合操作实现微博微信关注模型
# 张三关注的人
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}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
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下标的元素
- 1
- 2
- 3
- 4
- 5
- 6
- 7
集合操作
ZUNIONSTORE destkey numkeys key [key ...] //并集计算
ZINTERSTORE destkey numkeys key [key …] //交集计算
- 1
- 2
应用场景
# 点击新闻
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
使用场景一：用户行为分析 很多网站为了分析你的喜好，需要研究你点赞过的内容。
# 记录你喜欢过 001 号小姐姐
127.0.0.1:6379> setbit beauty_girl_001 uid 1
- 1
- 2
使用场景二：统计活跃用户
面试题：现在系统有亿级的活跃用户，为了增强用户粘性，该如何实现签到、日活统计
使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1
那么该如果计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只有有一天在线就称为活跃)，这是就用到了BITOP命令
对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
# BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数
BITOP operation destkey key [key ...]
- 1
- 2
- 3
初始化数据
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
- 1
- 2
- 3
- 4
- 5
- 6
统计 20210308~20210309 总活跃用户数: 1
127.0.0.1:6379> bitop and desk1 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk1
(integer) 1
- 1
- 2
- 3
- 4
统计 20210308~20210309 在线活跃用户数: 2
127.0.0.1:6379> bitop or desk2 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk2
(integer) 2
- 1
- 2
- 3
- 4
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 ...]
- 1
此命令用于添加位置信息到集合中
以下代码展示了如何通过 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
- 1
- 2
- 3
getpos命令
此命令用于根据输入的位置名称获取位置的坐标信息，基本语法如下
GEOPOS location-set name [name ...]
- 1
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"
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
geodist命令
此命令用于计算两个位置之间的距离，基本语法如下
GEODIST location-set location-x location-y [unit]
- 1
可选参数 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"
- 1
- 2
- 3
- 4
- 5
- 6
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]
- 1
- 2
- 3
- 4
这两个命令的各个参数的意义如下：
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"
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
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"
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
其他常用命令
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
scan
SCAN cursor [MATCH pattern] [COUNT count]
- 1
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"
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
info
查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:
Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
其中的参数说明：
# 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时的淘汰策略
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/不正经/article/detail/640156
推荐阅读
相关标签
