工作经历
在存储大量数据和获取列表的业务场景中，我们采用Mongodb存储模式，其中标记有时间业务的字段用String数据类型定义。
简单描述一下业务场景，系统A通过Http接口向系统B提交业务数据，请求参数有唯一的序列号标识；系统B将业务数据存储在Mongodb中，异步处理和组装数据，提交给系统C(银行系统)。系统C处理完数据后，会以异步回调的形式通知系统B；系统B通过对应关系找到系统A的唯一序列号，然后异步回调给系统A。
业务流程图示意图
发现问题
业务反馈，开发童鞋介入，发现系统A编辑了相同的交易(业务单)，然后重新请求系统B，直到回调其实是上一版本业务单的回调；另外，系统A在接收回调的接口上做了幂等运算，忽略了这个请求；因此，业务编辑器提交后，业务订单长时间处于处理状态。
影响范围
发现部分业务订单有问题，大部分业务订单正常。消除了在项目中设置统一时区的问题。
离线***
再现时间是早上，检测显示没有再现。非常诡异！！！
疑难解答问题
通过序列号的观察日志，发现是B系统存储在Mongodb中的时间字段，数据存在问题，如:创建时间为2022-05-01 14:24:10，然后系统存储为2022-05-01 02:24:10。因此，当系统B通过反转创建时间获得业务订单的最新记录时，它获得业务订单的第一个请求流。
服务器，mongodb节点
如果服务器时间有问题，联系运维童鞋，查看项目服务器各节点当前时间和mongodb各节点时间。结果正常，问题回到项目代码。
故障排除代码
代码历史悠久，最后一次迭代是通过记录创建时间逆序查询。最后，找到问题。
演示再现
@Testpublic void testTime() {Date now = new Date();SimpleDateFor***t sdf = new SimpleDateFor***t("yyyy-MM-dd hh:mm:ss");log.info("12小时制，时间:{}", sdf.for***t(now));sdf = new SimpleDateFor***t("yyyy-MM-dd HH:mm:ss");log.info("24小时制，时间:{}", sdf.for***t(now));}[2022-05-01 14:35:34.106] [***in] [INFO ] [com.xiu.boot.date.DateTest :26 ] 12小时制，时间:2022-05-01 02:35:34[2022-05-01 14:35:34.107] [***in] [INFO ] [com.xiu.boot.date.DateTest :28 ] 24小时制，时间:2022-05-01 14:35:34
紧急在线
修复bug，测试，重现(修改系统时间等操作)。最后，运营维护童鞋顺利发布系统，在线迭代修复。
事后恢复
1.在业务场景发生的概率下
多次编辑业务单，客户不取消业务单后，发现问题，在线迭代一段时间。
2.历史代码，新的需求场景
代码属于历史代码，新需求只是增加了一个排序，导致相应发展的童鞋坚持认为不是代码问题，影响了问题的导向。
3.问题导向不对。
首先位置是项目的时区设置，然后位置服务器时间不同步，最后是位置代码。
4.系统a的幂等处理结果优化。
幂等处理的异常结果不能忽略，直接报警处理。
本文来自倾心之夏投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/565084.html
微信扫一扫 
