redis核心

1.Redis核心----管道（pipeline）：它本身并不是redis提供的技术，这个技术本质上是客户端提供的

2.管道就是将request---->response---->request--->response改成了request---->request----->response---->response将写或读的操作串联在一起能极大的减少所需的时间（主要减少的IO时间）（管道中的指令越多，效果越好）

3.Redis管道本质

（1）客户端进程调用write将消息写到操作系统内核为套接字分配的发送缓冲send buffer。

（2）客户端操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过「网际路由」送到服务器的网卡。

（3）服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

（4）服务器进程调用read从接收缓冲中取出消息进行处理。

（5）服务器进程调用write将响应消息写到内核为套接字分配的发送缓冲send buffer。

（6）服务器操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过「网际路由」送到客户端的网卡。

（7）客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

（8）客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理。

（9）结束。

其中步骤5~8和1~4是一样的，只不过方向是反过来的，一个是请求，一个是响应。

4.read和write操作的费时体现在：read和write都是直接读或写缓存。如果缓存为空，read就要等待（费时），如果缓存已满，那么write就要等待（费时）

5.Redis核心----事务：redis的执行事务操作（单线程）三个阶段：开启事务，命令入队列，执行事务。细分为一下阶段：

1.事务开启:客户端执行Multi命令开启事务。

2.提交请求:客户端提交命令到事务。

3.任务入队列: Redis将客户端请求放入事务队列中等待

执行。

4.入队状态反馈:服务器返回QURUD， 表示命令已被放入

事务队列。

5.执行命令:客户端通过Exec执行事务。

6.事务执行错误:在Redis事务中如果某条命令执行错误，

则其他命令会继续执行，不会回滚。可以通过Watch监控

事务执行的状态并处理命令执行错误的异常情况。

7.执行结果反馈:服务器向客户端返回事务执行的结果

6. redis核心----发布pub，订阅sub机制：

消息多播（分布式系统的一种常用解耦方式）：生产者发布一个消息，由中间件将消息复制到多个消息队列，每个消息队列由一个消费者消费。如果不支持消息多播，那么就需要将所有消费者串联到一个子系统中，进行连续的消费（那么这些连续的消费者的耦合度高）。

7.redis用一个新的模块支持多播：PubSub（消息通信模式）

一个发布者可以想多个频道（channel）发送消息，一个订阅者也可以从多个频道接受消息

缺点：消费者挂掉之后重连，重连期间发布者发布的消息这个消费者将接受不到

8.Redis核心-----集群数据复制的原理

1.一个数据库在启动后，会向主数据库发送SYNC命令。

2.主数据库在接收到SYNC命令后会开始在后台保存快照，

并将保存快照期间接收到的命令缓存起来。在该持久化过

程中生成一个. rdb快照文件

3.在主数据库快照执行完成后，Redis会将快照文件和所

有缓存的命令以.rdb快照文件的形式发送给从数据库。

4.从数据库收到主数据库的. rdb快照文件后，载入该快照

文件到本地。

5.从数据库执行载入后的. rdb快照文件，将数据写入到内

存中。以上过程称为复制初始化。

6.在复制初始化结束后，主数据库在每次收到写命令时都

会将命令同步给从数据库，从而保证主从数据库的数据一

致。

9.Redis有三种集群模式：主从模式，哨兵模式，集群模式

1.主从模式：所有写请求都放到主数据库，再由主数据库将数据同步到从数据库（从数据库主要负责读）

（1）Redis保证T最终一致性，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。

（2）Redis同步支持主从同步和从从同步，从从同步功能是Redis后续版本增加的功能，为了减轻主库的同步负担。

（3）增量同步：Redis同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存buffer中，然后异步将buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了(偏移量)。 因为内存的buffer是有限的，所以Redis主 库不能将所有的指令都记录在内存buffer中。Redis的复制内存buffer是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。如果因为网络状况不好从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时，Redis的主节点中那些没有同步的指令在buffer中有可能已经被后续的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制一快照同步。

（4）快照同步：在整个快照同步进行的过程中，主节点的复制buffer还在不停的往前移动，如果快照同步的时间过长或者复制buffer太小，都会导致同步期间的增量指令在复制buffer中被覆盖（增量指令被不断往前移动的快照文件覆盖，丢失。所以务必配置一个大小合适的复制buffer），这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。

（5）无盘复制：主节点不再复制，而是遍历，遍历期间将数据发送到从节点，从节点进行一次性读取

（6）wait指令：redis复制是进行异步复制的，wait让其变成同步复制。wait提供两个参数，第一个参数是从库的数量N，第二个参数是时间t，以毫秒为单位。它表示等待wait 指令之前的所有写操作同步到N个从库(也就是确保N个从库的同步没有滞后)，最多等待时间t。如果时间t=0，表示无限等待直到N个从库同步完成达成一致。

   2.哨兵（sentinel）模式：在主从模式上添加一个哨兵来监视集群的运行状态。哨兵通过发送请求让redis服务器返回集群的运行状态

   3.集群模式:Redis集群实现了在多个Redis节点之间进行数据分片和数据复制。基于Redis集群的数据自动分片能力，我们能够方便地对Redis集群进行横向扩展，以提高Redis集群的吞吐量。

10.redis核心---过期策略：定时删除（定时扫描策略），惰性删除。从库不会进行定期删除，而是接受到主库的AOF（持久化）中的del指令来进行删除key

淘汰策略：

1. noeviction:不会继续服务写请求(DEL请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。

2. volatile-lru:尝试淘汰设置了过期时间的key，最少使用的key优先被淘汰。没有设置过期时间的key不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。

3. volatile-ttl: 跟上面一样，除了淘汰的策略不是LRU,而是key的剩余寿命ttl的值，ttl越小越优先被淘汰。

3. volatile-random:跟上面一样，不过淘汰的key是过期key集合中随机的key。

4. allkeys- lru:区别于volatile-lru,这个策略要淘汰的key对象是全体的key集合，而不只是过期的key集合。这意味着没有设置讨期时间的key也会被淘汰。

5. allkeys-random:跟上面一样，不过淘汰的策略是随机的key。

6. volatile-xxx:策略只会针对带过期时间的key进行淘汰，allkeys-xxx策略 会对所有的key进行淘汰。如果你只是拿Redis做缓存，那应该使用allkeys- xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用Redis的持久化功能，那就使用volatile-xxx策略，这样可以保留没有设置过期时间的key，它们是永久的key不会被LRU算法淘汰。

7.LRU（redis采用的是近似LRU的算法（只有懒惰处理），他给每个key增加了一个字段--时间戳，）：实现LRU算法除了需要key/value字典外，还需要附加一个链表，链表中的元素按照一定的顺序进行排列。当空间满的时候，会踢掉链表尾部的元素。当字典的某个元素被访问时，它在链表中的位置会被移动到表头。所以链表的元素排列顺序就是元素最近被访问的时间顺序。