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