Redis集群
介绍
1.单机、单实例的持久化方式
在我们之前的课程中，我搭建了一个单机，单进程，缓存redis。我们使用rdb,aof持久化，用来确保数据的安全。
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秒哨兵才能生效