Keepalvied
Keepalived是一个基于VRRP协议来实现的服务高可用方案，可以利用其来避免IP单点故障。
原理：每一台机器都有一个Keepalived，每个Keepalived都有一个自己的 ip，那就是一共有n个ip，但是所有的Keepalived只有一个共同的虚拟ip，n个ip都去抢这个虚拟ip，前端发起的请求将会落在抢到虚拟ip的那台机器上。同理，每一台机器上都有nginx和keepalived，配置nginx主从模式，一般主的优先级大于从的，所以主是好的话，主能抢到虚拟ip，一般的请求会访问这个虚拟ip，进而请求就会落在主这台机器上;但是如果主宕了的话，keepalived会检测到主已经挂了，就让从去抢到这个虚拟ip，所以来访问的时候，请求就会落在从机器上，达到高可用效果。
keepalived脑裂： 当联系2个节点的“心跳线”断开时，本来为一整体就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障，两个节点上就会争抢“共享资源”、争起“应用服务”，就会发生严重后果，两边“服务”都起不来了；或者两边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）
nginx 高可用
每一台机器都有一个Keepalived和一个nginx，配置主从关系，多个nginx用同一个配置文件
MASTER 服务的keepalived.conf
global_defs {
}
vrrp_instance VI_1 {
state MASTER #指定A节点为主节点 备用节点上设置为 BACKUP 即可
interface eth0 #绑定虚拟IP的网络接口
virtual_router_id 51 #VRRP组名，两个节点的设置必须一样，以指明各个节点属于同一VRRP组
priority 100 #主节点的优先级（1-254之间），备用节点必须比主节点优先级低
advert_int 1 #组播信息发送间隔，两个节点设置必须一样
authentication { #设置验证信息，两个节点设置必须一样
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { #指定虚拟IP，两个节点设置必须一样
192.168.116.120/32 #如果两个nignx的ip分别是192.168.116.128,.......129，则此处的虚拟ip跟他俩同一个网段即可
# 192.168.200.16
# 192.168.200.17
# 192.168.200.18
}
}
BACKUP服务的keepalived.conf
global_defs {
}
vrrp_instance VI_1 {
state BACKUP #指定A节点为主节点 备用节点上设置为 BACKUP 即可
interface eth0 #绑定虚拟IP的网络接口
virtual_router_id 51 #VRRP组名，两个节点的设置必须一样，以指明各个节点属于同一VRRP组
priority 99 #主节点的优先级（1-254之间），备用节点必须比主节点优先级低
advert_int 1 #组播信息发送间隔，两个节点设置必须一样
authentication { #设置验证信息，两个节点设置必须一样
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { #指定虚拟IP，两个节点设置必须一样
192.168.116.120/32 #如果两个nignx的ip分别是192.168.116.128,.......129，则此处的虚拟ip跟他俩同一个网段即可
# 192.168.200.16
# 192.168.200.17
# 192.168.200.18
}
}
这样当master主服务器的keepalived停止服务，slave从服务器会自动接管对外服务；一旦主服务器的keepalived恢复，会重新接管对外服务。但这并不是我们需要的，我们需要的是当NginX停止服务的时候能够自动切换。
原理：
keepalived支持配置监控脚本，我们可以通过脚本监控NginX的状态，如果状态不正常则进行一系列的操作，最终仍不能恢复NginX则杀掉keepalived，使得从服务器能够接管服务。
思路：
由于keepalived并不跟nginx耦合，他俩完全不是一家人，但是keepalived提供了一个机制：让用户自定义一个shell脚本去检测进程状态并在进程下线后尝试重启进程
MASTER 服务的keepalived.conf
global_defs {
}
#检测脚本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动
interval 2 #（检测脚本执行的间隔，单位是秒）
weight 2 #权重
}
#vrrp 实例定义部分
vrrp_instance VI_1 {
state MASTER # 指定keepalived的角色，MASTER为主，BACKUP为备
interface eth0 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡
virtual_router_id 51 # 虚拟路由编号，主从要一致
priority 100 # 优先级，数值越大，获取处理请求的优先级越高
advert_int 1 # 检查间隔，默认为1s(vrrp组播周期秒数)
#授权访问
authentication {
auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信
auth_pass 1111
}
track_script {
chk_http_port #（调用检测脚本）
}
virtual_ipaddress {
192.168.116.120/32 #如果两个nignx的ip分别是192.168.116.128,.......129，则此处的虚拟ip跟他俩同一个网段即可
# 192.168.200.16
# 192.168.200.17
# 192.168.200.18
}
}
BACKUP服务的keepalived.conf
global_defs {
}
#检测脚本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动
interval 2 #（检测脚本执行的间隔，单位是秒）
weight 2 #权重
}
vrrp_instance VI_1 {
state BACKUP #指定A节点为主节点 备用节点上设置为 BACKUP 即可
interface eth0 #绑定虚拟IP的网络接口
virtual_router_id 51 #VRRP组名，两个节点的设置必须一样，以指明各个节点属于同一VRRP组
priority 99 #主节点的优先级（1-254之间），备用节点必须比主节点优先级低
advert_int 1 #组播信息发送间隔，两个节点设置必须一样
authentication { #设置验证信息，两个节点设置必须一样
auth_type PASS
auth_pass 1111
}
track_script {
chk_http_port #（调用检测脚本）
}
virtual_ipaddress { #指定虚拟IP，两个节点设置必须一样
192.168.116.120/32 #如果两个nignx的ip分别是192.168.116.128,.......129，则此处的虚拟ip跟他俩同一个网段即可
# 192.168.200.16
# 192.168.200.17
# 192.168.200.18
}
}
检测脚本 check_nginx_pid.sh
#!/bin/bash
#检测nginx是否启动了
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then #如果nginx没有启动就启动nginx
systemctl start nginx #重启nginx
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then #nginx重启失败，则停掉keepalived服务，进行VIP转移
killall keepalived
fi
fi
mysql 高可用
双节点主从 + keepalived
两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个VLAN中，在master节点发生故障后，利用keepalived的高可用机制实现快速切换到slave节点， 和上面nginx的高可用一样，也是通过编写shell 脚本去检测进程状态。
主从模式
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行。主从的切换需要手动或者借助第三方工具，比如mycat实现自动主从切换。
主从复制的原理
（1）master服务器将数据的改变记录二进制binlog日志，当master上的数据发生改变时，则将其改变写入二进制日志中；
（2）slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件
（3）同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。
主从模式的另一个作用：读写分离
在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。
双主模式
双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。这样做可以在一定程度上保证主库的高可用,在一台主库down掉之后,可以在极短的时间内配合keepalived切换到另一台主库上（尽可能减少主库宕机对业务造成的影响），减少了主从同步给线上主库带来的压力；
思路是:
1.两台mysql都可读写，互为主备，默认只使用一台（masterA）负责数据的写入，另一台（masterB）备用；
2.masterA是masterB的主库，masterB又是masterA的主库，它们互为主从；
3.两台主库之间做高可用,可以采用keepalived等方案（使用VIP对外提供服务）；
4.所有提供服务的从服务器与masterB进行主从同步（双主多从）;
5.建议采用高可用策略的时候，masterA或masterB均不因宕机恢复后而抢占VIP（非抢占模式）；
不足的地方:
1.masterB可能会一直处于空闲状态（可以用它当从库，负责部分查询）；
2.主库后面提供服务的从库要等masterB先同步完了数据后才能去masterB上去同步数据，这样可能会造成一定程度的同步延时；
有几个需要注意的地方：
- 采用keepalived作为高可用方案时，两个节点最好都设置成BACKUP模式，这样不会导致MASTER重新上线后抢夺BACKUP，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突；
- 把两个节点的auto_increment_increment（自增起始值）和auto_increment_offset（自增步长）设成不同值。其目的是为了避免master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应用，从而会导致slave新写入数据的自增值和原先master上冲突了，因此一开始就使其错开；当然了，如果有合适的容错机制能解决主从自增ID冲突的话，也可以不这么做；
- keepalived的检测机制需要适当完善，不能仅仅只是检查mysqld进程是否存活，或者MySQL服务端口是否可通，还应该进一步做数据写入或者运算的探测，判断响应时间，如果超过设定的阈值，就可以启动切换机制；
- keepalived最终确定进行切换时，还需要判断slave的延迟程度。需要事先定好规则，以便决定在延迟情况下，采取直接切换或等待何种策略。直接切换可能因为复制延迟有些数据无法查询到而重复写入；
- keepalived自身都无法解决脑裂的问题，因此在进行服务异常判断时，可以调整判断脚本，通过对第三方节点补充检测来决定是否进行切换，可降低脑裂问题产生的风险。
更多demo请关注
springboot demo实战项目
java 脑洞
java 面试宝典
开源工具
公众号（五分钟技术）
五分钟了解前沿技术，大数据，微服务，区域链，提供java前沿技术干货，独立游戏制作技术分享
如果这篇文章对你有帮助请给个star
