Redis知识总结

见贤思齐

作者：leobhao，腾讯CSIG研发工程师。1.Redis概览Redis和memcache的区别，Redis支持的数据类型应用场景redis支持的数据结构更丰富(string，hash，list，set，zset)。memcache只支持key-value的存储；redis原生支持集群，memcache没有原生的集群模式。2.Redis单线程模型redis单线程处理请求流程redis采用IO多路复用机制来处理请求，采用reactorIO模型，处理流程如下:首先接收到客户端的socket请求，多路复用器将socket转给连接应答处理器；连接应答处理器将AE_READABLE事件与命令请求处理器关联(这里是把socket事件放入一个队列)；命令请求处理器从socket中读到指令，再内存中执行，并将AE_WRITEABLE事件与命令回复处理器关联；命令回复处理器将结果返回给socket，并解除关联。redis单线程效率高的原因非阻塞IO复用(上图流程)，I/O多路复用分派事件，事件处理器处理事件(这个可以理解为注册的一段函数，定义了事件发生的时候应该执行的动作)，这里分派事件和处理事件其实都是同一个线程；纯内存操作效率高；单线程反而避免了多线程切换。3.Redis过期策略对key设置有效期，redis的删除策略:定期删除+惰性删除。定期删除指的是redis默认每100ms就随机抽取一些设置了过期事件的key，检查是否过期，如果过期就删除。如果redis设置了10万个key都设置了过期时间，每隔几百毫秒就要检查10万个key那CPU负载就很高了，所以redis并不会每隔100ms就检查所有的key，而是随机抽取一些key来检查。但这样会导致有些key过期了并没有被删除，所以采取了惰性删除。意思是在获取某个key的时候发现过期了，如果key过期了就删除掉不会返回。这两个策略结合起来保证过期的key一定会被删除。最大内存淘汰(maxmemory-policy)如果redis内存占用太多，就会进行内存淘汰。有如下策略:noeviction:如果内存不足以写入数据，新写入操作直接报错；allkeys-lru:内存不足以写入数据，移除最近最少使用的key(最常用的策略)；allkeys-random:内存不足随机移除几个key；volatile-lru:在设置了过期时间的key中，移除最近最少使用；volatile-random:设置了过期的时间的key中，随机移除几个。4.Redis主从模式保证高并发和高可用(哨兵模式)读写分离单机的Redis的QPS大概就在上万到几万不等，无法承受更高的并发。读写分离保证高并发(10W+QPS)：对于缓存来说一般都是支撑高并发读，写请求都是比较少的。采用读写分离的架构(一主多从)，master负责接收写请求，数据同步到slave上提供读服务，如果遇到瓶颈只需要增加slave机器就可以水平扩容主从复制机制redisreplication机制：redis采取异步复制到slave节点；slave节点做复制操作的时候是不会block自己的，它会使用旧的数据集来提供服务，复制。完成后，删除旧的数据集，加载新的数据集，这个时候会暂停服务(时间很短暂)；如果采用了主从架构，master需要开启持久化。如果master没有开启持久化(rdb和aof都关闭了)。master宕机重启后数据是空的，然后经过复制就把所有slave的数据也弄丢了。即使采用高可用的的哨兵机制，可能sentinal还没有检测到masterfailure，master就自动重启了，还是会导致slave清空故障。主从同步流程当slave启动时会发送一个psync命令给master；如果是重新连接master，则masternode会复制给slave缺少的那部分数据；如果是slave第一次连接master，则会触发一次全量复制(fullresynchronization)。开始fullresynchronization的时候，master会生成一份rdb快照，同时将客户端命令缓存在内存，rdb生成完后，就发送给slave，slave先写入磁盘在加载到内存。然后master将缓存的命令发送给slave。哨兵(sentinal)模式介绍哨兵是redis集群架构的一个重要组件，主要提供如下功能：集群监控：负责监控master和slave是否正常工作；消息通知：如果某个redis实例有故障，哨兵负责发消息通知管理员；故障转移:如果masternode发生故障，会自动切换到slave；配置中心：如果故障转移发生了，通知客户端新的master地址。哨兵的核心知识:哨兵至少三个，保证自己的高可用；哨兵+主从的部署架构是用来保证redis集群高可用的，并非保证数据不丢失；哨兵(Sentinel)需要通过不断的测试和观察才能保证高可用。为什么哨兵只有两个节点无法正常工作假设哨兵集群只部署了2个哨兵实例，quorum=1。master宕机的时候，s1和s2只要有一个哨兵认为master宕机j就可以进行切换，并且会从s1和s2中选取一个来进行故障转移。这个时候是需要满足majority，也就是大多数哨兵是运行的，2个哨兵的majority是2，如果2个哨兵都运行着就允许执行故障转移。如果M1所在的机器宕机了，那么s1哨兵也就挂了，只剩s2一个，没有majorityl来允许执行故障转移，虽然集群还有一台机器R1，但是故障转移也不会执行。如果是经典的三哨兵集群，如下:此时majority也是2，就算M1所在的机器宕机了，哨兵还是剩下两个s2和s3，它们满足majority就可以允许故障转移执行。哨兵核心底层原理sdown和odown两种失败状态；sdown是主观宕机，就是一个哨兵觉得master宕机了，达成条件是如果一个哨兵pingmaster超过了is-master-down-after-milliseconds指定的毫秒数后就认为主观宕机；odown是客观宕机，如果一个哨兵在指定时间内收到了majority(大多数)数量的哨兵也认为那个master宕机了，就是客观宕机。哨兵之间的互相发现：哨兵是通过redis的pub/sub实现的。5.Redis数据的恢复(Redis的持久化)RDBRDB原理RDB（RedisDataBase）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的过程。RDB有两种方式save和bgsave:save:执行就会触发Redis的持久化，但同时也是使Redis处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令；bgsave:bgsave会fork()一个子进程来执行持久化，整个过程中只有在fork()子进程时有短暂的阻塞，当子进程被创建之后，Redis的主进程就可以响应其他客户端的请求了。RDB配置除了使用save和bgsave命令触发之外，RDB支持自动触发。自动触发策略可配置Redis在指定的时间内，数据发生了多少次变化时，会自动执行bgsave命令。在redis配置文件中配置:在时间m秒内，如果Redis数据至少发生了n次变化，那么就自动执行BGSAVE命令。save m nRDB优缺点RDB的优点:RDB会定时生成多个数据文件，每个数据文件都代表了某个时刻的redis全量数据，适合做冷备，可以将这个文件上传到一个远程的安全存储中，以预定好的策略来定期备份redis中的数据；RDB对redis对外提供读写服务的影响非常小，redis是通过fork主进程的一个子进程操作磁盘IO来进行持久化的；相对于AOF，直接基于RDB来恢复reids数据更快。RDB的缺点:如果使用RDB来恢复数据，会丢失一部分数据，因为RDB是定时生成的快照文件；RDB每次来fork出子进程的时候，如果数据文件特别大，可能会影响对外提供服务，暂停数秒(主进程需要拷贝自己的内存表给子进程，实例很大的时候这个拷贝过程会很长)。latest_fork_usec代表fork导致的延时；Redis上执行INFO命令查看latest_fork_usec；当RDB比较大的时候，应该在slave节点执行备份，并在低峰期执行。AOFAOF原理redis对每条写入命令进行日志记录，以append-only的方式写入一个日志文件，redis重启的时候通过重放日志文件来恢复数据集。(由于运行久了AOF文件会越来越大，redis提供一种rewrite机制，基于当前内存中的数据集，来构建一个更小的AOF文件，将旧的庞大的AOF文件删除)。rewrite即把日志文件压缩，通过bgrewriteaof触发重写。AOFrewrite后台执行的方式和RDB有类似的地方，fork一个子进程，主进程仍进行服务，子进程执行AOF持久化，数据被dump到磁盘上。与RDB不同的是，后台子进程持久化过程中，主进程会记录期间的所有数据变更（主进程还在服务），并存储在server.aof_rewrite_buf_blocks中；后台子进程结束后，Redis更新缓存追加到AOF文件中，是RDB持久化所不具备的。AOF的工作流程如下:Redis执行写命令后，把这个命令写入到AOF文件内存中（write系统调用）；Redis根据配置的AOF刷盘策略，把AOF内存数据刷到磁盘上（fsync系统调用）；根据rewrite相关的配置触发rewrite流程。AOF配置appendonly:是否启用AOF(yes|no)；appendfsync:刷盘的机制：always：主线程每次执行写操作后立即刷盘，此方案会占用比较大的磁盘IO资源，但数据安全性最高；everysec：主线程每次写操作只写内存就返回，然后由后台线程每隔1秒执行一次刷盘操作（触发fsync系统调用），此方案对性能影响相对较小，但当Redis宕机时会丢失1秒的数据；no：主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由操作系统决定，此方案对性能影响最小，但数据安全性也最低，Redis宕机时丢失的数据取决于操作系统刷盘时机。auto-aof-rewrite-percentage:当aof文件相较于上一版本的aof文件大小的百分比达到多少时触发AOF重写。举个例子，auto-aof-rewrite-percentage选项配置为100，上一版本的aof文件大小为100M，那么当我们的aof文件达到200M的时候，触发AOF重写；auto-aof-rewite-min-size：最小能容忍aof文件大小，超过这个大小必须进行AOF重写；no-appendfsync-on-rewrite:设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入，默认为no。AOF优缺点AOF的优点:可以更好的保证数据不丢失，一般AOF每隔1s通过一个后台线程来执行fsync(强制刷新磁盘页缓存)，最多丢失1s的数据；AOF以append-only的方式写入(顺序追加)，没有磁盘寻址开销，性能很高；AOF即使文件很大，触发后台rewrite的操作的时候一般也不会影响客户端的读写，(rewrite的时候会对其中指令进行压缩，创建出一份恢复需要的最小日志出来)。在创建新的日志文件的时候，老的文件还是照常写入，当新的文件创建完成后再交换新老日志。但是还是有可能会影响到主线程的写入，如：当磁盘的IO负载很高，那这个后台线程在执行AOFfsync刷盘操作（fsync系统调用）时就会被阻塞住，，紧接着，主线程又需要把数据写到文件内存中（write系统调用），但此时的后台子线程由于磁盘负载过高，导致fsync发生阻塞，迟迟不能返回，那主线程在执行write系统调用时，也会被阻塞住，直到后台线程fsync执行完成后，主线程执行write才能成功返回。这时候主线程就无法响应客户端的请求，可能会导致客户端请求redis超时。具体类似:https://blog.csdn.net/mmgithub123/article/details/124507846。AOF日志文件通过非常可读的方式进行记录，这个特性适合做灾难性的误操作的紧急恢复，比如不小心使用flushall清空了所有数据，只要rewrite没有发生，就可以立即拷贝AOF，将最后一条flushall命令删除，再回放AOF恢复数据。AOF的缺点：同一份数据，因为AOF记录的命令会比RDB快照文件更大；AOF开启后，支持写的QPS会比RDB支持写的QPS要低，毕竟AOF有写磁盘的操作。总结总结AOF和RDB该如何选择：两者综合使用，将AOF配置成每秒fsync一次。RDB作为冷备，AOF用来保证数据不丢失的恢复第一选择，当AOF文件损坏或不可用的时候还可以使用RDB来快速恢复。6.Redis集群模式(rediscluster)在主从部署模式上，虽然实现了一定程度的高并发，并保证了高可用，但是有如下限制:master数据和slave数据一模一样，master的数据量就是集群的限制瓶颈；redis集群的写能力也受到了master节点的单机限制。在高版本的Redis已经原生支持集群(cluster)模式，可以多master多slave部署，横向扩展Redis集群的能力。RedisCluster支持N个masternode，每个masternode可以挂载多个slavenode。rediscluster介绍自动将数据切片，每个master上放一部分数据；提供内置的高可用支持，部分master不可用时还是能够工作；rediscluster模式下，每个redis要开放两个端口：6379和10000+以后的端口(如16379)。16379是用来节点之间通信的，使用的是clusterbus集群总线。clusterbus用来做故障检测，配置更新，故障转移授权。rediscluster负载均衡rediscluster采用一致性hash+虚拟节点来负载均衡。rediscluster有固定的16384个slot(2^14)，对每个key做CRC16值计算，然后对16384mod。可以获取每个key的slot。rediscluster每个master都会持有部分slot，比如三个master那么每个master就会持有5000多个slot。hashslot让node的添加和删除变得很简单，增加一个master，就将其他master的slot移动部分过去，减少一个就分给其他master，这样让集群扩容的成本变得很低。cluster基础通信原理(gossip协议)与集中式不同(如使用zookeeper进行分布式协调注册)，rediscluster使用的是gossip协议进行通信。并不是将集群元数据存储在某个节点上，而是不断的互相通信，保持整个集群的元数据是完整的。gossip协议所有节点都持有一份元数据，不同节点的元数据发生了变更，就不断的将元数据发送给其他节点，让其他节点也进行元数据的变更。集中式的好处：元数据的读取和更新时效性很好，一旦元数据变化就更新到集中式存储，缺点就是元数据都在一个地方，可能导致元数据的存储压力。对于gossip来说：元数据的更新会有延时，会降低元数据的压力，缺点是操作是元数据更新可能会导致集群的操作有一些滞后。rediscluster主备切换与高可用判断节点宕机：如果有一个节点认为另外一个节点宕机，那就是pfail，主观宕机。如果多个节点认为一个节点宕机，那就是fail，客观宕机。跟哨兵的原理一样；对宕机的master，从其所有的slave中选取一个切换成masternode，再次之前会进行一次过滤，检查每个slave与master的断开时间，如果超过了cluster-node-timeout*cluster-slave-validity-factor就没有资格切换成master；从节点选取：每个从节点都会根据从master复制数据的offset，来设置一个选举时间，offset越大的从节点，选举时间越靠前，masternode开始给slave选举投票，如果大部分master(n/2+1)都投给了某个slave，那么选举通过(与zk有点像，选举时间类似于epochid)；整个流程与哨兵类似，可以说rediscluster集成了哨兵的功能，更加的强大；Redis集群部署相关问题redis机器的配置，多少台机器，能达到多少qps?机器标准:8核+32G集群:5主+5从(每个master都挂一个slave)效果:每台机器最高峰每秒大概5W，5台机器最多就是25W，每个master都有一个从节点，任何一个节点挂了都有备份可切换成主节点进行故障转移脑裂问题哨兵模式下:master下挂载了3个slave，如果master由于网络抖动被哨兵认为宕机了，执行了故障转移，从slave里面选取了一个作为新的master，这个时候老的master又恢复了，刚好又有client连的还是老的master，就会产生脑裂，数据也会不一致，比如incr全局id也会重复。redis对此的解决方案是：min-slaves-to-write1至少有一个slave连接min-slaves-max-lag10slave与master主从复制延迟时间如果连接到master的slave数小于最少slave的数量，并且主从复制延迟时间超过配置时间，master就拒绝写入12。client连接redis多tcp连接的考量首先redisserver虽然是单线程来处理请求，但是他是多路复用的，单tcp连接肯定是没有多tcp连接性能好，多路复用一个io周期得到的就绪io事件越多，处理的就越多。这也不是绝对的，如果使用pipeline的方式传输，单连接会比多连接性能好，因为每一个pipeline的单次请求过多也会导致单周期到的命令太多，性能下降多少个连接比较合适这个问题，rediscluser控制在每个节点100个连接以内。