数据结构实战与高性能原理剖析"/>
1. redis核心数据结构实战与高性能原理剖析
分布式缓存技术Redis
- 1. Redis的五种数据结构
- 1.1 String
- 1.2 hash
- 1.3 列表list
- 1.4 set
- 1.5 ZSet
- 2. Redis的单线程和高性能
- 3. 其他高级命令
- 3.1 scan:渐进式遍历键
本文是按照自己的理解进行笔记总结，如有不正确的地方，还望大佬多多指点纠正，勿喷。
课程内容：
1、Redis核心数据结构精讲
2、微博与微信消息流Redis实现
3、微信点赞、收藏与标签基于Redis实现
4、微博与微信朋友关注模型基于Redis实现
5、电商购物车如何用Redis实现
6、电商推荐系统如何用Redis实现
7、Redis高性能核心原理剖析、Redis 6.0多线程模型初探
redis安装步骤：
1. Redis的五种数据结构
五种数据结构：
1.1 String
可以直接去官方文档查看使用方法，也可以使用命令行查看帮助help @String
1. 字符串常用操作：
| set key value | 存入字符串键值对 |
|---|---|
| mset key value[key value…] | 批量存储字符串键值对 |
| setnx key value | 存入一个不存在的字符串键值对 |
| get key | 获取一个字符串键值 |
| mget key [key…] | 批量获取字符串键值 |
| del key [key…] | 删除一个键 |
| expire key seconds | 设置一个键的过期时间（秒） |
2. 原子加减
| incr key | 将key中存储的数字值加1 |
|---|---|
| decr key | 将key中存储的数字值减1 |
| incrby key increment | 将key所存储的值加上increment |
| decrby key decrement | 将key所存储的值减去decrement |
3. 应用场景
-
单值缓存
set key value
get key -
对象缓存
- set user:1 value(json格式数据)
- mset user:1:name ding 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共享 -
分布式系统全局序列号
incrby orderId 1000 //redis批量生成序列号提升性能
如果在分库分表中还使用数据库自带的自增id肯定是不可以的，就可以使用这个incr orderId，但是如果直接没生成一个订单，自增一个id，这对redis性能压力太大了。我们可以一次性多拿些id，incrby orderId 1000这样，拿到本机内存里面，在本机内存里面一个一个去加一，加到1000之后我再去获取。
这里面可能会有一个小问题，第一台id当我内存加到500M，我的机器挂了怎么办呢？确实存在这种情况哈，那这不就浪费一定的id了吗？没有关系哈，大多数情况下是没有关系的，id很多，把这个步长设置的小一点，其实浪费几百个id其实关系不大。
1.2 hash
hash结构相当于一个双层的map结构(key,(key,value))
1. 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 |
2. 对象缓存
HMSET user {userld}:name ding {userld}:balance 1888
HMSET user 1:name ding 1:balance 1888
HMGET user 1:name 1:balance
假设我一张user用户表可能有上万千条数据，甚至上亿，还能存在这种hash结构里面吗？
是不是不太合适啊。redis里面最怕的一个就是bigkey，大key的操作会阻塞redis，如果一条命令执行的太长，其他的命令都会被阻塞住。这样就会影响redis的并发。
3. Hash的应用场景
-
电商购物车
1)以用户id为key
2)商品id为field
3)商品数量为value -
购物车操作
1)添加商品→hset cart:1001 10088 1
2)增加数量→hincrby cart:1001 10088 1
3)商品总数→hlen cart:1001
4)删除商品→hdel cart:1001 10088
5)获取购物车所有商品→hgetall cart:1001
4. Hash结构优缺点
-
优点
1)同类数据归类整合储存，方便数据管理
2)相比string操作消耗内存与cpu更小
3)相比string储存更节省空间 -
缺点
1)过期功能不能使用在field上，只能用在key上
2)Redis集群架构下不适合大规模使用
5. redis集群架构（在这块是补充知识哈）
比如微博哈，他有几百T的数据肯定不是放到一个redis里面的。redis一般撑死分配10来个G的样子。对于集群来说就是把数据分片，拆成一份一份的。
1.3 列表list
1. 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,一直阻塞等待 |
2. List的应用场景
-
常用数据结构
Stack(栈)= LPUSH + LPOP = FILO
Queue(队列)= LPUSH + RPOP
Blocking MQ(阻塞队列)= LPUSH + BRPOP -
微博和微信公号消息流
带有时间线的消息流，是按照时间线排序的消息流。 -
微博消息和微信公号消息
我关注了邓超，孙俪等大V
- 邓超发微博，消息ID为10018
LPUSH msg:{我-ID}10018
2)孙俪发微博，消息ID为10086
LPUSH msg:{我-ID} 10086
3）查看最新微博消息
LRANGE msg:{我-ID}0 4
通过lrange查询到的消息是按照时间顺序排好序的。
如果邓超的粉丝只有几百个上千个粉丝，意味着他发一条消息就要往这几百个或者上千个粉丝里面发消息。这种方式是可以的。假如有5000个，在发消息的时候可以有优化。我其实是可以分批发的，首先给那些在线的人先发，其他的在后台就给他们慢慢发了。
那是邓超的粉丝实际上是有很多很多的，那怎么办呢？还是分批吗？没用的，他的粉丝那么多，在线的人肯定都特别的多。成本还是很高的，可以使用pull模式，就是我只发一份，你们上线了就从这个里面自己去拿。
pull和push有什么区别？还有没有更好的优化策略？
如果我关注了很多大V，每个大V都有自己的消息队列，那上线的时候就要拉去很多大V的消息，拉到本机还要排序，相对来说回避分批的那种小V要麻烦一点。
1.4 set
1. 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中删除 |
2. 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中 |
3. set 应用场景
-
微信抽奖小程序
1)点击参与抽奖加入集合
SADD key {userlD}
2)查看参与抽奖所有用户
SMEMBERS key
3)抽取count名中奖者
SRANDMEMBER key [count]/ SPOP key [count]
上面这个抽奖完之后集合里面还是不变的，但是如果我们先抽三等奖、再抽二等奖、再抽一等奖，那就需要把奖抽完之后删除该名字。
-
微信微博点赞、收藏、标签
1)点赞
SADD like:消息ID}{用户ID}
2)取消点赞
SREM like:{消息ID}{用户ID}
3)检查用户是否点过赞
SISMEMBER like:{消息ID}{用户ID}
4)获取点赞的用户列表
SMEMBERS like:消息ID}
5)获取点赞用户数
SCARD like:{消息ID} -
集合操作
SINTER set1 set2 set3→{c}
SUNION set1 set2 set3→{ a,b,c,d,e }
SDIFF set1 set2 set3→{ a }
第三行的意思是：set1减去set2与set3的交集
-
集合操作实现微博微信关注模型
1)诸葛老师关注的人:
zhugeSet-> {guojia, xushu}
2)杨过老师关注的人: yangguoSet–> {zhuge, baiqi,guojia, xushu}
3)郭嘉老师关注的人: guojiaSet-> {zhuge, yangguo, baiqi, xushu, xunyu)
4)我和杨过老师共同关注: SINTER zhugeSet yangguo2e-g
5)我关注的人也关注他(杨过老师): SISMEMBER guojiaSet yangguoSISMEMBER xushuSet yangguo
6)我可能认识的人: SDIFF yangguoSet zhugeSet->(zhuge,baiqi} -
集合操作实现电商商品筛选
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}
1.5 ZSet
1. 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下标的元素 |
2. ZSet集合操作
ZUNIONSTORE destkey numkevs key [key…]//并集计算
ZINTERSTORE destkey numkeys key [key …]//交集计算
3. 应用场景
- ZSet集合操作实现排行榜
1）点击新闻
ZINCRBY hotNews:20190819 1守护香港
2)展示当日排行前十
ZREVRANGE hotNews:20190819 0 9 WITHSCORES
3)七日搜索榜单计算
ZUNIONSTORE hotNews:20190813-20190819 7
hotNews:20190813 hotNews:20190814… hotNews:20190819
4)展示七日排行前十
ZREVRANGE hotNews:20190813-20190819 0 9 WITHSCORES
2. Redis的单线程和高性能
Redis是单线程吗？
Redis的单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的，这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。
Redis 单线程为什么还能这么快?
因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为Redis是单线程，所以要小心使用Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致Redis 卡顿。
Redis单线程如何出路那么多的并发客户端连接？
Redis的IO多路复用: redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。
#查看redis支持的最大连接数，在redis.conf文件中可修改，# maxclients 10000
127.0.0.1:6379> CONFIG GET maxclients##1)"maxclients"##2)）"10000"
3. 其他高级命令
keys:全量遍历键，用来列出所有满足特定正则字符串规则的key，当redis数据量比较大时，性能比较差，要避免使用
127.0.0.1:6379> set codehole1 a
OK
127.0.0.1:6379> set codehole2 b
OK
127.0.0.1:6379> set codehole3 c
OK
127.0.0.1:6379> set code1hole a
OK
127.0.0.1:6379> set code2hole b
OK
127.0.0.1:6379> set code3hole b
OK
127.0.0.1:6379> keys*
1) "codehole1"
2) "codehole3"
3) "codehole2"
127.0.0.1:6379> keys code*hole
1) "code3hole"
2) "code2hole"
3) "code1hole"
3.1 scan:渐进式遍历键
SCAN cursor [MATCH pattern] [CoUNT count]
scan参数提供了三个参数，第一个是cursor整数值(hash桶的索引值)，第二个是key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor值为0，然后将返回结果中第一个整数值作为下一次遍历的cursor。一直遍历到返回的cursor值为0时结束。
注意:但是scan并非完美无瑕，如果在scan的过程中如果有键的变化（增加、删除、修改)，那么遍历效果可能会碰到如下问题:新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键，这些是我们在开发时需要考虑的。
127.0.0.1:6379> scan 0 match key99* count 1000
1)“13976"(这个是下一次要扫描的游标，这个游标一直到0才结束)
2) 1) “key9911”
2)“key9974”
3 )“key9994”
4) “key9910”
5)“key9907”
6)“key9989”
7 )“key9971”
注意：但是scan并非完美无瑕， 如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那 么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说 scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的
Info：查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:
| Server | 服务器运行的环境参数 |
|---|---|
| Clients | 客户端相关信息 |
| Memory | 服务器运行内存统计数据 |
| Persistence | 持久化信息 |
| Stats | 通用统计数据 |
| Replication | 主从复制相关信息 |
| CPU | CPU 使用情况 |
| Cluster | 集群信息 |
| KeySpace | 键值对统计数量信息 |
connected_clients:2 # 正在连接的客户端数量
instantaneous_ops_per_sec:789 # 每秒执行多少次指令
used_memory:929864 # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内存
used_memory_human:908.07K # Redis分配的内存总量(Kb，human会展示出单位)
used_memory_rss_human:2.28M # 向操作系统申请的内存大小(Mb)（这个值一般是大于used_memo
y的，因为Redis的内存分配策略会产生内存碎片）
used_memory_peak:929864 # redis的内存消耗峰值(byte)
used_memory_peak_human:908.07K # redis的内存消耗峰值(KB)
maxmemory:0 # 配置中设置的最大可使用内存值(byte),默认0,不限制
maxmemory_human:0B # 配置中设置的最大可使用内存值
maxmemory_policy:noeviction # 当达到maxmemory时的淘汰策略
127.0.0.1:6379> info
# Server
redis_version:5.0.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:bec1b87bfb6bd040
redis_mode:standalone
os:Linux 3.10.0-1160.90.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:9665
run_id:e2509cd36ff2ba601c31d05237d5cc741aa8deb7
tcp_port:6379
uptime_in_seconds:39699
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:8597002
executable:/usr/local/redis-5.0.3/src/redis-server
config_file:/usr/local/redis-5.0.3/redis.conf# Clients
connected_clients:2
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0# Memory
used_memory:875256
used_memory_human:854.74K
used_memory_rss:10788864
used_memory_rss_human:10.29M
used_memory_peak:3905168
used_memory_peak_human:3.72M
used_memory_peak_perc:22.41%
used_memory_overhead:858808
used_memory_startup:792048
used_memory_dataset:16448
used_memory_dataset_perc:19.77%
allocator_allocated:1278976
allocator_active:1540096
allocator_resident:8687616
total_system_memory:3408482304
total_system_memory_human:3.17G
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.20
allocator_frag_bytes:261120
allocator_rss_ratio:5.64
allocator_rss_bytes:7147520
rss_overhead_ratio:1.24
rss_overhead_bytes:2101248
mem_fragmentation_ratio:12.95
mem_fragmentation_bytes:9955856
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:66616
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1686286355
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:4300800
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# Stats
total_connections_received:52
total_commands_processed:20
instantaneous_ops_per_sec:0
total_net_input_bytes:1300673
total_net_output_bytes:5023316
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
evicted_keys:0
keyspace_hits:6
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:828
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# Replication
role:master
connected_slaves:0
master_replid:d60f3d528bece5a6d38c1d5e1f38ab6f7c098b67
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:22.465098
used_cpu_user:13.196395
used_cpu_sys_children:0.008807
used_cpu_user_children:0.000000# Cluster
cluster_enabled:0# Keyspace
db0:keys=2,expires=0,avg_ttl=0
更多推荐
1. redis核心数据结构实战与高性能原理剖析
发布评论