例行早会今天早上一直在开会例行早会开完之后又开始开项目会议。内容量很多。有XXL-JOB是一个开源可用的框架。然后讲解了相关的RPA的一些内容。感觉回想好难啊我知道今天学习了很多知识但是我现在回想复习的时候好难想起来只有剩余的当时学习的感受和理解。慢慢想总会想起来了。先堆积名词术语然后还有逻辑和场景实现流程图。例行早会的时候各个小组汇报各自的进度然后后面就是进行项目的开会会议首先lz讲解了巡检数字人相关的RPA的内容着重给我们介绍讲解了基于gitee网站上开源的XXL-JOB这个框架实现RPA来进行讲解。然后这个框架也很灵活能够覆盖我们监控运维的项目的大部分场景。之后就是讲解完之后yls提出了自己的一些疑问然后又给我们新讲解了一种技术和工具消息队列RocketMQ这个消息队列之后就是给我们讲解了数据场景下的基于MQ实现的架构流程图。然后也讲解了各自工具和框架的优点和缺点。对于XXL-JOB来说这个工具是基于定时的标准来进行任务执行的但是是需要一个timer定时器但是对于海量大量数据的消费和处理的时候XXL-JOB就是显得力不从心了负载能力就没有那么大了很容易在某个consumer消费端执行任务时就会停机挂载。对于MQ来说对海量数据的处理是很有优势的因为MQ是进行了流量削峰还对消费端进行了分布式管理这样的话有多个消费端比起单个消费端来说项目不容易崩。要按保存啊不然刚刚写的内容都没有了啊啊啊啊啊啊。好崩溃又要重新开头再写。早上开会的时候也展示了昨天画的架构图和流程图然后今天yls说这个思路就偏离了所以要让我们重新再画。之后又给我们详细的讲解这些内容还是要好好学好好消化啊。今天早上讲解了很多中间件以及中间件的实现和相关实现的功能这个仔细想来很多都是八股文都是很核心的知识点面试的时候都会考到的所以要好好消化好好仔细学认真学。处理海量数据百万级数量数据成千上万条分类topic从DB、Redis当中确定任务的状态和任务id。为什么要用MQ作为消息总线Producer将消息传到MQ呢因为监控运维场景下会产生海量的数据如果直接将消息数据从Producer直接上传到consumer消费端当中的话有可能会造成当一个消息传过去之后出现问题整条业务流水线都会崩溃而无法继续正常进行运维监控的事务。还有就是如果下游消费端处理慢的话就会造成系统业务瘫痪然后导致整个项目被击垮。MQ起到解耦和削峰的作用。同时MQ自带重试、消息不丢失的功能。MQ自动把消息传给多个consumer天然能够实现分布式部署。为什么要使用多个consumer因为单个consumer不稳定不保险如果单个consumer不能运行那么整个项目就没有办法运行。但是如果是多consumer并行运行的话就会接着运行的能够提高项目的可用性。为什么检查状态需要用DB和Redis因为DB是持久状态存储的地方Redis是检查分布式锁的地方。而且检查状态是为了确保消息和任务并没有重复执行和接受。工作内容刚刚看视频的时候短暂的失去了思考的意思思维瘫痪晕厥了。流程图Producer→RocketMQ→多 Consumer→Redis/DB 状态校验→执行业务逻辑→失败就重新投递执行、日志落 ES、指标落 Prometheus没有做数据清洗、脏数据修复。1、为什么要用 RocketMQ 作为消息总线Producer 生产消息投递 MQ智能运维场景会大量产生事件设备上报数据、巡检任务、告警自愈任务。如果 Producer 直接调用执行模块一旦下游处理慢、瞬间大量运维事件过来系统直接被打垮MQ 起到解耦 削峰生产者只管发消息不用关心什么时候处理流量突增消息在队列缓存下游慢慢消费。同时 RocketMQ 自带重试、消息不丢失能力正好适配你 “失败要重新执行” 的诉求。对应业务端采集、调度平台作为 Producer把数据 / 任务封装消息发送给 RocketMQ。2、为什么多实例 Consumer 并行消费运维系统的事件、任务量波动很大高峰期可能上百台设备同时上报、批量巡检任务下发。单个 Consumer 处理能力有限多 Consumer 实例横向扩容分摊消息提升整体吞吐量分布式部署某一个 Consumer 节点挂掉其他节点还可以继续干活提高可用性。RocketMQ 自动把消息分发到多个 Consumer天然支持分布式消费。3、消费后第一步RedisDB 查询任务状态为什么必须做这一步RocketMQ 至少一次投递语义有可能重复投递同一条消息会出现同一个任务被多个 Consumer 同时执行。Redis做快速判断、分布式锁。快速判断任务是否已经在执行拦截重复执行性能高DB持久保存任务完整状态台账待执行、执行中、成功、失败Redis 宕机也不会丢失状态作用防止重复执行运维任务。运维任务比如配置下发、设备操作最怕重复执行重复下发配置会引发线上故障。这里不处理脏数据只做任务合法性校验任务是否过期、是否已经在跑不修改原始报文内容。不做补全、过滤。4、执行业务逻辑之后失败直接【继续投递重新发起执行】为什么这么设计你的需求执行失败就重新跑一遍任务不做脏数据丢弃、不做本地缓存失败任务。运维场景很多失败是临时性故障网络抖动、设备临时离线、接口超时不是数据本身错了过一会重试就可以成功把失败消息重新投递回 RocketMQ 队列利用 MQ 本身的排队机制再次被 Consumer 消费再次执行好处不需要自己手写本地失败队列、持久化失败任务复用现有 MQ 整套能力注意实际业务代码要在 Redis 记录重试次数避免无限循环反复重试。达到最大重试次数后就不再投递标记失败。5、日志全部存入 ES指标全部交给 Prometheus为什么分开两套存储很多新手会把日志和指标放一起二者用途完全不一样。ES存全部执行日志、异常日志、过程输出日志是文本、非结构化 / 半结构化数据任务输出详情、报错堆栈、执行输出、异常详情。需要支持全文检索运维人员排查故障的时候输入任务 ID检索完整执行日志看哪里报错特点数据量大侧重排查问题、溯源。Prometheus存放指标指标是结构化数值消息 TPS、任务成功率、执行耗时、失败数量、MQ 堆积数量。用于大盘展示、告警当失败率突增、执行时间变长直接触发告警它不存大段文本只存时间 数值适合监控预警不适合存详细报错日志。分工原则看报错细节查 ES看系统状态、告警看 Prometheus。6、为什么去掉「数据清洗、脏数据处理、空白补齐」这个是业务选型决策你的系统接收的是运维原始上报事件不允许修改原始上报内容。如果原始报文异常不要补全、不要修改不能篡改设备上报的原始数据异常数据不做修复直接走失败重试流程重新执行一次如果一直失败日志写入 ES交给运维人员人工排查源头设备而不是系统内部偷偷把数据改掉运维监控讲究原始真实性自动补全数据会掩盖现场问题造成误判。7、额外的兜底定时扫描僵死任务分布式环境下会出现异常Consumer 拿到任务之后节点直接宕机。DB 状态一直停留在 “执行中”任务永远不会结束也不会触发失败重试。后台定时任务扫描 DB找出长时间处于执行中的僵死任务释放分布式锁重新投递回 MQ 重新执行。属于分布式系统必不可少的兜底机制。整体设计的权衡总结设计点收益注意风险RocketMQ 消息总线解耦削峰消息可靠要控制重试次数防止无限循环多 Consumer 分布式消费支持扩容处理大流量依靠 RedisDB 防并发重复执行RedisDB 状态校验避免运维任务重复执行Redis 做缓存DB 持久化兜底失败直接重投递重新执行处理网络抖动等瞬时故障必须增加最大重试计数防止死循环ES 存日志Prometheus 存指标检索排查与监控告警各司其职不要用 Prometheus 存大段日志关闭自动数据清洗保留原始数据不掩盖现场问题异常需要人工介入定位源头设备简单一句话概括整套架构的核心思想原始数据原样流转不修改业务报文遇到执行失败优先重试状态靠 RedisDB 管控防止重复执行日志和监控指标分开存储依靠 MQ 实现分布式、削峰、可靠调度。