基于zookeeper的HA集群设计思路--

1. 各个节点都可以消费任务，但是由主节点来投票；
2. 主节点通过注册zookeeper的临时节点来选举--主节点需要同步从节点的信息
3. 正常工作机制--各个节点（包括主节点本身）在执行任务之前询问主节点，主节点通过布隆过滤器判断该任务是否被执行；
4. 如果该任务被执行过，则从节点将该任务加入存疑队列中--主节点不能保证一定被执行；任务被消费的几种可能--
   1. 新增节点，导致partition重分配--通过举证即可完成校验；
   2. 节点失败，导致partition重分配--举证无法校验；执行该任务的节点下线；需要运行任务检查策略--消息幂等性校验；
5. 存疑队列中的任务间隔时间需要其他节点举证--是否有其他节点准备执行或者正在执行或者执行过但是没有来得及提交；
6. 其他节点举证成功则丢弃该消息；其他节点举证失败则运行检查策略；
7. 节点任务执行成功则向kafka提交消息；
8. kafka提交失败说明此时发生了partition重分配，则节点向主节点提交消息，主节点负责处理该未提交的消息；
9. 主节点投票逻辑--
   1. 主节点自己判断是否通过--可以通过则更新布隆过滤器并通知其他节点，返回所有节点的并集；
   2. 如果投票过程中某个节点下线；主节点主动和该节点断开连接；
10. 节点下线逻辑---
    1. 网络延迟--
    2. 节点宕机--
       1. 节点下线需要主节点处理--主节点断开和该节点的链接
11. 节点上线--
    1. 如果没有主节点，则该节点抢占leader，但是observer节点会被篡位--使用篡位机制还是同步机制--进入选举状态
    2. 如果存在主节点，向主节点发起连接请求，主节点会同步自己的布隆过滤器数据；同步完成即可加入；
12. 选举--
    1. 集群初始化--节点启动状态为observer节点，如果没有主节点，则observer抢占成为leader节点；如果有主节点，则请求主节点加入集群；
    2. 某个节点成为主节点之后需要和其他节点完成数据同步---这样防止主节点在
13. 几种节点下线情况--
    1. 从节点网络延迟，被动断开和主节点的连接--这时重新加入集群需要向主节点同步信息；
    2. 主节点下线--引发选举节点---主节点有可能在消息分发的过程中下线，这样会导致数据不同步的问题，所以主节点在重新接入集群的时候需要同步各个集群的数据；
    3. 主节点下线--等待主节点发送决议消息的从节点将直接将该消息加入存异队列中；
    4. 主节点负责调度--管理各个节点已经消费的消息和已经提交的消息；
14. 消息消费流程-

 消息最多可能存在两个节点中--

1. 新增节点导致已经被其他节点拉取但是没被执行的任务被新节点拉取，此时任务会被前一个节点执行但是被新节点提交；
2. 某个节点宕机、或者与集群断开连接导致被该节点拉取但是没有提交的任务被其他节点拉取，此时该任务会被后拉取的节点执行并提交；
3. 所以存异队列中的消息肯定要被该节点提交；但是是否该由该节点执行却取决于举证结果，如果其他节点举证自己正在执行该任务，则不执行，如果没有节点执行或者没有查询到提交记录则移交到执行队列中；
4. 闭环在于--被拉去过的任务如果被再次消费肯定会加入到存疑队列中，加上举证和检查策略就能保证该任务最终状态的确定；
5. 在情况1中，该任务被执行应该提交给主节点还是直接提交给监听节点---因该监听主节点，保证在执行节点下线的时候该节点能够及时收到下线信息并重新承担该任务的执行角色；
6. 节点下线--宕机下线或者和主节点断开连接，此时应该放弃消费kafka中的消息，保证消息不会被重复消费；