双机热备的原理
夜半惊魂
上次的文章《负载均衡的原理》中讲到，张大胖在Bill的指导下，成功地开发了一个四层的负载均衡软件， 把流量“均匀地”分发到了后面的几个服务器中， 获得了老板的1000块钱奖励。
但是张大胖心中隐隐不安，总觉得系统埋着一颗定时炸弹，随时会引爆，这个炸弹就是： Load Balancer 只有一台服务器，万一这个服务器挂掉了怎么办？
没有了Load Balancer这个入口，用户的请求无法分发过来，后面的这些服务器只能干瞪眼了。
系统有“单点失败（Single Point of Failure）”的风险就是这个意思。
有一天晚上张大胖做了一个梦，梦见这个Load Balancer在高峰期挂掉了，导致整个系统瘫痪，看到损失了无数的订单， 愤怒的老板不停地向他咆哮：扣你小子半年工资。
吓得张大胖半夜醒来，出了一身冷汗。
不想单点失败该怎么办？ 张大胖稍微思索下就能想到解决方案： 上两台Load Balancer ！
可问题是：客户端究竟要访问哪一个？
还用DNS轮询的方式？ 那就回到最原始的问题了。
在这两个Load Balancer之前再加一个Load Balancer？ 那岂不又是单点失败？
不，这个路子是走不通的。
张大胖准备另辟蹊径。
在客户端看来，这两个Load Balancer 最好是一个整体，就像一个虚拟的服务器， 这个虚拟的服务对外提供一个IP (简称VIP)。
两个Load Balancer中，一个叫做Master， 另外一个可以叫做Backup ， 平时Master 负责干活， Backup待命，一旦Master挂掉， Backup 服务器立刻接管。 在外界看来，那个虚拟的服务器还在工作，并不知道内部发生的“大地震”。
想到这里，张大胖激动起来，竟然睡不着了， 干脆爬起来看邮件，写代码。
详细设计
第二天，张大胖七点就来到了公司，想着把昨晚的方案给Bill 汇报下。
可是他来得太早了，公司空无一人。 罢了，很多细节还没有完善，先不着急。
首先是这个虚拟的VIP ， 怎么才能实现在两个服务器之间的“IP漂移”呢？
张大胖曾经记得，一个网卡可以设置多个地址，比如在Linux上eth0表示网卡1，它可以绑定一个IP， 与此同时，还可以设置一个ip alias 或者 secondary ip 。
eth0 --> 192.168.1.10
eth0:1 --> 192.168.1.100
张大胖想： 我可以让这个192.168.1.100为VIP，如果服务器是Master， 就可以把这个IP给绑定上， 如果是Backup，那就不绑定。
换句话说，通过动态地绑定/解绑 就可以让这个VIP在两个服务器之间来回“漂移”了。
“IP漂移”的问题可以这么解决， 但是那个Backup 怎么知道Master 挂掉了呢？
从道理上说，很简单，只需要让Master不断地给Backup发“心跳”消息即可(可以采用广播的方式发消息)， 这个Backup(LoadBalancer2)得有个定时器， 如果在一个特定的时间（嗯，这个时间应该可以设置）内收不到心跳，那就认为Master完蛋了，就需要挺身而出，擦干眼泪，继承前任的遗志，很Happy地绑定VIP , 继续伟大的革命事业。
可是那个之前的Master（LoadBalancer1）如果又活了呢？
LoadBalancer2 该怎么办？革命的康庄大道还没走几步， 就要拱手让出还没捂热乎的VIP吗？
如果LoadBalancer1是个性能更加强悍的机器，同志们肯定希望由他来统领全局。
这里得定义一个策略，每个机器都得有个优先级（一个整数），在允许抢占的情况下，谁的优先级高，谁就是Master！
张大胖想到： 看来需要我开发一个软件了，实现这些通信“协议”和策略， 这个软件需要安装运行在每个Load Balancer上，让他们组成单个虚拟的Load Balancer， 对外提供服务。
在每个Load Balancer中，状态转换是这样的， 张大胖画了一张图：
汇报工作
到了9点钟， CTO Bill 准时上班， 张大胖赶忙跑去向领导汇报昨晚和今早的思想动态。
Bill 听完，沉吟片刻，说道：“这个主意不错，我支持！ 可是。。。。。。”
张大胖立刻紧张起来， 自己想得挺完善的啊，难道还有问题？
只听Bill 说道：“你可以让那个IP地址在两个主机之间漂移，实现主备切换， 但是MAC地址怎么办？ ”
张大胖说：“MAC地址 ? 关MAC地址什么事？ ”
啊 ！ 他突然明白了，确实是忽略了， IP包是被封装在以太网帧中发送的，其中需要MAC地址。
在发送第一个请求的时候，客户端（确切说是直接向Load Balancer发数据的那个机器）先是知道了VIP（如：192.168.1.100）， 接下来它需要知道这个VIP的MAC地址，这样才能发送数据。
为了拿到MAC地址，它需要发起ARP查询： 这个VIP（192.168.1.100)的 MAC的地址是什么？
如果Load Balancer 1是Master ，就会回复： 是23:39:8D:9C:0A:33 （记为 MAC1）
这时候客户端就会缓存，记下来。
然后Load Balancer 1 挂掉， Load Balancer 2 成为 Master。
此时客户端如果再次发送数据，还会往MAC1去放送，于是就出错了。
想通了这一层， 张大胖犯了愁， 这可怎么办？
Bill 提醒道：“你不是有个虚拟的IP地址吗？ 是不是也可以搞一个虚拟的MAC地址啊！”
张大胖如梦方醒： “对对， 无论是哪个机器成为Master， 每次响应ARP请求的时候，都返回这个虚拟的MAC地址。这样客户端面对的MAC地址就唯一了。”
看来虚拟IP + 虚拟的MAC 地址才能完整地解决问题！
申请机器
张大胖把软件开发出来了，小心翼翼地向抠门的老板去申请机器，老板看了方案，提了一个让张大胖大跌眼镜的问题： “你这里整了两个Load Balancer服务器， 但是平时只用一个，另外一个一直空闲，是不是极大的浪费啊？”
怎么办？张大胖挠了挠头，犯难了。
聪明的你估计已经想到办法了，赶紧留言吧，给出解决方案的前5名分享100元红包。
相关阅读：
（完）
你看到的只是冰山一角， 更多精彩文章，请移步《2016文章精华》或者《2017文章精华》
码农翻身
用故事讲述技术