Redis核心数据结构实战与高性能原理剖析

Redis核心数据结构实战与高性能原理剖析

1.redis安装步骤

1 下载地址：http://redis.io/download
2 安装步骤：
3 # 安装gcc
4 yum install gcc
5 # 把下载好的redis‐5.0.3.tar.gz放在/usr/local文件夹下，并解压
6 wget http://download.redis.io/releases/redis‐5.0.3.tar.gz
7 tar xzf redis‐5.0.3.tar.gz
8 cd redis‐5.0.3
9 # 进入到解压好的redis‐5.0.3目录下，进行编译与安装
10 make
11 
12 # 修改配置
13 daemonize yes #后台启动
14 protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
15 # 需要注释掉bind
16 #bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
17 # 启动服务
18 src/redis‐server redis.conf || ./redis-server
19 # 验证启动是否成功
20 ps ‐ef | grep redis
21 # 进入redis客户端
22 src/redis‐cli  || ./redis-cli
23 # 退出客户端 quit
24 # 退出redis服务：
25（1）ps -ef | grep redis
26（2）kill 进程号
27（3）src/redis‐cli shutdown

2.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

单值缓存

SET  key  value 	
GET  key 

对象缓存

 SET  user:1  value(json字符串数据)
 MSET  user:1:name  test   user:1:balance  1888   ---批量插入操作
 MGET  user:1:name   user:1:balance 	---批量获取操作

分布式锁

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

SET product:10001 true  ex  10  nx	// ---设置超时时间  防止程序意外终止导致死锁 

计数器

INCR article:readcount:{文章id}  	--- 记录文章阅读量
GET article:readcount:{文章id} 	--- 获取文章阅读量

Web集群session共享

spring session + redis实现session共享

分布式系统全局序列号 （数据库主键id）

INCRBY  orderId  1000		                //redis批量生成序列号（数据库自增id）提升性能 --当然在高并发的场景下使用redis做分布式系统全局主键自增 有点大材效用 并且太浪费redis 性能,我们可以每台机子一下子拿1000个，甚至更多存储本机内存，减                  
                                                //少和redis交互,当然这个只是一种分布式系统获取主键id的解决方案，弊端是如果服务器挂掉，拿过来的主键id就浪费了，对于那种对主键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  {userId}:name  zhuge  {userId}:balance  1888 ---存储操作
HMSET  user  1:name  test  1:balance  1888  ---存储操作
HMSET  user  1:name  zhangsan  1:balance  2888  ---修改操作
HMGET  user  1:name  1:balance   ---获取操作

注意：存储hash的时候，如果存在上百万，上千万的hash，bigkey是不适用于redis的，因为redis是单线程模型（仅指执行命令的操作是单线程，所有命令是由1个线程去执行的），如果获取这个大key的value的时候时间过长，那么其他的命令就会处于阻塞状态

电商购物车

1）以用户id为key
2）商品id为field
3）商品数量为value

购物车操作
cart:1001 1001是用户id cart是前缀  10088是商品id 1是商品数量
添加商品->hset cart:1001 10088 1
增加数量->hincrby cart:1001 10088 1
商品总数->hlen cart:1001
删除商品->hdel cart:1001 10088
获取购物车所有商品->hgetall cart:1001

Hash结构优缺点

优点
1）同类数据归类整合储存，方便数据管理
2）相比string操作消耗内存与cpu更小
3）相比string储存更节省空间
缺点
1）过期功能不能使用在field上，只能用在key上
2）Redis集群架构下不适合大规模使用  例如用户信息在一个hash里存储在集群中的一个节点上，或者说一个节点上出现大的hash结构就可能会发生数据倾斜，导致节点进入的请求过多，其他节点请求少。解决办法是通过规则衍生多个key，均匀存储在集群各个节点。

列表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,一直阻塞等待

应用场景：

常见数据结构：

Stack(栈) = LPUSH + LPOP  -- 先进后出的数据结构 用Lpush去插入的话 最先插入的值  lpop取的时候最后一个取出来
Queue(队列）= LPUSH + RPOP --先进先出 lpush最先插入的数据，rpop最先取出来
Blocking MQ(阻塞队列）= LPUSH + BRPOP 从key列表表尾弹出一个元素，若列表中没有元素，阻塞等待timeout秒

微博和公众号消息流：

在使用公众号和微博的时候，订阅或者关注一个用户的时候，该用户发布的消息是一个倒序的时间排序，也就是先进后出这样子，当然用数据库排序操作实现起来也不难，但在大数据量的情况下性能会有影响，用redis实现的话就容易的多，并且性能更高。

微博消息和微信公众号消息：

coder张关注了杨幂，迪丽热巴等大V
1）杨幂发微博，消息ID为10018
LPUSH  msg:{coder张-ID}  10018
2）迪丽热巴微博，消息ID为10086
LPUSH  msg:{coder张-ID} 10086
3）查看最新微博消息
LRANGE  msg:{coder张-ID}  0  4  --返回  10086，10018  先进后出
LRANGE  key  start  stop 返回列表key中指定区间内的元素，区间以偏移量start和stop指定

在大量粉丝的业务场景下，有两种发送消息的方案，一种是push，意思是优先主动向在线用户推送新消息，其他的不在线粉丝再慢慢推送消息，第二种是pull，消息发送至中间件，用户主动去拉取消息。缺点就是如果很关注很多大v，主动去拉取的话需要拉取许多大v消息，取到之后还需要进行排序。

集合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运算操作

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中

应用场景：

微信抽奖小程序：

1）点击参与抽奖加入集合； key是抽奖id
SADD key {userlD}
2）查看参与抽奖所有用户
SMEMBERS key	  
3）随机抽取count名中奖者 SRANDMEMBER key [count]命令不会删除中奖者  SPOP key [count] 命令会删除中奖者
SRANDMEMBER key [count] / SPOP key [count]

微信微博点赞，收藏，标签

注意：下列like:是key的前缀，命名规范 比如 sadd like:1 1 不是命令的一部分，不要误解。
1) 点赞
SADD  like:{消息ID}  {用户ID}
2) 取消点赞
SREM like:{消息ID}  {用户ID}
3) 检查用户是否点过赞
SISMEMBER  like:{消息ID}  {用户ID}
4) 获取点赞的用户列表
SMEMBERS like:{消息ID}
5) 获取点赞用户数 
SCARD like:{消息ID}

集合操作

set1 = a,b,c set2=b,c,d  set3= c,e,d
SINTER set1 set2 set3 -> { c }				--交集
SUNION set1 set2 set3 -> { a,b,c,d,e }		 --并集 = 去重后的合集
SDIFF set1 set2 set3 -> { a }                --差集 = 第一个集合去掉后边集合的并集

集合操作实现微博微信关注模型

1) 张三关注的人: 
zhangsanSet-> {wanger, wangwu}
2) 李四关注的人:
lisiSet--> {zhangsan, d, wanger, wangwu}
3) 王五关注的人: 
wangwuSet-> {zhangsan, f, h, g, wanger}
4) 张三和李四共同关注: 
SINTER zhangsanSet lisiSet -> {wanger, wangwu}
5) 张三关注的人也关注他(wanger): 
-- 1代表是 0代表否
SISMEMBER lisiSet wanger -> 1   
SISMEMBER wangwuSet wanger -> 1 
6) 我可能认识的人: 
SDIFF lisiSet zhangsanSet-> {zhangsan, d}

关系型数据库实现起来比较麻烦，redis实现起来更容易一些。

共同关注的人越多；爱好就越相近  比如说张三买了个电饭锅，那么相应的根据大数据推算，推算的逻辑可能就有共同关注的人这个逻辑，就会给你也推荐电饭锅。

集合操作实现电商商品筛选

注：brand os:android等都是key值或者是key值的前缀
SADD  brand:huawei  P40
SADD  brand:xiaomi  mi-10
SADD  brand:iPhone iphone12
SADD os:android  P40  mi-10
SADD cpu:brand:intel  P40  mi-10
SADD ram:8G  P40  mi-10  iphone12

SINTER  os:android  cpu:brand:intel  ram:8G ->  {P40，mi-10} --取交集

有序集合Zset

常用操作：

zset常用操作：

ZADD key score member [[score member]…]	//往有序集合key中加入带分值元素  socre分值是多少 就会将分值加多少
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集合操作实现排行榜：

1）点击新闻
ZINCRBY  hotNews:20190819  1  守护香港  --会对这个key的热度（分值）+1 排序的时候使用命令根据分值进行排序
2）展示当日排行前十
ZREVRANGE  hotNews:20190819  0  9  WITHSCORES 
3）七日搜索榜单计算（把7个key的数据 合并到新的key(hotNews:20190813-20190819)里边去,此处7代表7个key）
ZUNIONSTORE  hotNews:20190813-20190819  7 
hotNews:20190813  hotNews:20190814... hotNews:20190819
4）展示七日排行前十
ZREVRANGE hotNews:20190813-20190819  0  9  WITHSCORES

3.Redis的单线程和高性能

Redis是单线程吗？

Redis的单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的（仅指执行命令的操作是单线程，所有命令是由1个线程去执行的），这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

Redis单线程为什么还能这么快？

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis是单线程，所以要小心使用 Redis指令，对于那些耗时的指令(比如keys，要扫描整个redis存储的内存)，一定要谨慎使用，一不小心就可能会导致 Redis卡顿（执行命令是由单线程执行的，后续执行的命令会进行阻塞）。

Redis单线程如何处理那么多的并发客户端连接？

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

其他高级命令

keys：全量遍历键，用来列出所有满足特定正则字符串规则的key，当redis数据量比较大时， 性能比较差，要避免使用。

SACN:渐进式遍历键：

SCAN cursor [MATCH pattern] [COUNT count][TYPE type]
scan 参数提供了三个参数，第一个是 cursor整数值(hash桶的索引值)，第二个是key的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，第四个是匹配结果的数据结构类型，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为0时结束。
注意：但是scan并非完美无瑕，如果在scan的过程中如果有键的变化（增加、 删除、 修改），那么遍历效果可能会碰到如下问题：新增的键可能没有遍历到，遍历出了重复的键等情况，因为是hash桶的索引值，在遍历过程中rehash会重新打乱结构,也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的。

Info: 查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:

Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息

主要参数注释：

1 connected_clients:2 # 正在连接的客户端数量
2 instantaneous_ops_per_sec:789 # 每秒执行多少次指令
3 used_memory:929864 # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内存
4 used_memory_human:908.07K # Redis分配的内存总量(Kb，human会展示出单位)
5 used_memory_rss_human:2.28M # 向操作系统申请的内存大小(Mb)（这个值一般是大于used_memo
y的，因为Redis的内存分配策略会产生内存碎片）
6 used_memory_peak:929864 # redis的内存消耗峰值(byte)
7 used_memory_peak_human:908.07K # redis的内存消耗峰值(KB)
8 maxmemory:0 # 配置中设置的最大可使用内存值(byte),默认0,不限制
9 maxmemory_human:0B # 配置中设置的最大可使用内存值
10 maxmemory_policy:noeviction # 当达到maxmemory时的淘汰策略