本文共 3444 字，大约阅读时间需要 11 分钟。

redis应用场景

*  秒杀库存扣减*  APP首页的访问流量高峰

基础知识

*     5种基本的数据结构：String，List，Set，SortSet，Hash	*     其他的数据结构：hyperLogLog，Geo，pub/sub	*     用于防止存储穿透的数据结构：redis Module，像BloomFilter ，redisSearch，Redis-ML	*     设置key随机 过期：setRedis（key，value，time+Math.Random（）*1000）expire* Keys命令	*     使用keys可以扫出指定模式的key列表	*     如果key正在提供服务，因为redis是单线程的，keys指令导致线程阻塞一段时间，线上的服务会卡顿，直到指令      执行完成，才能恢复	*     使用scan指令可以在不阻塞的情况下提取key集合，但是存在重复概率，需要去重，耗时比keys长(增量式迭代命       令)	*     使用SMEMBERS命令可以返回集合键中的所有元素(增量式迭代命令)	*     过程中键可能会被修改，所以对返回的元素提供有限的保证* 异步队列	*     list结构作为队列，rpush生成消息，rpop消费消息，如果rpop没有消息，要适当地sleep后在试	*     list中还有个指令blpop,如果没有消息，会阻塞，直到消息来	*     pub/sub主题订阅模式，可以实现1：N的消息队列，实现生产一次，消费多次	*     pub/sub主题订阅模式，如果消费者下线的情况下，这时生产的消息会丢失，得使用专业的MQ来进行处理* 集群的同步机制	*     redis可以使用主从同步，从从同步，	*     第一次做同步的时候，主节点做一次bgsave并同时将修改的操作记录到缓存buffer，待传递完成后将RDB全量同步到复制节点，复制节点接受完后将RDB镜像加载到内存中，加载完成后，在通知主节点，将后续增量的数据通过AOF日志的方式同步即可，类似于数据库的binlog* 集群的高可用	*     redis sentinel 着眼于高可用，在master宕机时，会自动将slave提升为master，继续提供服务	*     redis Cluster着眼于拓展性，在单个redis实例内存不足时，可以使用Cluster进行分片存储* pipeline好处	*     可以将多次io往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果关系

缓存雪崩，穿透，击穿

*    缓存雪崩 	* 现象：大面积的缓存同一时间失效，导致所有请求直接访问DB，如同没有redis缓存，打崩DB（解决方案）	* 解决方式：		1. 批量往redis中存储数据的时候，把每个key的失效时间都加一个random随机值，可以保证数据不会在同一时间失效，		2. redis是集群部署，将热点数据均匀分布在不同的redis分片上，也能够避免缓存全部失效的问题		3. 将热点数据设置为永不过期，如果存在更新操作，也同步更新缓存* 缓存穿透	* 现象：用户频繁的发起一些缓存以及数据库中不存在的数据请求，导致DB压力过大，严重点可能击垮数据库（解决方案）	* 解决方式：		1. 业务上增加参数校验，如（id不合法，验权），进行数据过滤		2. 从网关处入手，在nginx中设置配置项，如果某个ip每秒访问量超出限制，拉黑或限流		3. 利用redis中的Bloom filter（布隆过滤器），也能避免穿透的发生，它利用高效的数据结构和算法快速算出DB中是否存在，如果不存在就直接return，如果存在，就先更新缓存，再返回结果* 缓存击穿	* 现象：一个热点的key承载着大量的请求，并发的对一个点进行访问，在这个key失效的瞬间，请求直接打到DB，导致不可用(解决方案)	* 解决方式：		1. 如果该数据一直承载着大量的并发，就设置永不过期，		2. 增加互斥锁

持久化

* redis数据存储在内存中，如果机器断电了，数据就消失了，就需要进行恢复		* redis是如何实现的？	* RDB(redis DataBase)		* 冷备		* RDB持久化机制是会生成一个内存快照，是对redis中的数据进行周期性的持久化到磁盘（默认5分钟）		* 优点：RDB对redis的性能影响很小，因为每次同步数据都是fork一个子线程进行数据的持久化，而且恢复数据的效率比AOF快，直接用就可以了		* 缺点：默认是5分钟或者更久持久化一次，意味着中间的数据会丢失，AOF最多丢失1s的数据，RBD丢失的数据量会比AOF大许多	* AOF（append only file）		* 热备		* AOF机制是对每条写入命令记录日志，以append-only 的模式进行追加		* 优点：数据完整性很高，AOF是一秒一次通过一个后台的线程fsync操作，最多丢失1s的数据，因为只对文件进行追加，所以减少了磁盘寻址的开销		* 缺点：			1. 数据恢复的比RDB要慢 			2. 一样的数据，AOF文件比RDB文件要大* 生产环境选择那种方式进行持久化？	* 默认是两个都进行开启，先用RDB恢复基本的数据量，恢复时间快，系统不会卡顿太久，之后在用AOF进行数据的查漏补缺。

主从同步

*  启动一台slave的时候，他会发送一个psync命令给master，如果这个slave是第一个次连接到master，*  他会触发一个全量复制，master就开启一个线程去生成RDB快照，之后的数据同步存储在buffer缓存中，RDB生成后，*  master会把这个RDB文件发给slave，slave拿到后，会先写进自己的本地磁盘，然后再他加载到内存中，之后再同步buffer中遗留的发给slave中进行同步。

哨兵模式

*     哨兵+主从 实现redis 的集群高可用*     集群监控：负责监控redis master和slave进程是否正常工作*     消息通知：如果某个redis实例出现异常，有故障，那么哨兵就会发送消息给管理员*     故障转移：如果master node 死掉了，会自动转移到slave node上*     配置中心：如果故障转移了发生了，通知client客户端新的master地址

内存淘汰机制（过期策略）

*     定期删除：	* 默认100ms就会随机抽一些设置了过期时间的key，然后去排查是否过期，如果过期了就删除*   惰性删除 ：	* 我不主动删除，我比较懒惰，我等你来查询，发现过期了，就给你删除，然后不返回，没有过期就不管	*    如果定期没有删除(随机的缘故)，也没有查询过，就会存在垃圾数据，占内存，怎么办?   *  淘汰机制

经典KV，DB读写模式

*     缓存+数据库读写的模式	*    读的时候，先读缓存，如果缓存中没有，再读DB，取出数据后放入缓存，然后返回响应	*    更新的时候，先更新DB，然后再删除缓存（为啥不更新缓存）*  原因：因为缓存中的数据往往不单一，通常数据结构比较复杂，往往由多个数据组合而成。更新开销大，而且更新后的数据并不一定就会使用，可能很久都不会使用。

健壮性

*     事前：redis高可用，哨兵+集群 redis cluster ，避免全盘崩溃*     事中：本地的ehcache，存储热点数据，(效率比redis高，但是存在单机的局限性)，hystrix限流+降级，避免请求直接打到DB*     事后：RDB+AOF，一旦重启，从磁盘中拉取数据，快速恢复缓存数据

和memcache的差异

* redis相比于memCache而言，数据结构更加丰富(不限于key-value)，拥有更加丰富的数据操作* redis只使用单核，而memcache是多核的，如果数据小于100k，平均每个核上redis存储的效率是大于memcache的，如果数据结构比较大，memcache更优* 在redis3..的版本中，能支持cluster模式，而memcache没有原生的集群模式，需要依赖客户端来实现往集群分片中写入数据

转载地址：https://blog.csdn.net/Junudam/article/details/125156712 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！