组件热备部署的消息流程图

       现在就业的公司是一家互联网企业，部署在阿里云服务器上，从阿里云服务器通过nginx对接到公司机房的服务器。通过提供给其他企业的服务来收取费用，对接的企业不乏在全球排得上名的，为了保证企业的声誉和服务的稳定性，对服务的可用性和容灾性有极高的要求。其中有一个重要的模块在设计之初并未考虑到这几点。最初设计的架构问题，现在在生产服务器上一直单机部署，这个对生产环境带来不稳定因素。

       由于这个组件在线上已经运行了一段时间，对接了很多企业，针对某些企业做了一些定制化的修改，如果推导之前的架构设计和程序逻辑的话，也会带来很多不确定因素。因此综合以上考虑，在不改变原来的逻辑情况下，团队决定做了热备部署方案，以下是热备部署的两个消息图，一个是启动过程的消息图，另一个是主机挂机备机启动的消息图：

        这个方案有一个风险，当两个服务器之间的网关或者交换机发送故障时，Master、Mirror心跳检测不到对方，程序上判断双方挂机的情况下，都会启动Task任务，这个时候就会违背当初设计这套方案的初衷。

为什么会想到这种设计方案呢？当时参考了RabbitMQ的集群部署，采用Mirror接替Master位置

https://www.cnblogs.com/haolujun/p/9641840.html

中间采用心跳机制来检测Master的存在状态，那么Netty的心跳机制如何实现。

https://blog.csdn.net/a953713428/article/details/69378412