江湖车侠|PowerJob 的自实现高可用方案，妙妙妙( 三 ) 本文适合有Java基础知识的人群作者：He

PS：这个方案的诞生，我大概付出了1斤脑细胞的代价（不得不说这个减肥方法还蛮好的）...脑细胞不能白死，尽管那些奇奇怪怪得方案没有活到正式版本，但没有他们就无法通往真理的大门。为了表达纪念和“哀悼”之情，我将最终的设计命名为——V4：丧钟为谁鸣。
V4：丧钟为谁鸣想明白了不能由 Worker 发起 Server 的重新选举，这个问题就基本上解决了......由于篇幅原因以及网上已经有小伙伴写了这一块源码分析的博客，我这里就不重复“造轮子”了，在这里主要讲一下设计思路。
就像前面说的那样， worker 因为没办法获取 server 的准确状态，所以不能由 worker 来决定连接哪一台 server 。因此， worker 需要做的，只是服务发现。即定时使用 HTTP 请求任意一台 server ，请求获取当前该分组（appName）对应的 server 。
而 server 收到来自 worker 的服务发现请求后，其实就是进行了一场小型的分布式选主：server 依赖的数据库中存在着 server_info 表，其中记录了每一个分组（appName）所对应的 server 信息。如果该 server 发现表中存在记录，那就说明该 worker 集群中已经有别的 worker 事先请求 server 进行选举，那么此时只需要发送 PING 请求检测该 server 是否存活。如果发现该 server 存活，那么直接返回该 server 的信息作为该分组的 server 。否则就完成篡位，将自己的信息写入数据库表中，成为该分组的 server 。
细心的小伙伴可能又要问了？发送 PING 请求检测该 server 是否存活，不还是有和刚才一样的问题吗？请求不同，发送方和接收方都有可能出问题，凭什么认为是原先的 server 挂了呢？
确实，在这个方案下，依旧没办法解决 server 到底挂没挂这个堪比“真假美猴王”的玄学问题。但是，这还重要吗？我们的目标是某个分组下所有的 worker 都连接到同一台 server ，因此，即便产生那种误打误撞篡位的情况，在服务发现机制的加持下，整个集群最终还是会连接到同一台 server ，完美实现我们的需求。
至此，耗时 6 天，从原来的怀疑人生，到完美方案的落地实现，真是曲折～
最后最后，贴上两位小伙伴贡献的源码分析文章，我亲自 check 过，没有质量问题（这话说的我感觉自己好飘哈哈哈），请各位观众老爷放心查看～

PowerJob源码分析-分组隔离设计
PowerJob源码解读1：Server和Worker之间的通信解读

那么以上就是本篇文章全部的内容了～相信通过这篇文章和上篇文章，大家已经对 PowerJob 的调度层和高可用高性能架构有了一定的了解了。接下来就是下期预告环节了～
为了保留神秘感，这次就选择不预告了（才不会告诉你是我还没想好具体写什么）～
所有惊喜，下期再见～