電商的11.11大促，既是一場全民運動，也是頂級團隊和技術的對決。爲了深入剖析11.11背後的技術力量，InfoQ派出了多位編輯親臨各大電商的11.11指揮部現場，對一線的技術專家做了各個領域的專訪。本篇新聞就是對京東商城技術研發體系交易平臺副總監王曉鐘的採訪報道。
王曉鍾介紹說，11.11大促，基本的原則是保證主要的交易系統沒有任何故障，這是多部門合作的結果。運維部門從網絡層開始就準備了很多預案和容量規劃，負責處理外部的流量，特別是惡意流量的甄別和處理。
交易系統瓶頸
談到交易系統的瓶頸，他認爲，隨着系統數據和狀態的變化，它不是一個固定的點。以線上交易爲例，依賴的邏輯分支特別多，包括用戶信息、商品信息、價格計算、庫存信息、虛擬資產使用情況等等，這些信息都來源於不同的服務，所以整個交易系統的邏輯特別複雜。在前期準備中，京東內部進行了大量的壓力測試，嘗試找出可能的瓶頸點；在實際運行過程中，工程師密切監控，每個熱點都有預案。處理的思路要麼是提前準備很多組機器，分擔流量，要麼是臨時開啓一些細微的降級，增加一些緩存。
監控系統
京東的實時監控系統基本上都是通過日誌分析來完成，包括軟硬件多個維度，硬件包括CPU使用率、網絡連接數等等；軟件包括某個接口的響應時間、異常拋出的次數等等，當然監控系統也要做11.11備戰，比如對於重要系統的數據隔離等等。關於響應時間，目前瓶頸都在公網上，國內的互聯網質量比較差。從服務器這邊講，每一百次調用中，最差的一次也只有15毫秒，但是到了公網上，根據測試，好的也是100多毫秒，差的甚至到1秒左右。監控系統是京東自己開發的，所有的第三方的東西，它都造一個通用的輪子，京東以前還是一輛大卡車，用通用的輪子就可以了。目前這個業務量可以說已經是一輛跑車了，對輪胎的要求特別高，所以輪子都自己定製的，適合自己的業務、系統、軟件、硬件，包括適合自己的人和管理。
雲平臺與容量規劃
京東的底層系統其實分爲兩塊，一塊是內部的虛擬雲，有不少系統是在用虛擬雲系統；還有一部分，比如說交易，像這種交易也有一部分在用虛擬雲，有一部分在用硬件，都是不一樣的，看業務是否適合。因爲雲不適合所有的業務場景。比如說有狀態的應用，對數據一致性要求高的，它就不太適合。有些像購物車的價格計算，完全沒有狀態，就適合。
雲平臺，第一，部署和管理上和以前相比要方便很多；第二，在故障處理上，有很多底層的可以自動切換的功能，合理的調配資源。
容量規劃，主要依靠各個團隊對於自己的未來業務的預測，京東的團隊主要依靠自己的大數據系統。從大數據團隊裏獲取業務增長數據的趨勢。大家對這些趨勢進行分析，可以合理的判斷自己用戶的增長量大致是多少。比如對用戶團隊來說，關注的是用戶的登陸量和註冊量，對交易團隊來說，關心的是訂單的增長量。商品團隊關心的每天商品的更新量，還有商品的增長量，每個團隊不一樣。他們根據自己量的趨勢來做自己的容量規劃。
數據一致性
交易系統數據一致性，交易依賴的用戶、商品、促銷、庫存這些接口，首先沒辦法做異步，只有同步的來做，而且如果做同步的話，分佈式事務是很難繞過去的話題，對電商來說，簡直是一個技術上的惡夢。目前京東的做法很簡單，提交的時候就做強一致性檢查。提交完了，在強一致性檢查的基礎上，再做異步的一致性檢查。某一單如果沒有提交成功，那沒有一致性問題。只要這一單成功了，系統肯定會保證數據一致性。舉個具體例子，交易一旦成功，用戶餘額如果扣了，那肯定就是扣了。不會存在交易成功，但餘額實際上沒扣的情況。還有優惠券也是一樣的，必須是強一致性的。
線上測試
做線上的性能測試怎麼不影響其他用戶？舉個例子，假設線上是兩組系統，如果要做線上的性能壓測，會把用戶導到其中的一組上去。物理上和做壓測的那一組隔絕。因爲對交易來說，現在交易已經做到分佈式交易，各個組之間，包括數據都做了隔絕。如果一組壓力過大出現問題，哪怕整組宕機的情況下，其他幾組機羣還是好的，快速的把入口流量一切換，保證用戶體驗。這一招就可以用在線上性能測試中。每次線上性能壓測的時候，把用戶導到一組隔絕的機器上，用戶在上面跑。然後剩下的那幾組就用各種工具進行壓測，跑出的數據特別真實。
秒殺隔離
秒殺系統是今年從主交易系統中剝離出來，服務器和數據系統都是獨立部署的，秒殺用的庫存和商品信息都是單獨推送到秒殺系統裏，完全隔離。系統本身又做了很多針對秒殺的優化。
原文地址：http://www.infoq.com/cn/news/2014/11/jd-1111-trading-system