本文共 1383 字，大约阅读时间需要 4 分钟。
单点故障在运维过程中时常出现，单点故障这里仅指程序自身设计问题导致无法扩展，而不是因为资金预算不到位造成的单点。
下面简单介绍两种情景下，解决单点故障的运维方案。
问题一
某服务端程序对外提供服务，监听在某个端口对外提供服务，在整个运维环境中只能存在一份，无法扩展，同时要保证它的高可用性。这里假设服务端IP 为10.1.1.23 ，端口为7788 。
解决方案：
1、在服务端搭建keeeplived高可用环境，让程序监听在VIP上，让VIP在两台或多台主机间漂移
修改服务端配置
| 1 | listen 10.1.1.23:7788； |
2、修改内核参数
| 1 | sysctl -w net.ipv4.ip_nonlocal_bind=1 |
这个参数允许程序监听在一个不存在的地址上而不报错。
3、在各个节点上开启相应的程序。
点评：这种问题比较常见，可通过高可用软件或者负载均衡软件来解决。
问题二
某客户端程序在整个运维环境中只能存在一份，无法扩展，同时需要保证它的高可用性。客户端程序固定连接上游的某个服务端。这里假设上游服务器IP为10.1.1.23端口为1123，客户端本地IP为10.1.1.34 VIP为10.1.1.45 。
解决方案：
1、搭建keepalived高可用环境，让VIP在两台或多台主机间漂移。
2、修改客户端本地出站到上游服务端的源IP为VIP，
| 1 | iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.34 -d 10.1.1.23 --dports 1123 -j SNAT --to- source 10.1.1.45 |
如果VIP在本地，那么本机和上游就可以通讯；反之，如果VIP不在本地，与上游就无法通讯；
总之就是在多客户端与服务端之间建立一个阻塞式的通道。
（存疑：fail-over时，由于客户端IP是VIP保持不变，可利用tcp协议重连机制来重新建立连接。）
点评：这种问题比较奇葩，但还是有解决方案，解决方案也算是一种奇葩，特事特办。
总结
既然是单点故障，那必定得容忍fail-over时可能造成的数据丢失，剩下的就是数据同步问题了，尽量减少fail-over造成的损失。
相关资料
1、一个主机上存在多个IP的情况下，网卡上的第一个IP为primary IP，其它IP为secondary IP，
primary IP 无法修改，除非卸载IP
当该主机为客户端时，发往服务端的请求会固定从primary IP 出站
当该主机为服务端时，客户端请求哪个IP，流量就会从哪个IP出站
2、iptables 执行流程中，nat表优先于filter表
3、linux内核关于tcp重连的一些参数
| 1 2 3 4 5 | net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 |