当前位置:   article > 正文

redis基本数据结构与应用

redis基本数据结构与应用

概要

在这里插入图片描述
redis常用的5种不同数据结构类型之间的映射如下:

结构类型结构存储的值结构的读写能力
STRING可以是字符串、整数或者浮点数key-value形式;对整数和浮点数执行自增或者自减操作
LIST一个链表,链表上的节点都包含了字符串链表两端插入或者弹出;对链表进行修建;读取单个或者多个元素;根据值查找或者删除
SET元素不重复、无序的 collection添加、获取、删除单个元素;检查元素是否存在;计算交集、并集、差集;从集合中随机取
HASHHASH 包含字符串的无序散列表添加、获取、移除单个键值对;获取所有键值对
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

应用场景举例:

  1. 如需要往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
  1. 计数器
    比如,文章的阅读量
    在这里插入图片描述
INCR article:readcount:{文章id}
GET article:readcount:{文章id}
  • 1
  • 2
  1. 分布式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

应用场景

  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

在这里插入图片描述

  1. 购物车
    用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

在这里插入图片描述

应用场景

  1. 微博和公众号的消息推送
    在这里插入图片描述
    在这里插入图片描述
# MacTalk发微博,消息ID10086
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

应用场景

  1. 微信抽奖小程序
    在这里插入图片描述
# 点击参与抽奖加入集合
SADD key {userlD}
# 查看参与抽奖所有用户
SMEMBERS key	  
# 抽取count名中奖者(不移除集合中元素)
SRANDMEMBER key [count]
# 抽取count名中奖者(移除集合中的元素)
SPOP key [count]
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  1. 点赞、收藏、标签场景

在这里插入图片描述

# 点赞
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
  1. 集合操作实现微博微信关注模型
    在这里插入图片描述
# 张三关注的人
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 , 那么在返回匹配的位置时会将位置与中心点之间的距离一并返回;
在默认情况下, GEORADIUSGEORADIUSBYMEMBER 的结果是未排序的, 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
推荐阅读
相关标签
  

闽ICP备14008679号