Redis 集群

Redis 集群

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秒哨兵才能生效

本文由 在码圈 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
您可以自由的转载和修改,但请务必注明文章来源并且不可用于商业目的。
本站部分内容收集于互联网,如果有侵权内容、不妥之处,请联系我们删除。敬请谅解!
原文链接:https://www.arcinbj.com/archives/redis集群
最后更新于:2020-03-27 11:24:35

请博主喝咖啡 ☕.