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

就像前面说的那样， 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天，从原来的怀疑人生，到完美方案的落地实现，真是曲折～
PowerJob源码分析-分组隔离设计PowerJob源码解读1：Server和Worker之间的通信解读那么以上就是本篇文章全部的内容了～相信通过这篇文章和上篇文章，大家已经对PowerJob的调度层和高可用高性能架构有了一定的了解了。接下来就是下期预告环节了～
为了保留神秘感，这次就选择不预告了（才不会告诉你是我还没想好具体写什么）～
【江湖车侠|的自实现高可用方案，妙妙妙，PowerJob】所有惊喜，下期再见～