标签：问题排查   strong   就是   缺点   物流   记录   导致   生成   指令   

前言

物流项目已经稳定运行超过一年的时间了，客户也没有再提出一些需要核查的问题。直到最近两天，客户那边开始频繁的让我们核查一些标签没有产生过门事件的问题，这个引起了我们的重视，最终也完美解决，下面简单说说整个问题的核查和解决思路。

问题排查过程

客户在上周的早上突然联系我们说有一个标签正常过门，但是没有任何事件产生，系统中无法查询到任何关于该标签的事件，需要我们这边核查一下。

因为笔者之前了解过，客户曾经使用过非我司制造的标签，并且该批标签存在异常，可能无法正确读取，所以我们这边最开始的假设是该问题标签为异常标签，如果为异常标签，那么在网络层就不会读取到任何明细数据，所以首先核查网络层。

使用linux指令查询对应epc的网络层日志，竟然找到了读取记录，说明标签被正常读取。这个时候就需要核查整个链路，看看问题到底出在哪里，我们继续核查了最后的转发层和storm计算层的相关日志，一步一步缩小问题圈，最终确定标签的明细是在storm层消失的。

这个时候笔者比较困惑，标签没有产生天线算法的过门事件，也没有留痕，那么到底是在哪块通过业务逻辑抛弃掉了呢？部长提出了一个猜想，该标签是否是绑定的标签，消失是否和绑定业务相关？于是我核查了redis中存储的标签绑定数据，发现该标签确实是绑定标签，然后查看下对应的storm层源码中对绑定标签的业务逻辑处理，问题逐渐明晰。

目前实现的业务流程如下：

• 如果标签没有绑定门，那么直接走天线算法的业务逻辑判断，只要走了天线算法，就一定会在系统留痕。
• 如果标签有绑定门，那么该标签就只能通过绑定门入门，如果走了非绑定门，那么该条数据被悄无声息的抛弃，并且不会继续走天线算法的逻辑。

客户在物流门出门时做了绑定业务，但是对应的绑定门出现了问题，无法通过这个门入门，只能通过其他非绑定门入门，导致了问题的产生。

问题解决

笔者认为，这个问题的关键是在软件的业务逻辑设计时，在一些异常的业务逻辑分支中，没有和客户核实清楚应该如何处理。比如这次的问题是，如果绑定门标签通过非绑定门时应该如何处理，开发草率的认为应该直接抛弃掉这条数据，并且没有在系统中留下任何痕迹，导致了后面出了问题，排查问题很困难。

和客户协商后，客户认为应该加入一个开关控制是否启用强绑定判断，如果现场出现了绑定门无法使用的情况，可以通过这个开关使业务能够正常流转下去。但是仔细思考下，其实客户还是没有说明，如果强绑定打开的情况下，标签如果通过非绑定门，那么业务逻辑该如何处理？有两种方式可以处理：

• 让明细数据继续走天线算法逻辑
  • 优点：有很大概率产生正常的入门事件，客户可以正常结算；系统中有记录，可追溯；源码几乎无改动，改动很小。
  • 缺点：标签无法自动解绑，仍处于绑定状态，客户需要后续手动解绑；有小概率不产生事件或者出门事件，影响实际结算
• 不让明细数据走天线算法逻辑，但是在系统中进行留痕
  • 优点：系统中有记录，可以明确知道无事件的原因
  • 缺点：标签虽然入门，但是一定无法产生任何事件，一定会影响客户的业务结算，源码改动较大，需要再进行测试。

这里需要考虑客户使用绑定的原因，客户之所以使用复杂的绑定和解绑操作，就是为了减少只通过天线算法而产生的错误事件，最终影响客户的业务结算，业务结算需要保证百分之百正确。但是如果是因为客户的异常操作导致的，我们也应该尽可能保证让客户能够进行业务结算。

考虑到上面的优点和缺点，我们选择第一种方式，让明细数据继续走天线的算法逻辑，起码有大概率可以正常生成事件，减少客户的损失。

总结

经过这次问题的排查和解决方案，笔者收获了很多，最重要的是开发时要仔细思考异常业务分支，不能武断的替客户做判断，要和客户仔细讨论，明确异常分支的业务处理，并且通过日志还是其他方式要在出现异常时能够可排查可追溯，开发时要更加关注异常分支。

工作日记-物流门的业务流程异常引发的思考

标签：问题排查   strong   就是   缺点   物流   记录   导致   生成   指令   

原文地址：https://www.cnblogs.com/ging/p/13917981.html