redis
2021-01-28 15:49:37 0 举报AI智能生成
redis的使用总结和应用场景
作者其他创作
大纲/内容
应用场景
1.秒杀库存扣减
2.APP首页热点数据访问
3.登录tokenId验证
4.接口幂等性校验
数据结构
String
普通的set跟get,kv缓存
共享用户session:单点登录
计数器：实时计数器，可以快速实现计数和查询的功能(订单号)
hash
类似Map 的结构
List
使用场景：我们常用的博客网站的文章列表，当用户量越来越多时，而且每一个用户都有自己的文章列表，而且当文章多时，都需要分页展示，这时可以考虑使用Redis的列表，列表不但有序同时还支持按照范围内获取元素，可以完美解决分页查询功能。大大提高查询效率
set
无序集合，会自动去重
Sorted Set
排行榜：有序集合经典使用场景。排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等
分布式锁
持久化
RDB
持久化机制，是对 Redis中的数据执行周期性的持久化
优点
他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里钟之前的数据，就去远端拷贝一份之前的数据就好了
RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快
缺点
**RDB**都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉**AOF**则最多丢一秒
还有就是**RDB**在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，在做秒杀的时候他刚好在这个时候**fork**了一个子进程去生成一个大快照，就会出问题
AOF
AOF机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog
优点
**RDB**五分钟一次生成快照，但是**AOF**是一秒一次去通过一个后台的线程`fsync`操作，那最多丢这一秒的数据
**AOF**在对日志文件进行操作的时候是以`append-only`的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损
缺点
一样的数据，**AOF**文件比**RDB**还要大
**AOF**开启后，**Redis**支持写的**QPS**会比**RDB**支持写的要低，他不是每秒都要去异步刷新一次日志嘛
redis集群
redis跟关系型数据库的区别
**Redis**采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的**QPS（每秒内查询次数）**
单线程单进程模型的好处
避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 **CPU**，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
使用多路I/O复用模型，非阻塞IO
单机瓶颈的解决方案
集群的部署方式也就是Redis cluster，并且是主从同步读写分离，类似Mysql的主从同步，Redis cluster*支撑 N 个 Redis master node，每个master node都可以挂载多个 slave node
redisj集群数据交互的方式？持久化？如何存入内存？
AOF和RDB
哨兵集群
哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并**不能保证数据不丢失**，但是可以保证集群的**高可用**
M1所在的机器挂了，哨兵还有两个，两个人一看他不是挂了嘛，那我们就选举一个出来执行故障转移不就好了
哨兵组件的主要功能
集群监控
负责监控 Redis master 和 slave 进程是否正常工作
消息通知
如果某个 **Redis** 实例有故障，那么哨兵负责发送消息作为报警通知给管理员
故障转移
如果 master node 挂掉了，会自动转移到 slave node 上
配置中心
如果故障转移发生了，通知 client 客户端新的 master 地址
redis集群主从数据之间同步
主从架构使用原因
单机**QPS**是有上限的，而且**Redis**的特性就是必须支撑读高并发的，那你一台机器又读又写，**这谁顶得住啊**
原理
你启动一台slave 的时候，他会发送一个**psync**命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制
master就会启动一个线程，生成**RDB**快照，还会把新的写请求都缓存在内存中，**RDB**文件生成后，master会将这个**RDB**发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave
异常(断电/服务器挂了)
传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的
RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办
Key如何寻址?什么是分布式寻址？了解一致性 Hash？
key如何寻址
分布式寻址
Hash一致性
布隆过滤器
原理
布隆过滤器可以用于检索一个元素是否在一个集合中
优点
空间效率和查询时间都远远超过一般的算法
缺点
缺点是有一定的误识别率和删除困难
面试关联
一般都会在回答缓存穿透，或者海量数据去重这个时候引出来，加分项哟
缓存击穿/雪崩/穿透
击穿
场景
某个热点数据,大并发j的访问，当此时这个key失效的瞬间，访问直接打到DB
出现原因
缓存击穿不同的是*缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库
处理方案
**布隆过滤器（Bloom Filter）**这个也能很好的防止缓存穿透的发生，他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查了DB刷新KV再return
设置热点数据永远不过期。
加上互斥锁就能搞定了
雪崩
场景
首页的Key失效时间都是12小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库
出现原因
同一时间，大面积的key失效，所有请求打到DB
处理方案
在批量往**Redis**存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效
穿透
场景
通过id查询：不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去请求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就容易崩掉了
出现原因
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求
处理方案
在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等
接口访问幂等性处理
0 条评论
下一页
为你推荐
查看更多
