文章目录
Redis的几种部署方式？
1.单例 2.主从+哨兵（高可用，主机宕机，根据哨兵投标选举 将从机升为主机） 3.集群（扩展性）
一、单机模式
这种方式就是直接部署一个redis实例，既：部署一台redis服务。
二、主从模式
部署一台redis主服务master，多台redis从服务slave，master主服务专门用于redis的写操作，所有的slave从服务专门用于redis的读操作。在master主服务接受到写命令的时候，会将数据同步到所有的slave从服务。
主机down掉，从机无法升为主机
资源利用率低，master压力大，slave基本无压力
1.主从复制流程
slave初始化后全量复制，正常情况下增量复制。
主从全量（master的全部数据）复制的流程：
引用图片：
（1）slave服务器连接到master服务器，便开始进行数据同步，发送psync命令（Redis2.8之前是sync命令）
（2）master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令。如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是每个连接都执行一次，然后再把这一份持久化的数据发送给多个并发连接的slave。如果RDB复制时间超过60秒（repl-timeout），那么slave服务器就会认为复制失败，可以适当调节大这个参数
（3）master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令。
client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败。
（4）slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。
（5）master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令
（6）slave服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
1.1.Redis中master与slave，怎么判断同步进度？
主库（master)会记录自己写到的位置master_repl_offset
从库（slave)也会记录自己已经读取到的位置slave_repl_offset
计算两者差值为同步进度
三、Sentinel哨兵模式
至少3个，保证健壮性，且为奇数个。
Redis Sentinel着眼于高可用。哨兵模式，主要是为了解决主从模式下，master主服务不可用的情况。 一般都是：一主二从三哨兵，一个master主服务，两个slave从服务，部署三个哨兵服务。哨兵服务会监控所有的主从服务，按照每秒一次的频率向所有主从服务发送ping命令，如果在指定时间里面，没有接收到主服务的PONG回应，则哨兵服务会认为主服务不可用了，此时会根据一定的规则，通过选举投票方式，将一台从服务提升为master主服务，并且告诉所有其他的从服务，跟随这台新的master主服务。当之前那台主服务重新上线后，它会变成从服务，跟随新的主服务。
引用图片：
四、cluster集群部署
所有主节点共享16384个solt槽位，当数据库中的16384个槽都有节点在处理时，集群处于上线状态（ok）；相反地，如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态（fail）。
Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。Redis Cluster 采用虚拟哈希槽分区，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，每个key通过CRC16校验后对16384取模来决定放置哪个槽(Slot)，每一个节点负责维护一部分槽以及槽所映射的键值数据。计算公式：slot = CRC16(key) & 16383。
这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。使用哈希槽的好处就在于可以方便的添加或移除节点。
当增加节点时，把其他节点的某些哈希槽挪到新节点即可；
当移除节点时，把移除节点上的哈希槽挪到其他节点即可。
引用图片：
1.为什么是16384个solt位？
CYC16校验的范围为0-65535，为什么是16384个solt槽位？
两个redis节点之间通信时，需要在客户端执行一个命令，让双方知道彼此：127.0.0.1:7000>cluster meet 127.0.0.1:7001握手成功后，两个节点之间会定期发送ping/pong消息，用于交换信息：
引用图片：
1、 定期
1）每秒随机选取5个节点，找出最久没有通信的节点发送ping
2）每100ms都会扫描本地节点列表，如果发现节点最近一次接收pong消息的时间大于cluster-node-timeout/2，则发送ping
引用图片：
2、交换的信息 = 消息头 + 消息体
1）消息头
引用图片：
消息头里面有个myslots的char数组，长度为16383/8，这其实是一个bitmap,每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。所以，槽位越多，消息头越大。
2）消息体
包括节点标识、ip、端口、发送时间……其中会携带一定数量的其他节点（总节点数的1/10，至少3个节点）信息用于交换。所以，节点越多，消息体越大。
3、答案
槽位越大，消息头中的myslots[CLUSTER_SLOTS/8]数组越大，每秒需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大，浪费带宽。
节点越多，心跳包的消息体越大，超过1000个节点，会导致网络拥堵。所以redis作者不建议超过1000个节点。对于1000个节点，16384个solt够用。
Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率（文件大小前后比）就很低。节点少，槽位多，bitmap压缩率低。
Redis两种持久化方式（RDB、AOF）
为了防止Redis崩溃，内存中的数据丢失，导致大量请求打到数据库，引发雪崩。引入持久化，在硬盘中备份数据，当Redis重启后可以直接加载备份数据，避免雪崩。
数据安全级别较高，可以同时开启RDB与AOF，数据恢复时，Redis优先使用AOF文件来恢复数据集。
一、RDB（默认）
为了节约空间，定义一个二进制格式，把数据一条条码在一起，生成一个rdb文件。如此设计，数据量比较大，不能频繁的去做，而且为了保证自身性能，fork一个子进程去完成相应操作。并且，如果一直是读取操作，没有写入，此时不需要备份，避免浪费时间，提供配置参数：
• save 900 1 # 900秒（15分钟）内有1个写入
• save 300 10 # 300秒（5分钟）内有10个写入
• save 60 10000 # 60秒（1分钟）内有10000个写入
优点：RDB是一个非常紧凑的文件，它保存了Redis在某个时间点的数据集，利于还原到指定时间的版本。比AOF还原块。
缺点：RDB需要保存整个数据集的状态，资源消耗多，不能频繁的做。当发生故障时，可能会丢失几分钟内的数据。
二、AOF
RDB备份周期是分钟级的，服务器秒内多响应不太满足。借鉴MySQL中binlog（记录数据更改操作的日志），把所有写入命令记录下来，写入到一个文件中，称之为AOF（Append Only File）。
1.多久写入一次？
防止拖垮性能，不能每执行一个写入命令就记录一次。设置一个aof_buf命令缓冲区。aof_bug缓冲区写入到AOF的数据会被操作系统缓存，为了解决这个问题，增加刷新参数：appendfsync参数取值：
• always: 每个事件周期都同步刷新一次
• everysec（默认）: 每一秒都同步刷新一次
• no: 我只管写，让操作系统自己决定什么时候真正写入吧
2.AOF重写
防止随着时间的推移，AOF文件越来越大，称之为AOF重写。
瘦身：省略数据中间值，指令合并
例如，
• RPUSH list ‘123’
• RPUSH list ‘456’
合并成一条指令：
• RPUSH list ‘123’ ‘456’
为了不影响，自身性能，fork一个子进程去完成。
3.AOF重写数据一致性
AOF重写期间，修改了AOF，导致数据不一致。
引入aof_rewrite_buf缓冲区，将期间的指令缓存，AOF重写完成之后，写入到新的AOF中，保证数据一致性。
优点：AOF默认每秒fsync一次，最多丢失一秒的数据。
缺点：AOF体积大于RDB，使用sync策略，可能会慢于RDB。
友情链接：
1）Redis——java连接操作Redis数据库、spring整合Redis
2）杂记——win 安装、配置Redis（connection timed out: /x.x.x.x:6379、no further information: /x.x.x.x:6379）
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
