【51CTO.com原創稿件】背景

蘇寧易購合同數據中心系統是蘇寧合同管理系統中的一個子系統，主要為蘇寧價格、結算、商戶平臺、調撥等系統提供銷售、扣點、賬期等數據，用于指導銷售、賬期結算、采購流程管庫等。

隨著公司業務的快速發展，各系統的調用量和并發量明顯增長，現有的合同數據服務接口已不能滿足某些系統的性能要求，急需升級和優化該服務接口，提高系統的可用性和穩定性。

系統面臨兩個緊迫訴求：

1. 接口性能要從原有的并發量1000TPS提升到10000+TPS以上，滿足高性能。

2. 系統可以橫向擴展，隨著業務發展，可以動態的擴容，滿足可擴展。

問題分析

未改造前的蘇寧合同子系統扣點服務查詢邏輯

如圖：

存在的問題：

1. 大量的連接查庫，造成數據庫負載較高

扣點服務查詢業務邏輯比較復雜，通常一條數據調用需要多次對數據庫進行查詢，在調用量大的時候，經常會出現數據庫連接不夠，數據庫負載過高等問題，給數據庫造成很大壓力。

2. 串行化查詢，效率較低

接口調用的時候，通常是一個報文里包含幾十條數據，由于是串行查詢，每條報文都是逐條查詢，導致處理效率較低。

3. 大量的服務調用，造成服務器壓力過大

現有的4臺Wildfly服務器在并發量大的時候，每臺機器的壓力都比較大，需要更多的機器來分擔壓力。

改造方案

1. 增加緩存，預先將熱點數據放入緩存

(1) 系統最大的問題，就是IO比較密集，服務并發調用的時候，需要大量的查詢數據庫。我們想到的方案就是能否把一部分數據提前計算好，放入緩存，當系統調用的時候直接從緩存中取。

(2) 考慮到數據量比較大，生產環境有將近10億的數據，單臺Redis無法容納這么大的數據，需要做分布式存儲。借助蘇寧自研的Zedis分布式緩存來實現對數據的存儲。

實現方案：

(1)后臺通過定時任務預先將做過價格的商品(熱點數據)計算好之后，將結果數據寫到zedis緩存集群中。

(2)有新的熱點數據變動的時候，先將緩存數據清除，再將數據插入庫中，更新該商品緩存狀態(防止緩存數據與數據庫數據不一致)。

(3)后臺定時任務查詢到緩存狀態未處理的數據重新計算結果，將最新的數據寫入緩存中。

處理流程，如圖：

2. 串行改并行，多線程并發處理數據

(1)調用扣點服務的報文通常都是實時的，也存在一些批量調用的數據，一個報文存在多條調用的數據，未改造前，整個調用都是串行的。

如圖：

調用之前花費的時間是各條數據處理時間的總和

(2)多線程改造之后可以并行的處理一個報文的多條數據

如圖：

改造后，在后臺維護一個線程池，并發處理一個報文的多條數據，花費的時間是處理時間最長的一條數據，處理時間上相較于串行處理有了顯著提高。

3. 橫向擴展服務器，分散壓力

蘇寧易購合同管理數據中心子系統是一個分布式系統，天然具備擴展性。隨著調用量，并發量的增加，單臺Wildfly服務器壓力增大，為滿足性能要求，根據壓測結果，對服務器進行了橫向擴展，從以前的4臺擴容到30臺，分散系統壓力。

4. 改造之后的接口調用方案

如圖：

接口壓測

改造之后，對扣點服務接口進行了壓測，壓測借助于公司內部的蛙測平臺。

壓測環境

服務器數量配置

Nginx24C 4G

Wildfly84C 4G

Zedis54C 32G

MySQL58C 16G

測試場景

測試場景1

模擬場景： 無緩存數據庫壓測

并發用戶數： 8000

測試結果界面如下：

測試時間： 2018-10-01 22：40：23 ~2018-10-01 22：45：23

事務執行總量：2355622次;失敗：0次; 成功率：100%

wildfly服務器利用率穩定在5%~10%

事務的平均響應時間：624.75ms

TPS：平均 8264.4

測試場景2

模擬場景： 半緩存半數據庫壓測

并發用戶數： 8000

測試結果的界面如下：

測試時間： 2018-10-07 16：18：30~2018-10-07 16：23：30

事務執行總量：3653576次;失敗：0次; 成功率：100%

Wildfly服務器利用率穩定在5%~10%

事務的平均響應時間：403.72ms

TPS：平均 12818.3

測試場景3

模擬場景： 全緩存壓測

并發用戶數： 8000

測試結果界面如下：

測試時間： 2018-09-13 11：42：13~2018-09-13 11：47：13

事務執行總量：10519551次;失敗：0次; 成功率：100%

Wildfly服務器利用率穩定在5%~10%

事務的平均響應時間：140.43ms

TPS：平均 36907.3

小結

從壓測結果中可以得出，改造之后的服務接口的TPS有了顯著提升，從以前的1000TPS提升到10000+TPS以上，滿足蘇寧外圍系統對合同扣點服務接口的性能要求。

回顧這次性能優化，主要從三方面入手：

1. 利用Redis內存級別的存儲，實現數據的快速讀取。

2. 從程序內部優化，將串行化的處理改成并行化異步處理。

3. 利用分布式可擴展的特點，擴展服務器，分散壓力。

從這次扣點服務升級改造中得出，性能優化不僅僅是單一的利用某個技術就可以提升系統的性能，需要全方位綜合的解決性能問題，總結的思路有三點：

1. 找到系統性能的瓶頸。

2. 針對性能瓶頸有的放矢做技術方案，選取合適的技術方案。

3. 一定要壓測，優化之后是否真正的提升了系統性能，提升了多少。

結束語

2018年是集團高速發展的一年，隨著智慧零售，大開發等戰略的逐漸落地，公司的業務量數據量不斷的增長，同時對系統的性能和穩定性提出來更高的要求。為響應公司提出的“造極”精神，我們也對現有系統進行了迭代升級，不斷優化，不斷升級。

在造極精神的鼓舞下，圍繞快速迭代、質量保證和穩定服務，把極客、極物、極速的造極精神當作我們的工作態度，唯有挑戰不可能，才能超越一切可能，沖破極限，進而登峰造極。

作者：張冀平，蘇寧易購IT總部員工平臺研發中心技術經理，負責公司內部ERP系統的規劃架構開發工作。資深碼農，十年軟件開發經驗，對系統架構，性能優化，分布式系統設計有著豐富的實戰經驗。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】