分布式异步任务处理组件（二）
一些关键点的设计脑暴记录----very important！！！
- 首先，任务存储交给kafka，由节点负责写入kafka，acks=1；失败重试；透传kafka的提交可靠性，保证任务提交成功；后续可以考虑自己实现kafka相关机制---做局部优化，因为强依赖kafka
- 如何保证消息唯一被消费一次---集群状态维护全局消息唯一key，在写入kafka之前生成，保证提交的任务具有全局唯一key；每次消息执行成功做集群广播，通知到一半以上的节点再持久化（这里考虑一半以上节点还是所有节点，应该是所有节点才行--研究一下一半以上的架构模型适用于什么场景）；每个节点间隔时间做持久化，因为是集合操作保证不会重复；间隔时间做持久化保证性能；（这里存在疑点，如果多节点同时失败怎么办，参考zookeeper的持久化机制，或者集群同步机制）保证全局key持久化成功，这样不能保证任务消息只被提交一次---数据库操作才可以保证，需要依赖回滚机制；；；有些任务不具有回滚性质--比如发送邮件。如何处理？可以分为两段提交，prepare状态在发邮件之前执行，提供检查策略用于其他节点检查邮件是否真实被执行；数据库操作提供自检查--检查全局ID即可；文件和邮件短信之类的操作需要用户提供检查策略；---理论上严格保证唯一执行需要每次处理任务前执行检查策略--所以这里要可配置，是否需要严格只执行一次，还是至少被执行一次--原理和提交可靠性一样---也不太一样，提交策略是至少被提交一次，其实有可能多次提交；
- 如何维护集群状态全局唯一key，预分配+全局投票；
- 再谈如何保证消息唯一被消费一次--全内存操作，只有消息消费成功才给kafka提交offset，因为是全内存操作保证每次拉取的消息数量不会太多；---怎么保证消息不回积压--积压问题通过集群部署实现，因为全内存操作保证最大运行能力，还产生积压说明系统配置不够；--非必要不考虑将消息再次持久化，如果要持久化只考虑持久化极少数一部分；
- 集群状态通过全局广播或者zookeeper来实现--基本上考虑节点上线和节点下线问题；也要考虑节点网络延迟问题；--一般来说全局广播和zookeeper的原理是一样的；
- 定制化分布式线城池--任务分类；优先级；线程池动态监控和动态调整；---详细考虑设计哪些参数，比如任务执行时间，单任务实际线程运行时间和阻塞时间，IO操作时间--然后对任务打标签---标签是否需要广播，广播后在任务提交时就打标签，以配合自我流量控制；
- 任务处理器handler如何注册--动态加载；JNI；或者RPC--这三种方式应该都要支持；
- 单节点流量控制--根据当前节点实际任务执行情况做流量控制，单节点消费能力做流量调节跟其他节点没有关系--因为是最大能力执行；
- 延时队列怎么实现--双队列--实时队列和延时队列--但是这里也要配合标签和流量控制考虑到实际上的延时队列跟实际上的实时队列的差别---延时队列分为两种--一种是计时结束后需要立即执行，另一种是计时结束后重新入队；
- 因为保证强可靠性，任务是否支持子任务或者叫任务递归，任务嵌套--比如自动扣费成功后产生生成订单任务---在扣费任务里提交生成订单即可，不需要组件做管理；---第10点不用考虑；
- 单节点流量控制需要规避大任务阻当小任务的情况发生---比如一个大任务挡住所有后续所有小任务的执行；所以这里需要保证所有任务不是严格顺序执行的；比如一部分线程宁愿空着也不能消费大任务，这里可以做任务类型队列，CPU密集型任务队列，IO密集型任务队列，总时间小的任务队列，总时间长的任务队列；-----衡量标准要考虑绝对参数，自适应性参数调节可能产生相对参数；