快遞系統的高并發優化設計

龔磊 沈源淳

摘 要：隨著電子商務市場的蓬勃發展帶動了傳統快遞業務量的急速上漲，由此劇增的業務數據傳輸、處理、查詢成為了快遞業提升服務品質的新瓶頸。本文為解決大型信息處理系統中高性能、大吞吐量和高并發數據的優化問題，從軟件架構、數據架構、高可用三個方面闡述如何提高系統的整體性能，以保證大用戶量高并發訪問系統時仍然具有良好的用戶體驗，以及高可用和高可靠性。

關鍵詞：高并發；優化設計；大用戶量

引言

我國于2006發布的《物流術語》中給快遞定義是：承運人將文件或貨物從發件人所在地通過承運人自身或代理的網絡送達收件人手中的一種快速的運輸服務方式[1]。快遞是突出物流服務中運輸功能的一個特別版本，是針對物流中零散、快速、精確派送部分的一個具體體現。

快遞行業是一個既傳統又新興的行業，說起傳統其是典型的勞動密集型行業，跟大型工廠倉庫有不少類似，說起新興是因其隨著互聯網購物等新興需求使得市場不斷擴大而蓬勃上升。其市場規模2008年僅0.13萬億，據國家郵政局6月24日發布的《2016年度快遞市場監管報告》顯示，2016年中國快遞業務量達到了312.8億，同比增長51.4%[2]。電子商務市場的高速增長產生了大量的快遞需求，尤其是C2C電商，對第三方快遞的依賴幾乎是 100%。快遞業務量的急劇增長使得業務員要計劃和管理越來越多的數據[3-4]。業務快速增長，如果無法在短時間內處理完成必然引起公司的運營效率降低，導致無法及時完成快遞業務，又必然引起客戶的不滿，繼而影響自身信譽及后續業務[5]。

1業務場景分析

與電商圍繞用戶行為和商戶或商品維護不同，物流快遞系統里圍繞的基本就只有運單。但是物流快遞有其特殊性，以及傳統行業難以避免的歷史遺留問題，所以在一個運單的生命周期內有好幾個變體，簡單說來業務上是1收件（包括電商來的訂單可以看作是預備的運單）、2發件（門店主要靠定期來回于門店與轉運中心之間的班車來將收件以后的快遞件傳遞給上級門店、本區域的中心門店或最終達到本區域轉運中心）、3到件（發件方區域轉運中心發往收件人一方所在區域的轉運中心乃至具體門店）、4派件（具體門店分配具體人員進行快遞件的最終派送）、簽收（收件人簽收快遞件，最終完成整個生命周期）。其中每一處人員接手都有相關操作記錄，每一次涉及車輛的運輸操作都會有每件快遞件的掃描記錄操作乃至將多個小件打包后的包裹記錄的掃描記錄操作。車輛相關操作可能大都集中在前后半夜的幾個小時內，而且是一邊一些地方有發車裝貨掃描、一邊一些地方有到車卸貨掃描，而人員操作主要集中在每天早上上班的1、2小時內的早高峰階段、以及晚上下班發件方門店收到件以后，集中進行快遞件收件確認的操作，這幾個時間點，在數千家網店的物流快遞公司內，都會短時間產生大量的并發壓力，這就是本文所要分析并優化的問題。

2高并發設計

當前大多數業務系統都基于B/S架構或者基于前端APP或本地gui+后端接口的架構，其本質都是以HTTP通信協議為基礎，可以將架構簡化為前端+http接口+后端業務邏輯+后端其它組件。

2.1前端架構

前端的關鍵是清晰的功能和貼心的用戶體驗，其次才是絢麗的界面。業務邏輯設計上前端主要處理view層從后端接口下載的數據，然后承載、小部分情況下緩存在本地，最終顯示。在需要的時候編輯相關數據，然后作為接口參數回發給后端接口以便后端處理復雜的業務邏輯，而前端在這個過程中主要是初期驗證回傳數據（確保調用后端接口前數據盡量是有效的，以免太多無意義的后端處理）和在大并發業務場景下某些場景的操作頻率限制，比如運單錄入時候（收件），調用后端報價與折扣接口，按照某物流公司門店4千左右，單門店同時調取報價接口的設備以5個計算，設極端情況下50%客戶端同時訪問后端為例，該場景點的性能極端情況瞬間就達：4000*5*0.5=1w的訪問次數，假設后端的處理能力是1k每秒，這樣集中的請求需要10秒以上的時間來處理，那么可選的限制操作首先就是不允許重復使用這個功能，每5-10秒才允許使用一次，這樣確保盡量在短時間內不會對后端產生太大的壓力，其次可以在請求后端接口前隨機增加若干秒的延遲，這樣也能大大降低極端情況下的壓力。

2.2后端架構

后端的軟件架構其設計上要遵循的原則頗多。

（1）容器無狀態：最基礎的業務容器的無狀態，常見的實際場景就是作為后端入口的http接口，這里所說的業務容器主要是指asp.net的iis這類，當然能夠獨立不需要外部webserver就能直接提供http服務的比如.net的owin規范的hostself的獨立exe方案來處理高并發短連接的http請求。之所以要保證無狀態是為了業務容器這一層可以配合負載均衡手段達到理論上無限擴展實例，以期橫向擴展性能。

（2）服務拆分：如果說容器無狀態屬于微觀視角，那么大型系統應做的縱向以及橫向拆分就是屬于準宏觀視角，其中包括不同方面，拆分在軟件架構層面主要就是1，按照層次拆分：接口層、業務邏輯層、底層基礎服務層等。2按照系統和模塊拆分：上層系統、下層系統自然不用說，業務上不同系統也一樣應該拆分，在物流系統里比如對接電商的訂單管理系統和下一層的處理訂單轉成運單后的運單管理系統之間的關系就是電信的上下層級、同時又是不同業務系統的拆分，同層按照不同模塊應該再行拆分，比如訂單處理系統里對電商的對接接口，處理訂單的處理容器等。3按照讀寫拆分：在業務系統里最主要的行為就是讀與寫，而讀與寫的側重是不同的，如果能在架構設計上很好的針對性設計，就能起到事半功倍的作用，很多時候這也是對系統吞吐量提高以及長期迭代發展的重中之重，比如訂單業務處理主流程的各個不同業務模塊和電商調取物流系統里的物流軌跡系統，就是典型的寫跟讀的區別。

（3）異步處理：異步處理有不同層級，軟件架構中不同模塊或者業務處理行為之間數據流的異步，常見的異步處理可能利用的具體技術有：消息隊列比如rabbitmq或kafka、中間表、緩存比如：redis的list類型。異步處理的意義：1、很多業務場景并發很大，如果想要全都實時同步處理，幾乎是不可能完成的任務，那么在業務上稍微改變一下，使其可以異步處理或者延后執行，這就解決了問題。電商環境下秒殺類的操作常用這種方式來應對大并發，每個并發第一時間最初的業務處理系統做的事可能僅僅是驗證基本數據可用性，找一個地方存儲，通常這個地方是隊列性質的，然后由隊列的消費者程序（群）來進行消費處理，當然這個過程必然會加大單個請求的處理反應時間，但是一般是可以接受的，在業務上會需要為延長處理時間做一定的處理，比如加等待提示信息、加一定時間內不可重復操作的限制等，而在物流里隊列異步場景很多，比如跨系統、跨模塊間的數據傳輸，通常都并不需要即時，幾分鐘到一小時都在接收范圍內。特別要注意異步處理應有兩份數據可備查以作校驗，用高可用、同步復制的技術就可以做到，各種主流mq基本都支持或者使用主備復制的db方案，重要的異步數據有必要作定時驗證。