Redis 集群

介绍

1.单机、单实例的持久化方式

rdb（relation-ship database）持久化：
默认redis会以一个rdb快照的形式，将一段时间内的数据持久化到硬盘，保存成一个dumpr.rdb二进制文件。
工作原理：当redis需要持久化时，redis会fork一个子进程，子进程将数据写到磁盘上临时一个RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write。

配置redis.conf:
save 900 1
save 300 10
save 60 10000

在900秒内，如果有一个key被修改，则会发起快照保存。300秒之内，如果超过10个key被修改，则会发起快照保存。在60秒内，如果1w个key被修改，则会发起快照保存。

aof（append-only file）持久化：
默认会以一个appendonly.aof追加进硬盘。

redis.conf默认配置:
appendfsync yes
appendfdync always
#每次有数据修改都会写入AOF
appendfsync everysec
#每秒同步一次，策略为AOF的缺省策略

2.单节点、单实例面临的问题：

• 单点故障
• 容量有限
• 压力

面对这么多问题，我们解决的方式是，将单节点变为多节点进行架构：

1.进行读写分离。

2.基于三维进行扩展AKF。

• X轴进行全量镜像的节点复制（从单库到多库）

• Y轴进行业务功能分离（根据业务逻辑再次进行分库）

• Z轴进行优先级逻辑再拆分（单业务进行分片，如MR的DataNode，单业务进行分节点运算）

3.进行集群化面临的几个问题：

1.数据一致性

分量数据不能保证一致，如果保证一致，那么就会丢失可用性。如果我们保证数据的强一致性，那么，我们将会破坏可用性（数据在同步，不能保持可用）。

2.数据完整性

我们保证弱一致，可能会取到错误数据。

3.数据最终一致性

我们如图3的价架构，在中间放一个类似kafka之类的中间件，然后我们能保证最终一致性。（kafka通过一定技术，变得可靠）

4.分布式常见的几个架构：

主备架构：主机死了，备机可以顶

主从复制：主机后面有几个从节点。（redis用的是主从复制）

主从复制架构，又面临一个问题，单点故障怎么解决？

我们对主进行HA架构，用一个程序进行监控，该监控程序，为了避免单点故障，那么也必须是一个集群架构。

我们的监控设备一定是奇数台，进行过半选举，如果过半都选举故障，那么，将会跳到另一台节点。

配置

1.解压

准备一个redis的tar包，进行解压。

2.启动节点并跟随

启动3个实例，从节点使用replicaof ip port这个命令进行跟随主节点。

（注意，在redis 5之前，我们可以通过slaveof进行跟随主节点，但是，从redis5之后，改为了replicaof进行跟随）

3.使用追加方式

开启时候，使用appendonly yes这个配置，进行追加的方式进行写入集群。

是有用dump.rdb全量备份的时候，可以进行追随主节点

使用appendonly进行增量备份，是无法进行追随主节点的

4.主节点挂机

手动将主节点挂机

从节点可以变为主节点，直接使用replicaof no one命令

哨兵

1.启动3个哨兵，进行监控

命令是：

1.redis-server ./26379.conf --sentinel
2.也可以直接启动redis-sentinel

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

26379.conf文件只需要2行

第二行语义：哨兵 监控 监控名 ip 端口 几票通过

需要过30秒哨兵才能生效