redis基本数据结构与应用

他叫阿来

于 2024-05-20 15:06:30 发布

阅读量1.1k

点赞数 16

分类专栏： redis实战文章标签： redis

本文链接：https://blog.csdn.net/weixin_42612223/article/details/139061011

版权

redis实战专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章目录

概要

在这里插入图片描述
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时的淘汰策略

他叫阿来

关注

16
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
redis基本数据结构与应用

scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。如果在scan的过程中如果有键的变化（增加、删除、修改），那么遍历效果可能会碰到如下问题：新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键，这些是我们在开发时需要考虑的。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬。
复制链接

扫一扫

专栏目录