昨天参加完中兴捧月的决赛,感觉特别的糟糕。说实话,感觉中兴这次比赛搞得真的很奇葩!一是比赛搞得让我觉得公司对整个比赛的态度有点随意,有点不正式。二是比赛的赛题要求每天都在变,感觉不天天关注活动交流区,就容易违规一样~真奇葩!。三是比赛的通知。收到了进入决赛的邮件通知,看完后真的没懂要做些什么要准备些什么。直到到了中兴的研究所现场才发现,我擦,居然是视频答辩~邮件里面和电话里面怎么不说清楚呢?再者,我刚好没准备ppt,我以为是现场拿着自己的作品演示,然后答辩,谁知道是远程视频答辩,在摄像头面前叽里咕噜了半天,我也说不清楚我们的作品的原理怎么样,有哪些技术要点。你要是在现场,我立马给你说清楚作品的基本情况和一些基本原理。哎~算是自己没充分准备吧。
话说,一开始没打算参加这个比赛的,一是时间比较紧,二是要准备找工作,后面开赛后看到任务四不错,挺有感觉挺想练练手的,于是就参加了。谁知道复赛的要求一变再变,感觉赛题要求都脱离了现实生活了:控制进程瘫痪的时候,系统要能正常工作,要让用户感知不到系统瘫痪~。还不允许添加其他进程(如监视进程),要在模拟的环境下实现双机热备,我还真的没头绪,或许自己经验欠缺。
为了应付赛题的要求,设计了一个“有点靠拢题目意思的方案”。写一下自己的方案,学习交流、总结提升~
上图就是我们的系统原理图。系统由三类进程构成。测试进程和主控和从控同时保持套接字连接,主控和从控同时和所有的负荷进程保持套接字连接,主控与从控之间保持套接字连接。网络模块和日志模块是通用模块。网络模块负责基于socket 的数据包收发和网络状态检测,给上层提供基于固定格式的消息通信。
基本原理是:控制进程启动时,先启动的处于主模式(主控进程)。后启动的处于从模式(从控进程)。主控与从控之间定时保持心跳包交换,如果一定时间后没收到对方的心跳包,则认为对方瘫痪(重启或者死机),发现对方瘫痪时,检查自己的工作模式,如果工作于从模式则切换到主模式。整个系统,任何时候只有一个工作在主模式下的控制进程。该进程为测试进程服务,而工作于从模式的进程不提供任何服务。两个总控与所有负荷进程都保持套接字连接,测试进程同时与两个控制进程保持套接字连接。测试进程在发送请求时,同时给两个控制进程发送请求,其中肯定有一个处于主模式的进程会提供响应。此外,主控与从控之间实时保持状态同步,即保证有主控瘫痪时从控立刻能够转换为主控进程并为测试进程服务。(负荷进程的热插拔这里就不提了)
以上介绍了防控制进程瘫痪的方案。当然,这个方案有两个明显的缺陷:
1.数据同步问题。即由于网络传输的不可靠性,主控与从控之间的状态非常有可能不一致,而这个不一致会导致用户丢失。
2.从现实角度讲,让用户同时访问两个服务器是不科学不合理的。
3.当主控宕机,从控切换到主控时有可能会丢失用户的请求。
当然,让用户同时访问两个服务器,虽然不科学不合理,但是作为比赛也是为了应付赛题要求:主控瘫痪,快速为用户服务。在本方案中,理想的情况下,主控宕机了,从控会尽快感知对方宕机,然后切换到主模式下,从而为用户服务。这样设计也是让用户感知不到主控与从控的切换。
最后,这样的方案只是比赛用用而已~O(∩_∩)O~