一、单机、单节点、单实例的问题
1、单点故障
2、容量有限
3、压力太大
二、AKF
1、X轴(做数据的副本):解决单点故障。
全量镜像,主提供读写,备提供读。
2、Y轴(数据按业务功能进行划分):解决容量有限。
3、Z轴(按优先级逻辑再拆分):解决压力问题。
同一个业务,0到999放到一个Redis库里,1000到1999放到一个Redis库里,也就是一个业务放到多个Redis库里,同时也得加上规则,让对应的数据能够放到对应的库里。
主备与主从的区别?
主备:客户端只能访问主,不能访问备用机,备用机是在主挂掉之后能够接替主,然后对外提供服务。
主从:客户端不仅能访问主,还能访问备用机。
主自己也是一个单节点,所以一般会对主做HA(高可用)。高可用不是说主不会挂,而是主挂掉之后马上能够重新选择一个备机或从机作为主,对外表现是一直可用的。
通过AKF实现一变多,数据一致性问题如何解决?
1、强一致性:所有节点阻塞,直到所有数据全部一致。如果其中一个节点因为网络问题导致数据迟迟不能同步,不能一致,那么整个集群都在阻塞着,就不可用了,所以极易破坏可用性。而一变多就是为了解决单节点的单点故障、可用性的问题,而强一致性又破坏了可用性。
2、弱一致性:容忍数据丢失一部分。通过异步方式同步数据。
3、最终一致性:通过一个集群可靠快速的中间件(例如kafka)来同步数据,保证数据的一致性。
三、Replication(复制)
Redis使用默认的异步复制,其特点是低延迟和高性能。也就是采用的弱一致性。
1、窗口1:cd ~,mkdir test,cd test
2、窗口2:cd /root/soft/redis-5.0.9/utils
(1)./install_server.sh 6381
(2)service redis_6379 stop(停掉所有redis)
3、窗口1:cp /etc/redis/* ./
(1)vi 6379.conf,
(2)daemonize yes改为no(前台阻塞运行),
(3)#logfile /var/log/redis_6379.log(注释掉日志文件),
(4)appendonly yes改为no(不产生aof)。6380,6381也做同样的修改。
4、窗口2:cd /var/lib/redis/6379,rm -rf ./*,6380,6381也做同样的修改。
5、窗口1:redis-server ~/test/6379.conf
6、窗口2:redis-server ./6380.conf
7、新开一个窗口(窗口3):redis-server ./6381.conf
8、新开3个窗口分别连上3个server,keys *查看是否为空。
9、窗口7:cd /var/lib/redis 查看6379、6380、6381是否为空。
10、窗口5(连接6380服务器的客户端):REPLICAOF 127.0.0.1 6379(5.0之前是SLAVEOF 127.0.0.1 6379),6380以6379作为主节点。(此时在连接6379的客户端的读写操作会同步到6380上,6380默认只能读、不能写)
11、窗口6(连接6381服务器的客户端):REPLICAOF 127.0.0.1 6379(连接后,之前6379的数据会同步过来,同时自己的老数据会被清空)
12、窗口7:此时/var/lib/redis下6380和6381就有数据了
13、窗口3:Ctrl+c(模拟从节点挂掉),然后再redis-server ./6381.conf --replicaof 127.0.0.1 6379(此时6381不会flush old data,同时会把它挂掉之后主节点的数据进行增量更新)。此时主节点6379不会落rdb文件(以redis-server ./6381.conf --replicaof 127.0.0.1 6379 --appendonly yes启动 主节点又会落rdb文件,自己会落aof文件)。
14、窗口1:Ctrl+C(模拟主节点挂掉),此时6380和6381仍然只能读,主节点之前的数据还能查询。
15、窗口5:replicaof no one(不再追随6379,自己成为主节点)。
16、窗口6:REPLICAOF 127.0.0.1 6380。
四、配置文件
1、replica-serve-stale-data yes(当连接到某个主节点后到load主节点的RDB文件结束期间,是否对外提供旧数据的查询)
2、replica-read-only yes(从节点是否只读)
3、repl-diskless-sync no(no:主节点先把数据load到磁盘,再通过网络发送给从节点;yes:主节点直接把RDB文件通过网络发送给从节点)
4、# repl-backlog-size 1mb(从节点挂掉后,到重新恢复期间主节点产生的数据可以存储在一个队列里<这就是配置此队列的大小>,从节点恢复后可以根据偏移量直接从此队列取增量数据,而不需要再次同步全量数据)
5、# min-replicas-to-write 3,# min-replicas-max-lag 10(最小必须向几个从节点写成功数据),开启就渐渐向强一致性靠拢。
五、High Availability(高可用)
Redis Sentinel是Redis官方的高可用性解决方案。
1、监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2、提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3、自动故障迁移(Automatic failover):当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为追随新的主服务器;当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
演示:
1、停掉所有节点,退出所有客户端。
2、窗口1:vi 26379.conf,输入
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
3、窗口1:cp 26379.conf 26380.conf,cp 26379.conf 26381.conf,修改端口号
4、窗口1:redis-server ./6379.conf
5、窗口2:redis-server ./6380.conf --replicaof 127.0.0.1 6379
6、窗口3:redis-server ./6381.conf --replicaof 127.0.0.1 6379
7、窗口4:cd ,cd test/,redis-server ./26379.conf --sentinel(此时通过日志可以看到,尽管配置文件只配置了监控6379主节点,但是却显示了此主节点的两个从节点,是通过发布订阅来实现的)
8、窗口5:cd ,cd test/,redis-server ./26380.conf --sentinel(不仅显示了主节点下的从节点信息,还显示了该主节点的其他sentinel)
9、窗口6:cd ,cd test/,redis-server ./26381.conf --sentinel
10、窗口1:Ctrl+C,模拟主节点挂了,因为网络问题不会立马就选出一个主节点来。(同时sentinel会修改自己的配置文件)
11、窗口7:连上6380的client,PSUBSCRIBE * (可以看到各个sentinel之间发送的消息)
12、redis源码路径/root/soft/redis-5.0.9下的sentinel.conf文件可以看到哨兵的配置文件信息。