Redis的核心数据结构以及高性能底层原理

一、Redis的单线程和高性能

Redis是单线程吗？
Redis实际意义上来说不是单线程的。Redis的单线程是指网络IO键值对的读写以及执行命令是由一个线程完成的，但是异步删除、AOF文件重写、持久化以及集群的数据同步都是由其他线程来完成的。

Redis 单线程为什么还能这么快？
Redis的所有操作都是基于内存中实现的，执行的速度较快。而且使用一个线程来处理读写逻辑过程中，避免了上下文切换。所以Redis单线程还能很快的原因。
要注意的一点：正是因为Redis是单线程的，所以我们在使用Redis的时候需要注意那些可能引起Redis阻塞的操作，防止Redis的线程进入阻塞状态，导致Redis效率降低。

Redis 单线程如何处理那么多的并发客户端连接？
Redis是一个NIO模型。它将所有的请求放入一个队列中，一个一个地处理请求。通过文件事件分派器将请求发送给事件处理器也就是Redis的线程去处理请求。所以Redis单线程还可以处理很多的并发客户端连接。

Scan渐进式遍历键
SCAN cursor [MATCH pattern] [COUNT count]
scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。

注意：但是scan并非完美无瑕， 如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的。

SCAN cursor[游标] match 表达式 count 数量
SCAN扫描的数量并不是一次扫描符合表达式的次数，而是扫描所有key的次数。并不是符合条件的结果数量。每次返回会返回下次游标的值已经扫描符合条件的结果，然后继续安装给的游标的值继续扫描一直到返回的游标值为0.所有的返回结果加起来就是我们要获取的结果。–它就是分开获取所有符合条件的key，如果使用keys *可能key太多了，就会造成阻塞。

127.0.0.1:6379[5]> keys *
1) "lpc1"
2) "lpc3"
3) "lpc7"
4) "lpc6"
5) "lpc4"
6) "lpc2"
7) "lpc8"
8) "lpc9"
9) "lpc5"
127.0.0.1:6379[5]> SCAN 0 lpc* 3
(error) ERR syntax error
127.0.0.1:6379[5]> SCAN 0 match lpc* count 3 
1) "14"
2) 1) "lpc4"
   2) "lpc2"
   3) "lpc6"
127.0.0.1:6379[5]> SCAN 14 match lpc* count 3 
1) "13"
2) 1) "lpc1"
   2) "lpc3"
   3) "lpc7"
127.0.0.1:6379[5]> SCAN 13 match lpc* count 3 
1) "0"
2) 1) "lpc8"
   2) "lpc9"
   3) "lpc5"
127.0.0.1:6379[5]> 

二、Redis的核心数据结构

String类型
常用的操作

SET  key  value 			//存入字符串键值对
MSET  key  value [key value ...] 	//批量存储字符串键值对
SETNX  key  value 		//存入一个不存在的字符串键值对
GET  key 			//获取一个字符串键值
MGET  key  [key ...]	 	//批量获取字符串键值
DEL  key  [key ...] 		//删除一个键
EXPIRE  key  seconds 		//设置一个键的过期时间(秒)

原子加减

INCR  key 			//将key中储存的数字值加1
DECR  key 			//将key中储存的数字值减1
INCRBY  key  increment 		//将key所储存的值加上increment
DECRBY  key  decrement 	//将key所储存的值减去decrement

对象缓存

1.set user:1 {name:lupengcheng,age:20}
2.set user1:name lupengcheng set user:1:age 20

分布式锁

SETNX  product:10001  true 		//返回1代表获取锁成功
SETNX  product:10001  true 		//返回0代表获取锁失败
。。。执行业务操作
DEL  product:10001			//执行完业务释放锁

SET product:10001 true  ex  10  nx	//防止程序意外终止导致死锁

业务场景
1.文章的阅读量

//设置文章的key
set actitle:1 0

//每次点击一次阅读功能文章的阅读量+1
incrby arcitle:1 1

//取出id为1的文章的阅读量
get arcitle:1

2.集群的session共享

spring session + redis的session共享--单点登录

3.分布式全局序列号

分布式集群下，一张订单表可能会分库分表。这样使用mysql提供的主键自增功能就无法使用。我们可以使用redis生成全局序列号
set orderId 0

每次需要一个订单的id就执行incrby命令,这样可以获取到全局序列号
incrby orderId 1

问题：可能有几千万个订单需要生成，那么redis的压力会特别大。所以我们可以一次性取1000条id到内存中。用完了再取。

hash类型
Hash常用操作

HSET  key  field  value 			//存储一个哈希表key的键值
HSETNX  key  field  value 		//存储一个不存在的哈希表key的键值
HMSET  key  field  value [field value ...] 	//在一个哈希表key中存储多个键值对
HGET  key  field 				//获取哈希表key对应的field键值
HMGET  key  field  [field ...] 		//批量获取哈希表key中多个field键值
HDEL  key  field  [field ...] 		//删除哈希表key中的field键值
HLEN  key				//返回哈希表key中field的数量
HGETALL  key				//返回哈希表key中所有的键值

HINCRBY  key  field  increment 		//为哈希表key中field键的值加上增量increment

对象缓存

HMSET user 1:name jack 1:age 20 1:gender male
hmget user 1:name 1:age 1:gender
1) "jack"
2) "20"
3) "male"  

Hash应用场景
购物车

电商购物车功能实现：
1.以用户的id为key–car用户Id
2.以商品的id为field
3.商品的数量为value
例如：hset car:1 good:1 2

功能实现：
1.商品数量增加：HINCRBY car:1 good:1 1—(integer) 3
2.商品数量减少：HINCRBY car:1 good:1 -1—(integer) 2
3.删除商品：HDEL car:1 good:1
4.全选：HGETALL car:1
1) “good:2”
2) “2”
3) “good:3”
4) “3”
5.购物车的商品数量：HLEN car:1
(integer) 2

Hash结构优缺点
优点
1）同类数据归类整合储存，方便数据管理
2）相比string操作消耗内存与cpu更小
3）相比string储存更节省空间

缺点
过期功能不能使用在field上，只能用在key上
Redis集群架构下不适合大规模使用

List结构
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列表表头弹出一个元素，若列表中没有元素，
//阻塞等待timeout秒,如果timeout=0,一直阻塞等待
BRPOP  key  [key ...]  timeout 	//从key列表表尾弹出一个元素，若列表中没有元素，
//阻塞等待timeout秒,如果timeout=0,一直阻塞等待

List应用场景
微博和微信公号消息流


例如jack关注了大V【curry】
如果curry发布了一条动态，那么jack在看朋友圈的时候应该刷到curry发的动态。如果多条动态则按时间顺序排序【最新的在前面】–满足list的栈结构
LPUSH mesg:{用户Id} 动态id

如果大Vjames也发布了一条动态，也要加入jack的信息集合中
LPUSH mesg:{用户Id} 动态id

当jack打开朋友圈，执行LRANGE mesg:用户Id start end-查看最新的动态

LPUSH mesg:1 mesg1 mesg2 mesg3 mesg4 mesg5
(integer) 5
127.0.0.1:6379[2]> LRANGE mesg:1 0 3
1) "mesg5"
2) "mesg4"
3) "mesg3"
4) "mesg2"

Set结构
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中删除

Set运算操作

SINTER  key  [key ...] 				//交集运算
SINTERSTORE  destination  key  [key ..]		//将交集结果存入新集合destination中
SUNION  key  [key ..] 				//并集运算
SUNIONSTORE  destination  key  [key ...]		//将并集结果存入新集合destination中
SDIFF  key  [key ...] 				//差集运算
SDIFFSTORE  destination  key  [key ...]		//将差集结果存入新集合destination中

Set应用场景

抽奖的场景：
点击参与抽奖：SADD active:1 用户ID
查看全部：SMEMBERS active:1

参与抽奖的用户加入到活动集合中，如果只有一轮抽奖那么可以使用SRANGE随机抽取中奖用户；如果抽奖分为一等奖 二等奖 三等奖的话使用SPOP每次将随机的中奖用户删除进行下一轮的抽奖环节

//参与活动1抽奖的用户为10个
127.0.0.1:6379[3]> SMEMBERS active:1
 1) "1"
 2) "2"
 3) "3"
 4) "4"
 5) "5"
 6) "6"
 7) "7"
 8) "213"
 9) "223"
10) "2112"

//只抽取3个中奖用户--随机的，每次都不一样
127.0.0.1:6379[3]> SRANDMEMBER active:1 3
1) "213"
2) "1"
3) "3"
127.0.0.1:6379[3]> SRANDMEMBER active:1 3
1) "213"
2) "2"
3) "2112"
127.0.0.1:6379[3]> SRANDMEMBER active:1 3
1) "4"
2) "223"
3) "2"
127.0.0.1:6379[3]> SRANDMEMBER active:1 3
1) "213"
2) "4"
3) "2"


//抽取3个三等奖
127.0.0.1:6379[3]> SPOP active:1 3
1) "3"
2) "2"
3) "4"

//抽取2个二等奖
127.0.0.1:6379[3]> SPOP active:1 2
1) "2112"
2) "5"

//抽取1个一等奖
127.0.0.1:6379[3]> SPOP active:1 1
1) "213"

//剩余用户
127.0.0.1:6379[3]> SMEMBERS active:1
1) "1"
2) "6"
3) "7"
4) "223"

1、点赞
SADD like:消息ID 用户ID

2、取消点赞
SREM like:消息ID 用户ID

3、检查用户是否点赞–如果点赞了那小爱心会变为红色
SISMEMBER like:消息ID 用户ID

4、获取点赞的用户列表
SMEMBERS like:消息ID

5、获取点赞的用户数量
SCARD like:消息ID

6、本人查看评论列表
当一个好友给“我”的动态进行评论，评论ID会记录在“我” 的comments:消息ID集合中，然后SMEMBERS comments:消息ID获得所有评论

集合操作

集合操作实现微博微信关注模型[很重要]

//jack关注的人-1
Focus:jackId = {merry,james}

//merry关注的人-2
Focus:merryId = {jack,tom}

//tom关注的人-3
Focus:tomId = {merry}

//james关注的人-4
Focus:jamesId = {merry,jack}

//【微关系--共同关注功能】假如我是jack，我和james共同关注的人：
SINTER Focus:jackId Focus:jamesId = {merry}
    SINTER focus:1 focus:4
    1) "2"

//可能认识的人--我关注的人，他关注的人是我可能认识的人[这里加入这个人是merry-如果复杂一点可以将jack的所有关注的人的关注的人集合一起取差集]
SDIFF focus:2 focus:1 //当然这里除去自己
    1) "1"
    2) "3"

//我关注的人也关注她--1为true 0为false
SISMEMBER focus:4 2

ZSet有序集合结构
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下标的元素

Zset集合操作

ZUNIONSTORE destkey numkeys key [key ...] 	//并集计算
ZINTERSTORE destkey numkeys key [key …]	//交集计算

Zset应用场景

Zset集合操作实现排行榜
1）点击新闻
ZADD hotNew:20210801 1 守护香港
2）展示当日排行前十
ZREVRANGE hotNew:20210801 0 9
3）七日搜索榜单计算

ZUNIONSTORE hotNew:20210720-23 4  hotNew:20210720 hotNew:20210721 hotNew:20210722 hotNew:20210723
(integer) 6

127.0.0.1:6379[4]> ZREVRANGE hotNew:20210720-23 0 -1 WITHSCORES
 1) "wyf"
 2) "363562"
 3) "dmz"
 4) "40045"
 5) "lpc"
 6) "13466"
 7) "ym"
 8) "5246"
 9) "hh"
10) "4800"
11) "wyb"
12) "2000"

展示七日排行前十

//展示四日排行前5
127.0.0.1:6379[4]> ZREVRANGE hotNew:20210720-23 0 4 
1) "wyf"
2) "dmz"
3) "lpc"
4) "ym"
5) "hh"

总结

基本介绍了Redis的各种数据结构以及使用场景。这也只是一小部分的使用，有很多地方都可以使用到redis。不仅仅只有String哦。需要我们认真的思考决定使用哪种数据结构。