redis知识点总结(持续更新)

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没有原生的集群模式，需要依赖客户端来实现往集群分片中写入数据