系统架构实践与总结-冗余

冗余是架构设计上常用的技术手段，通常用来保证系统的高可用。

典型应用场景

下面具体介绍反向代理和MySQL集群两个场景下，如何通过冗余来保障高可用。

反向代理

传统的web站点，经常使用Nginx做反向代理。反向代理作为整个网站的入口，通常会承担流量转发、安全防护等工作，保证其高可用至关重要。为了保证反向代理的高可用，Nginx+Keepalived是一种常用的解决方案。

Nginx+Keepalived通常有两种实现方式：

1. 主备方案：一台机器对外提供服务，对应一个VIP；另外一台或多台做备份。正常状况下备机不接流量，当主机出现故障时，Keepalived检测到故障并执行切换逻辑。
2. 多主方案：每一台机器同时对外提供服务，对应多个VIP；当某一台机器出现故障时，Keepalived检测到故障将机器下线，并完成流量切换工作。

总结

本场景中，通过冗余提供超出实际访问量的Nginx服务和Keepalved检测，在故障发生时，完成流量切换以达到反向代理层的高可用。在主备份方案中，备机通常处于闲置状态，造成了“资源浪费“；而且在发生故障切换流量的过程中，主机上这一时段的请求会出现问题；而且突然大流量的切换也容易引发备机故障。相比之下多主的方案，多台机器都处于工作中，流量分布更加均匀，出现问题的概率更低，是更优雅的方案。不过在多主方案中，每一台机器平时承接的流量最好是其极限值的30%左右，如果过高的话当发生流量切换时容易出现连锁反应，过低会造成资源浪费。

不管是哪一种方案，都提供了冗余的承载能力，才能有后续的流量转移，所以在此场景下冗余是高可用的必要前提。

MySQL集群

介绍我了解的两种MySQL部署模式

MySQL+Keepalved

用户通过VIP访问Master和Slave节点，每个节点采用Keepalved探活。配置主从关系，进行数据同步。当Master节点故障时，把Slave节点提升为主节点。

基于MHA的高可用架构：

部署一份MHA的Manager节点，在MySQL各个实例部署MHA Node节点。MHA可以实现秒级的故障自动转移。当然MySQL节点之间的数据同步还要依赖MySQL自身的数据同步方式。

总结

以上两种数据库部署架构都采用了主从结构，以减轻 Master 节点的读压力。同时为了保证集群的高可用性，分别采用 Keepalived 和 MHA 完成故障迁移。不过这一切的前提还是冗余。

我们就拿 MySQL+Keepalved 这种部署方式来说，当 Master 节点发生故障需要下线时，所有的读写都需要迁移到 Slave 节点，这势必导致 Slave 节点流量上升，单个 Slave 节点如果没有冗余的能力能承接请求，Slave 节点也会很快发生故障。换句话说 Slave 节点在分担读流量的同时也为集群提供了冗余的处理能力。

更全面的考虑冗余

除了上述两种场景，在微服务架构中冗余设计的思路更是随处可见。不过要想把冗余设计好并没有那么简单。当我们考虑到时间、地理位置、时延、环境等因素时事情就变得复杂起来了。

时间维度：如何保证冗余服务的时间一致性；如何妥善处理故障迁移时间段内的请求都是比较难处理的问题。

地理位置：通过多中心、异地部署增强系统的高可用，此时还需要保证请求就近选择服务。

时延：在冗余的服务中，请求因为物理链路传输会产生时延，尤其是跨国业务，网络开销很容到达几百ms，此时要想保证冗余服务正常对接也是非常苦难的。

除了系统部署架构上的冗余，我们在开发具体的业务应用时也会用到冗余的思想，比如我们的数据源是否既可以从常规位置获取又可以从备份服务中获取；再比如为了应对网络环境的不稳定性，我们可以让浏览器同时发起两个长链接请求，选择率先链接成功的一个使用；再比如可以同时调用多个第三方服务，选择第一个返回的结果使用。

总结

本文我们介绍了反向代理和MySQL集群两种场景中冗余部署的架构，分析了设计冗余架构时要考虑的更多因素，还列举了具体业务中一些冗余思想的运用。冗余虽然会造成一定的浪费，但同时又是高可用、提升性能的必要+有效手段。

欢迎私信交流，指出文章的不足之处或提出您的疑虑。