Redis总结

Redis数据结构适用场景

1. String
2. Hash 主要存放一些对象 ，简单对象的缓存，后续操作直接修改这个对象中某个字段的值
3. List 有序列表 ，粉丝列表，文章评论，基于redis实现简单的高性能分页（微博下拉分页）
4. Set 无序集合，去重
5. Sort set  排行榜

Redis线程模型，与memcached的区别

Redis拥有更多的数据操作并支持更丰富的数据结构，在memacache里，需要将数据拿到客户端进行类似修改再set回去，大大增加了网络io和数据体积；redis原生支持cluster模式，memcached需要依靠客户端网集群中分片写入数据。

线程模型

 

消息处理流程

• 文件事件处理器使用I/O多路复用(multiplexing)程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
• 当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都推到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O多路复用程序才会继续向文件事件分派器传送下一个套接字

 

客户端与服务端连接

假设Redis服务器正在运作，那么这个服务器的监听套接字的AE_READABLE事件应该正处于监听状态之下，而该事件所对应的处理器为连接应答处理器。

如果这时有一个Redis客户端向Redis服务器发起连接，那么监听套接字将产生AE_READABLE事件， 触发连接应答处理器执行：处理器会对客户端的连接请求进行应答， 然后创建客户端套接字，以及客户端状态，并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联，使得客户端可以向主服务器发送命令请求。

之后，客户端向Redis服务器发送一个命令请求，那么客户端套接字将产生 AE_READABLE事件，引发命令请求处理器执行，处理器读取客户端的命令内容， 然后传给相关程序去执行。

执行命令将产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的AE_WRITABLE事件与命令回复处理器进行关联：当客户端尝试读取命令回复的时候，客户端套接字将产生AE_WRITABLE事件， 触发命令回复处理器执行， 当命令回复处理器将命令回复全部写入到套接字之后， 服务器就会解除客户端套接字的AE_WRITABLE事件与命令回复处理器之间的关联。

文件事件类型

当套接字变得可读时（客户端对套接字执行write操作，或者执行close操作），或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行connect操作），套接字产生AE_READABLE 事件

当套接字变得可写时（客户端对套接字执行read操作），套接字产生AE_WRITABLE事件。

I/O多路复用程序允许服务器同时监听套接字的AE_READABLE事件和AE_WRITABLE事件，如果一个套接字同时产生了这两种事件，那么文件事件分派器会优先处理AE_READABLE事件，等到AE_READABLE事件处理完之后，才处理AE_WRITABLE 事件

一致性hash和hash槽对比（https://www.jianshu.com/p/4163916a2a8a）

一致性hash是一个0-2^32的闭合圆，（拥有2^23个桶空间，每个桶里面可以存储很多数据，可以理解为s3的存储桶）所有节点存储的数据都是不一样的。计算一致性哈希是采用的是如下步骤：

1. 对节点进行hash,通常使用其节点的ip或者是具有唯一标示的数据进行hash(ip),将其值分布在这个闭合圆上。
2. 将存储的key进行hash(key),然后将其值要分布在这个闭合圆上。
3. 从hash(key)在圆上映射的位置开始顺时针方向找到的一个节点即为存储key的节点。如果到圆上的0处都未找到节点，那么0位置后的顺时针方向的第一个节点就是key的存储节点

redis cluster采用数据分片的哈希槽来进行数据存储和数据的读取。redis cluster一共有2^14（16384）个槽，所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是你想 的读是从节点，写是主节点。第一次新建redis cluster时，16384个槽是被master节点均匀分布的

对比

·  它并不是闭合的，key的定位规则是根据CRC-16(key)%16384的值来判断属于哪个槽区，从而判断该key属于哪个节点，而一致性哈希是根据hash(key)的值来顺时针找第一个hash(ip)的节点，从而确定key存储在哪个节点。

·  一致性哈希是创建虚拟节点来实现节点宕机后的数据转移并保证数据的安全性和集群的可用性的。redis cluster是采用master节点有多个slave节点机制来保证数据的完整性的,master节点写入数据，slave节点同步数据。当master节点挂机后，slave节点会通过选举机制选举出一个节点变成master节点，实现高可用。但是这里有一点需要考虑，如果master节点存在热点缓存，某一个时刻某个key的访问急剧增高，这时该mater节点可能操劳过度而死，随后从节点选举为主节点后，同样宕机，一次类推，造成缓存雪崩。

解决上述缓存雪崩问题

做好缓存中元素key的访问监控，一旦发现qps限流或者网络大小限流，迅速定位哪些key并发量过大，或者那些key返回的value过大，通过给key加随机数或者更优化的随机算法，将key分散到不同的缓存机器

Redis单线程模式为什么快

1. 纯内存操作

Redis 将所有数据放在内存中，内存的响应时长大约为 100 纳秒，这是 redis 的 QPS 过万的重要基础。

1. 核心是基于非阻塞的IO多路复用机制

有了非阻塞 IO 意味着线程在读写 IO 时可以不必再阻塞了，读写可以瞬间完成然后线程可以继续干别的事了。

redis 需要处理多个 IO 请求，同时把每个请求的结果返回给客户端。由于 redis 是单线程模型，同一时间只能处理一个 IO 事件，于是 redis 需要在合适的时间暂停对某个 IO 事件的处理，转而去处理另一个 IO 事件，这就需要用到IO多路复用技术了， 就好比一个管理者，能够管理个socket的IO事件，当选择了哪个socket，就处理哪个socket上的 IO 事件，其他 IO 事件就暂停处理了。

1. 单线程反而避免了多线程的频繁上下文切换带来的性能问题。

第一，单线程可以简化数据结构和算法的实现。并发数据结构实现不但困难而且开发测试比较麻

第二，单线程避免了线程切换和竞态产生的消耗，对于服务端开发来说，锁和线程切换通常是性能杀手。

单线程的问题：对于每个命令的执行时间是有要求的。如果某个命令执行过长，会造成其他命令的阻塞，所以 redis 适用于那些需要快速执行的场景。

Redis为什么采用IO多路复用

首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的

Redis高可用

高并发:redis单机吞吐量可以达到几万不是问题，想要提高redis的读写能力，可以用redis主从架构，单主负责写请求，多从负责读请求，将主的数据异步复制到从。

高可用：哨兵机制+主从架构+持久化

 

Redis哨兵有什么作用（分布式）

1. 集群监控 负责监控redis master和slave进程是否正常工作
2. 消息通知 如果某个redis实例发生故障，负责发送消息
3. 故障转移 主备切换
4. 配置中心 发生了故障转移后通知客户端新的master地址

Redis cluster（多master ，读写分离，高可用，大数据量）

区别于主从架构(redis  repliaction )+哨兵模式

Redis中是如何实现数据分布的，这种方式有什么优点。

redis cluster有固定的16384个hash slot（哈希槽），对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot 。

redis cluster中每个master都会持有部分slot（槽），比如有3个master，那么可能每个master持有5000多个hash slot

hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。每次增加或减少master节点都是对16384取模，而不是根据master数量，这样原本在老的master上的数据不会因master的新增或减少而找不到。并且增加或减少master时redis cluster移动hash slot的成本是非常低的。

Redis节点通信机制是什么

Rediscluster节点采取gossip协议进行通信，所有节点都持有一份元数据，不同的节点如果出现元数据的变更后不断得将元数据发送给其他节点让其他节点进行数据变更

节点互相之间不断通信，保持整个集群所有节点的数据是完整的。
主要交换故障信息、节点的增加和移除、hash slot信息等。

这种机制的好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力;缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后

缓存更多数据

Redis支持海量数据的瓶颈在于单机容量，redis单主的瓶颈不在于读写并发，而在于内存容量

缓存雪崩和穿透

举个例子，假设每天高峰期的时候系统每秒请求是5000次，缓存在高峰期可以分担每秒4000次请求，另外1000次请求落到数据库（假设数据库每秒可承担2000次请求）。如果此时过来5000请求，但是redis因为某些原因挂掉了，缓存整个就不能用了，那么这5000个请求就全部落到数据库（大量的key全部落到数据库1.key过期2.集群挂掉）。显然数据库扛不住，直接崩溃。此时，如果没用什么特别的方案来处理这个故障，只是很着急的重启数据库，结果因为缓存还没数据，立马数据库又被新的流量给打死了。这就是缓存雪崩。

对于缓存雪崩主要分为事前事中事后，
事前：如果缓存不可用是因为缓存中的大部分数据集中失效，我们可以对缓存的失效时间加上一个随机值，使失效时间分散一点，尽量避免集中失效。另外如果是因为别的原因redis宕机导致缓存不可用，这时候我们就需要提前做好Redis高可用的架构，如主从+哨兵或redis cluster，来避免Redis出现故障时整个缓存不可用，全盘崩溃。

事中：可以将一小部分数据同样缓存到本地ehcache（本地缓存组件）缓存，另外加上hystrix限流&降级组件，避免MySQL被打死。

事后：如果真的发生雪崩，我们还可以用redis的RDB或AOF重启redis快速从磁盘加载缓存数据。这就需要我们提前打开Redis持久化机制，在雪崩发生的事后快速恢复缓存数据，一旦重启从磁盘中恢复数据到内存。

另外一个问题，缓存穿透，一般是黑客恶意攻击，或是自己系统出bug。例如黑客恶意伪造请求，这些请求都是数据库根本查不到的，所以缓存中也没用，那这些大量的恶意请求都会落到数据库去查询，数据库不就挂了吗？

解决办法就是
1、只要从数据库没查到，就写入一个空值到缓存里去。
2、使用布隆过滤器对请求的key进行一层过滤，过滤掉系统认为不存在不合法的key

Redis热点key问题

可以设置热点key的过期时间很多，或者逻辑上永不过期。

设置热点数据自动检测机制，检测每个key某个时间段的请求次数，过期次数，查库次数，然后监听检测出来的热点key，当快要过期的时候，异步起线程去更新这个热点key的过期时间。