背景

业务主要是通过A系统向B系统写入Kafka,然后B系统消费Kafka 将结果写到Kafka中,A进行消费最终结果。
在整个流程中,A写入Kafka会写入一张 record1表记录,然后在A消费最终结果的时候也记录一张record2表。主要改动的话 只是B系统内进行写入数据,但是没有想到用的同一个Map导致前后的一个变量值String类型转换成Integer类型。导致下游系统解析错误。由于上线后没有感觉会影响到这块,所以差不多3 4个小时后才发现,所以造成比较大的影响。
在这里插入图片描述

事故

补救措施:由于日志中有最终消费结果,所以从日志中拉取到最终的结果,然后在生产机器上进行重新推送这波数据。

总结

事前:对于需求 可能的难点 有问题的地方需要全方位的考虑清楚。最笨的方法就是一个案例一个案例过一遍整体的流程。
事中:上线后需要及时观察总体的数据,不能只看改动的地方,这样即使出现问题后,也可以在短时间内找到问题,然后解决,将故障时间缩小到最小范围。
事后:出现问题后,需要及时复盘,影响已经造成 可以从中吸取到一定的教训。

Logo

Kafka开源项目指南提供详尽教程,助开发者掌握其架构、配置和使用,实现高效数据流管理和实时处理。它高性能、可扩展,适合日志收集和实时数据处理,通过持久化保障数据安全,是企业大数据生态系统的核心。

更多推荐