前言

物流項目已經穩定運行超過一年的時間了，客戶也沒有再提出一些需要核查的問題。直到最近兩天，客戶那邊開始頻繁的讓我們核查一些標簽沒有產生過門事件的問題，這個引起了我們的重視，最終也完美解決，下面簡單說說整個問題的核查和解決思路。

問題排查過程

客戶在上周的早上突然聯系我們說有一個標簽正常過門，但是沒有任何事件產生，系統中無法查詢到任何關于該標簽的事件，需要我們這邊核查一下。

因為筆者之前了解過，客戶曾經使用過非我司制造的標簽，并且該批標簽存在異常，可能無法正確讀取，所以我們這邊最開始的假設是該問題標簽為異常標簽，如果為異常標簽，那么在網絡層就不會讀取到任何明細數據，所以首先核查網絡層。

使用linux指令查詢對應epc的網絡層日志，竟然找到了讀取記錄，說明標簽被正常讀取。這個時候就需要核查整個鏈路，看看問題到底出在哪里，我們繼續核查了最后的轉發層和storm計算層的相關日志，一步一步縮小問題圈，最終確定標簽的明細是在storm層消失的。

這個時候筆者比較困惑，標簽沒有產生天線算法的過門事件，也沒有留痕，那么到底是在哪塊通過業務邏輯拋棄掉了呢？部長提出了一個猜想，該標簽是否是綁定的標簽，消失是否和綁定業務相關？于是我核查了redis中存儲的標簽綁定數據，發現該標簽確實是綁定標簽，然后查看下對應的storm層源碼中對綁定標簽的業務邏輯處理，問題逐漸明晰。

目前實現的業務流程如下：

• 如果標簽沒有綁定門，那么直接走天線算法的業務邏輯判斷，只要走了天線算法，就一定會在系統留痕。
• 如果標簽有綁定門，那么該標簽就只能通過綁定門入門，如果走了非綁定門，那么該條數據被悄無聲息的拋棄，并且不會繼續走天線算法的邏輯。

客戶在物流門出門時做了綁定業務，但是對應的綁定門出現了問題，無法通過這個門入門，只能通過其他非綁定門入門，導致了問題的產生。

問題解決

筆者認為，這個問題的關鍵是在軟件的業務邏輯設計時，在一些異常的業務邏輯分支中，沒有和客戶核實清楚應該如何處理。比如這次的問題是，如果綁定門標簽通過非綁定門時應該如何處理，開發草率的認為應該直接拋棄掉這條數據，并且沒有在系統中留下任何痕跡，導致了后面出了問題，排查問題很困難。

和客戶協商后，客戶認為應該加入一個開關控制是否啟用強綁定判斷，如果現場出現了綁定門無法使用的情況，可以通過這個開關使業務能夠正常流轉下去。但是仔細思考下，其實客戶還是沒有說明，如果強綁定打開的情況下，標簽如果通過非綁定門，那么業務邏輯該如何處理？有兩種方式可以處理：

• 讓明細數據繼續走天線算法邏輯
  • 優點：有很大概率產生正常的入門事件，客戶可以正常結算；系統中有記錄，可追溯；源碼幾乎無改動，改動很小。
  • 缺點：標簽無法自動解綁，仍處于綁定狀態，客戶需要后續手動解綁；有小概率不產生事件或者出門事件，影響實際結算
• 不讓明細數據走天線算法邏輯，但是在系統中進行留痕
  • 優點：系統中有記錄，可以明確知道無事件的原因
  • 缺點：標簽雖然入門，但是一定無法產生任何事件，一定會影響客戶的業務結算，源碼改動較大，需要再進行測試。

這里需要考慮客戶使用綁定的原因，客戶之所以使用復雜的綁定和解綁操作，就是為了減少只通過天線算法而產生的錯誤事件，最終影響客戶的業務結算，業務結算需要保證百分之百正確。但是如果是因為客戶的異常操作導致的，我們也應該盡可能保證讓客戶能夠進行業務結算。

考慮到上面的優點和缺點，我們選擇第一種方式，讓明細數據繼續走天線的算法邏輯，起碼有大概率可以正常生成事件，減少客戶的損失。

總結

經過這次問題的排查和解決方案，筆者收獲了很多，最重要的是開發時要仔細思考異常業務分支，不能武斷的替客戶做判斷，要和客戶仔細討論，明確異常分支的業務處理，并且通過日志還是其他方式要在出現異常時能夠可排查可追溯，開發時要更加關注異常分支。