redis 部署方式及常见特性

单机部署

redis的单机部署

如何保证redis的高并发和高可用？ redis的主从复制原理？redis的哨兵原理？

redis单机能承载多高并发？如果单机扛不住如何扩容扛更多的并发？

redis会不会挂？既然redis会挂如何保证高可用？

Redis主从架构(实现高并发)

单机的redis，能够承载的QPS大概在上万到几万不等。对于缓存来说，一般是用来支撑读高并发的，因此架构可以做成一主多从，主节点负责写，并且将数据复制到其他的从节点，而从节点负责读，即主从(master-slave)架构。这样也好实现水平扩容，支撑读高并发。

• redis采用异常方式复制数据到slave节点，从redis2.8开始，slave node 会周期性确认自己每次复制的数据量
• 一个master node 可以配置多个slave node
• slave node 依然可以链接其他slave node
• slave node 复制数据时不会block master node的正常工作
• slave node 复制数据时也不会 block 自己的查询操作，它会用旧的数据提供服务，但是完成复制后需要删除旧数据加载新数据，这时会暂停对外服务
• slave node 主要用来进行横向扩容做读写分离，提高读的吞吐量

另外，主从架构建议开启master node的持久化，避免master宕机重启后数据为空，然后一经复制，slave node的数据也丢失了。还有master的备份方案也需要考虑，可以在本地文件丢失后能有备份恢复master，确保master启动时是正常有数据，即使slave node可以自动接管master node，但也可能sentinel还没检测到master failure，master node就自动重启了，就还会发生复制到slave node数据全部丢失的情形。

主从复制的原理

当启动一个slave node的时候，它会发送一个PSYNC命令给master node。如果这是slave node初次连接到master node，会触发一次full resynchronization全量复制，此时master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端新收到的所有写命令缓存在内存中。RDB文件生成文件后，master会将这个RDB发送给slave，slave会写入本地磁盘，然后再从本地磁盘加载到内存中，接着master会将内存中缓存的写命令发送到slave，slave也会同步这些数据。slave node如果跟master node有网络故障断开连接会自动重连，此时master node只会复制slave缺少的那部分数据。

主从复制的断点续传

从redis2.8开始支持主从复制的断点续传，如果主从复制过程中网络断开，那么可以接着上次复制的地方继续复制下去，而不是从头复制一份。

master node 会在内存中维护一个backlog ，master 和 salve 都会保存一个 replica offset 还有一个master run id ，offset就是保存再backlog中的。如果 master 和 slave 网络连接断了，salve 会让 master 从上次 replica offset 开始继续复制，如果没有找到对应的 offset ，那么会执行一次 resynchronization 全量复制。

如果根据 host + ip 定位 master node 是不知道是否复制过的，如果 master node 重启或者数据发生了变化，那么 slave node 应该根据不同的 run id 区分。

无磁盘化复制

 master 再内存中直接创建RDB，然后发送给 salve ，不会再自己本地落地磁盘了，只需要再配置文件中开启 repl - diskless -sync yes

repl - diskless - sync yes

过期key处理

 slave 不会过期 key，只会等待 master 过期 key。 如果 master 过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条 del 命令发送给slave

复制的流程

slave node 启动时，会在本地保存master node 的信息，包括 master node 的 host 和 IP ，但是复制流程还没开始。

slave node 内部有个定时任务，每秒检查是否有新的 master node 要连接和复制，如果发现，就跟 master node 建立 socket 网络连接。然后 slave node 发送 ping 命令给 master node 。如果master设置了requirepass，那么slave node 必须发送 masterauth 的口令过去进行认证，master 第一次执行全量复制，后续持续将写命令异步复制给slave

全量复制

 master 执行 bgsave ，在本地生成一份RDB快照文件。

master node 将RDB快照文件发送给salve node ，如果RDB复制时间超过60秒，slave node 会认为复制失败，当然这个参数可以适当调大

master node 在生成RDB时，会将所有新的命令缓存在内存中，在slave node保存了RDB之后，再将新的命令复制给slave node

如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败

slave node 接收到RDB之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，同时基于旧的数据版本对外提供服务

如果slave node 开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF

增量复制

如果全量复制过程中断，slave 重新连接 master 时，会触发增量复制

master 直接从自己的backlog 中获取部分丢失的数据，发送给slave ，默认backlog是1MB

master 是根据slave 发送的psync 中的offset 来从 backlog 中获取数据的

异步复制

master 每次接收到写命令之后，先在内部写入数据，然后异步发送给salve node

主从节点互相都会发送heartbeat信息，master 默认每隔10秒发送一次heartbeat，slave 每隔一秒发送一个heartbeat

Redis哨兵集群(实现高可用)

如何高可用？

一个salve挂掉是不会影响可用性的，还有很多slave在提供相同数据下的相同读服务。但是mater挂掉之后，主从就全部失效了。redis的高可用架构，叫做failover故障转移，也叫主备切换。就是master在故障时，自动检测，并且将某个slave自动切换为master。这时就可以使用哨兵的机制进行监控、通知、故障转移、配置更新等操作了。

sentinel 哨兵，用于实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 集群监控：监控redis 所有master和slave进程是否正常工作
• 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
• 故障转移：如果master挂掉了，会自动转移到slave上
• 配置中心：如果故障转移发送了，通知client客户端新的master地址
• 故障转移时，判断一个master是否宕机，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
• 即使部分哨兵也挂了，哨兵集群也是能正常工作的，保证了监控高可用机制的自身也是高可用的。

slave→master（如何选出新的master进行主备切换）

• 判断slave与master断开时间的长短，短的优先
• 断开时间相同的话 根据offset判断复制数据的多少，复制多的优先
• 复制相同的判断run id，小的优先

redis实现高并发主要依赖主从架构，同时需要缓存大量数据的话就需要redis集群了，此时再加上哨兵就可以实现任何一个实例宕机都能进行主备切换的高可用。

Redis的一些特性

RDB的优缺点

AOF的优缺点

REDIS的事务：放弃了回滚

一致性哈希算法原理（数据写入时选择节点，数据读取时找到所在节点）

redis 的单线程原子操作的设计