京東售后管理（京東售后管理數據方向）

　　通過閱讀本文，您將了解到一個售后系統應該具備的一些能力、在整個上下游系統中的定位、基本的系統架構，以及針對售后業務場景中常見問題的解決方案。

　　一、核心價值

　　京東到家售后系統作為逆向流，強依賴京東到家業務域，目前涵蓋了：退款、退貨、換貨、維修等四大類場景，并且為用戶與商家提供申訴、仲裁場景支持，為計費與結算系統提供逆向金額數據支持。

　　售后系統業務結構：

　　售后系統上下游依賴：

　　二、系統架構

　　售后系統使用的就是基礎的三層架構。應用層有不同身份的三個端入口，服務層提供了一些業務支持和數據支持，數據層目前使用到了MySQL和Redis以及ElasticSearch。當然還有一些中間件使用，比如rpc框架，zk配置中心，worker分布式定時任務，jmq消息。還有完善的基礎設施，統一監控和日志采集。

　　三、業務形態

　　當正向訂單履約完成后，如訂單中商品有缺件、錯件、質量等問題可以發起售后申請。目前申請售后支持用戶端、商家端、到家客服發起。用戶端申請需要根據不同責任方分配到商家或者客服審核。商家端只能選擇商家責任原因申請售后，然后自動審核通過。客服代用戶申請售后和用戶端一致，流轉到商家或客服審核。

　　用戶端申請售后流程：

　　1. 申請售后

　　1）多端操作并發場景下問題

　　2）售后商品拆分信息如何獲取

　　在正向訂單履約完成后一定的時效內，可以通過用戶端，商家端，運營端基于訂單中商品選擇性申請售后。當接收到一個售后單提交申請，售后這邊會依賴訂單數據，拆分數據來構建售后單詳情數據。那么對于多端申請售后入口，我們怎么能保證訂單中商品不會被重復申請呢？申請時我們使用了redis分布式鎖。

　　售后申請場景下分布式鎖需要注意點：

　　①不同的入口使用相同的key，這里我們通過前綴加訂單號來區分，來保證對同一訂單加鎖。

　　②加入過期時間，比如第一個申請獲取到鎖，如果釋放鎖異常，這里只需要等到超時時間自動過期，防止死鎖。

　　③等待鎖時間，同一個訂單多個入口同時申請售后，如果獲取不到鎖就進入等待，直到獲取到鎖或者等待超時后退出。

　　④使用uuid來保證token唯一性，每次都釋放自己當前請求鎖。

　　我們保證了同一時間只能有一個訂單下的售后能夠申請，接下來就是組裝售后單詳情數據。一個完整的售后單數據來源于訂單詳情和拆分詳情。

　　通過從訂單詳情中取用戶基礎信息，訂單信息，商家門店信息來保存到售后單主表中。根據申請選擇的商品skuid從訂單商品詳情中獲取對應商品基礎信息保存到售后商品表中。接下來就是比較重要的售后商品拆分信息，這個數據來源于拆分系統。先了解下拆分數據結構:

　　可以看到，拆分系統會根據訂單中所有商品把金額拆分到每一件商品上，并且通過num_下標來區分。當選擇訂單中某個商品發起售后我們是怎么去找到這個商品對應的拆分信息呢？

　　我們通過sku_promotionType（商品+促銷類型)來區分不同的商品拆分信息，然后通過記錄num商品下標來確定找到哪一個商品。

　　比如下面的場景：

　　假設訂單中購買了3個正價A商品，1個促銷A商品。

　　①第一次申請一個正價A售后。這時售后系統會記錄一個售后單，對應售后詳情為商品A。從拆分獲取sku_A_正價_num0信息并記錄到售后商品拆分詳情表。

　　②再申請一個正價A和一個促銷A售后。這里售后會發現此訂單已申請過一個正價A，記錄的是sku_A_正價_num0。這時就會去取拆分的 sku_A_正價_num1這條數據。

　　③第二次申請售后對應一個新售后單，商品詳情記錄為sku_A_正價，sku_A_促銷。商品拆分記錄數據為:sku_A_正價_num1，sku_A_促銷_num0。

　　初步了解了售后商品獲取對應拆分數據的邏輯，這時如果同一個訂單中購買了相同促銷的A商品，但是價格不一樣怎么辦呢？按照上面獲取邏輯，獲取的售后商品金額就會出現多退或者少退情況。

　　比如下面的捆綁促銷：

　　A+B捆綁銷售，A金額3元。A+C捆綁銷售，此時A金額2元。這時拆分的數據結構為：sku_A_捆綁_num0價格3元，sku_A_捆綁_num0價格2元。此時如果兩個A都申請了售后，我們再按照sku_promotionType去獲取拆分那么永遠獲取的都是第一個的金額。因此針對這種特殊的促銷場景，我們在原有獲取拆分維度基礎上又增加了一個價格。

　　區分維度：sku_promotionType_price(商品+促銷類型+價格)

　　上面的方案可以滿足各種不同促銷場景的售后，但是針對稱重退差訂單申請售后還會適用么？

　　稱重退差訂單含義：當正向訂單揀貨時，商家發現實際揀貨的稱重品和售賣規格有誤差，此時可以發起退差單把差額的錢退給用戶。之后訂單正常履約，訂單完成后用戶也可以申請售后。此時再申請售后退給用戶的錢就應該是減去退差后的部分。

　　比如下面的場景：

　　假設一個訂單中買了2個原價A+1個促銷價A，原價3元，促銷價2元，整單共8元。揀貨時發現A商品實際重量比標重少，退差1元，此時退差單中會記錄商品A退差金額，退差重量。這時選擇正價A發起售后申請，售后系統就需要根據實際重量獲取退差商品金額，然后計算實際退款金額。這時我們又在原來的基礎上增加了一個重量維度。

　　sku_promotionType_price_weight(商品+促銷類型+價格+重量)

　　系統都是為了業務來服務的，隨著業務變更場景的增多，我們的架構也在演變。目前所有的計算拆分邏輯都封裝成統一方法，統一入口，未來再增加不同促銷，或者其他業務都可以很友好的支持。

　　2. 審核售后

　　1）多條件復雜查詢性能問題

　　當售后單申請成功后，會根據審核方分配給商家或者客服審核。這里涉及到兩個列表查詢，一個是運營端客服使用，一個是商家端根據商家賬號權限來展示可操作的售后單列表。最初我們的售后單表數據并不是很大，隨著業務品類擴增以及用戶量的增加遇到了一些問題。

　　①數據庫頻繁報警，慢SQL，影響其他業務

　　②商家運營反饋售后單列表查詢過慢，影響審核效率。

　　通過分析慢SQL日志，我們根據查詢字段增加索引來提高查詢速率。由于支持各種查詢場景過多，目前主表中已經建立了20多個索引。而且基于業務的發展需要支持查詢的時間區間也會更長。主表的數據量一直在增長，還是會遇到查詢性能問題，過多的索引對于售后單流程中變化更新也有一定的影響。

　　因為ES是基于倒排索引實現的搜索，配合分詞器在文本模糊搜索上表現比較好，使用的業務場景廣泛，因此我們考慮把售后單數據同步到ES中，列表查詢走ES。

　　基于我們目的是為了解決查詢問題，每次操作業務都會根據主鍵再查詢一次mysql庫詳情，數據遷移同步方案如下：

　　①存量數據如何同步？

　　首先增加一個開關來控制操作是走mysql還是es。先關閉開關然后通過批量同步接口，根據主鍵id范圍區間查詢把存量數據分批同步到ES中。打開開關，這時如果有新的售后單數據，通過MQ異步同步到ES中，同時把開關打開前產生的一部分數據同步到ES中。最后再通過count總數校驗下數據是否全部同步。

　　②如何保證數據同步一致性？

　　涉及到同步數據，難免就會有數據不一致問題。從售后單申請到售后單狀態變更，提交事務后每個節點都會發送一個需要同步的MQ消息。接收到消息后通過主鍵id查詢mysql獲取售后單詳情。然后全量字段同步到ES中。這樣不管先消費哪個節點的MQ，同步的數據都是實時查詢的數據庫，以此來保證每次同步的數據都是當時最新數據。

　　③數據延遲怎么處理？

　　MQ消費有延時，就有可能造成ES和mysql中數據狀態不一致問題。我們只是為了解決查詢性能問題，因此所有復雜查詢都是查的ES數據，但當商家或者客服操作售后單時會根據主鍵查詢mysql售后單詳情，然后執行審核操作。針對所有的業務操作后端也增加了前置狀態校驗，來屏蔽這種數據延時帶來的問題。

　　沒有最好的方案，只有最適用自己業務的方案。當然現在也有一些工具類插件可以支持不同的同步方案，比如cancel基于binlog的同步以及CloudCanal。我們的目的是為了解決查詢效率問題，因此選擇了上面的同步方案。

　　3. 售后退貨

　　1）合單召喚物流配送方案

　　退貨退款售后單，商家或平臺審核通過后，需要退回訂單中貨物。這里就需要與達達交互，召喚配送員走逆向取件流程。在創建運單召喚達達配送前售后這邊會有一個合單邏輯。

　　①合單思想

　　訂單完成后申請售后可以分多次申請，每次可以選擇不同數量的商品。如果用戶同一個訂單中商品分多次售后都申請為退貨，那么在售后單審核通過后這些售后的商品都需要配送員送回商家。這里為了提升用戶多次退貨體驗，也同時為了節約配送成本。因此就需要有一個合單邏輯，同一訂單下的售后單退貨只需召喚一次物流配送即可。

　　②合單邏輯

　　合單worker定時掃描待召喚物流的售后單，當到達用戶預計取件開始時間前10分鐘就會觸發需要合單的任務。合單任務會根據訂單號獲取此訂單下所有需合單的售后單，然后獲取預計取件開始時間最近的售后單。依據最近上門取件開始時間來創建物流運單。

　　③創建運單

　　創建運單前需要前置狀態校驗，只處理待退貨售后單。然后組裝訂單下用戶基本信息，需要合單的所有售后單商品信息以及累計重量，創建運單。運單接口根據訂單號做冪等處理，重復調用會返回相同的運單號。

　　④接收結果

　　通過監聽運單狀態消息，來同步更新配送員信息。

　　⑤異常重試

　　針對合單任務失敗數據，記錄失敗標識，等待下次合單worker執行。記錄失敗次數，如果超過失敗最大次數，跳過合單并預警處理。避免一直合單失敗的數據影響正常合單業務數據。

　　4. 售后退款

　　1）退款準確性問題

　　通過上面的流程圖了解了售后單審核退款到退款結束的一個過程。那么我們都做了哪些來保證審核退款的售后單金額是正確的呢？

　　①增加分布式鎖

　　商家角色審核退款可以通過商家中心、商家端APP、系統對接接口。同時客服端也可以通過運營平臺審核退款。

　　因為這里也涉及多端操作，所以這里的鎖主要為了防止重復審核退款。

　　審核退款時已經確定是售后單維度，每個售后單只能審核退款一次，所以這里的key維度是售后單維度。并且獲取不到鎖直接拋出失敗，提示業務異常。

　　②單行商品合法性校驗

　　為什么要做單行商品合法性校驗呢？可以看下下面這個場景:

　　假設當前訂單購買了1個A商品和2個B商品，A商品單價10元，B商品單價15元，整單金額40元。申請售后接口參數為：

　　skuList:[{"skuCount":1,"skuName":"skuA","procotionType":"1"},{"skuCount":1,"skuName":"skuA","promotionType":"1"}]

　　系統對接的商家通過到家開放平臺發布的售后接口創建售后單，由于開放平臺入口面對的是所有商家，每個商家系統對接能力不一樣，可以看出訂單中只買了1個A商品，但是傳了兩遍。正常我們的做法是解析入參list，然后校驗每一行商品的合法性。查詢當前訂單已申請商品個數，以及訂單中總商品個數，然后與當前審核售后單商品個數做比較。但是循環比較等于比較了兩次，每次個數都是1。而且由于2個商品A總額小于訂單總額，所以即使有后面的臺賬總額校驗，還是會造成多退情況。因此這里需要根據當前申請商品總數加已申請此商品總數與訂單中商品總數做校驗。

　　③訂單臺賬金額校驗

　　訂單臺賬金額校驗，是最后一道校驗，校驗的維度不同，是獲取每一項支付明細剩余可退金額。校驗當前要退售后單金額與臺賬余額比較，必須小于等于臺賬余額。

　　④異步退款結果

　　審核退款后，通過異步接收退款mq來更新退款狀態。退款成功通知下游依賴系統。

　　總結

　　逆向售后的業務是依賴于正向訂單的，隨著正向單不同場景玩法的增加，售后需要支持的場景也在增多，我們也在不斷的迭代進步。在這當中也遇到了一些需要解決和完善的問題，比如售后系統沒有自己的網關，這樣會造成業務邏輯維護多處，業務不閉環。整個售后業務中各種不同場景下邏輯配置都不同，我們也在規劃通過模板引擎配置做到智能化。最后也非常歡迎大家留言交流，共同進步。

  今天的分享就到這里了，想了解更多關于十大京東代運營公司、京東代運營等內容，敬請關注火蝠電商官網。