網聯又稱“非銀行支付機構網絡支付清算平臺”，是為國內所有非銀行支付機構搭建的一個共有的交易轉接以及清算的平臺?？赡苡腥藭木W聯模式下會不會對支付性能有影響？特別是即將來臨的2017年“雙111，還能不能開啟瘋狂剁手模式？七夕節早上5點20分女神能否準時收到微信紅包？

　　答案當然是肯定的。面對高并發、低延時的支付場景需求，網聯采用高性能的分布式架構，完全能支撐住大家愉快地買買買和節日表白。

　　先以超市購物的例子來說明網聯清算模式下的整個支付清算業務流程：

　　?小明在超市買了1000塊錢的商品，用微信支付時選擇使用綁定的招商銀行卡付款；

　　?財付通收到小明的請求后，向網聯平臺發起一筆協議支付交易；

　　?網聯平臺將交易信息存在數據庫里，并將請求轉發至招行，招行在小明賬戶扣掉1000塊錢，網聯收到招行扣款成功的通知后，會給財付通反饋支付成功的回執，同時通知工行(財付通備付金行)給財付通工行賬戶增加1000塊錢。

　　?最后，財付通將支付結果通知小明，小明帶走商品。

　　小明需要等待支付結果才能完成交易，因此要求整個支付鏈路具備低延遲的特點，網聯交易轉接的處理時間設計為秒級響應。

　　這種場景，在生活中比比皆是。據數據顯示2016年“雙111，支付寶的支付峰值達到12萬筆／秒，預計2017年“雙11”會達到20萬筆/秒的支付峰值。根據歷史數據推算60%的交易涉及銀行賬戶的網絡支付請求，即會有12萬筆/秒的支付請求需要轉接至網聯平臺；因此，網聯平臺的設計目標是支持12萬筆/秒的平穩實時轉接請求的能力，同時考慮容災要求，平臺滿配峰值支持18萬筆/秒。

　　“三地六中心”支撐

　　為支撐這樣的高并發需求，網聯必須考慮異地容災，多點多活，容忍城市級災難的機房建設。

　　業界傳統的做法是建設“兩地三中心”，而“兩地三中心”架構一般只有一個中心對外提供服務，另外一個中心為數據備份（并不對外提供服務），不能滿足平臺的容災多活要求。網聯采用了“三地六中心”的系統架構，每個機房支持2萬筆/秒，峰值支持3萬筆/秒，三個城市六個機房同構設計，同時對外提供服務且互為備份。任何一個機房或一個城市發生重大故障，其他機房可以繼續提供12萬筆/秒的平穩運行服務。

　　每個機房需要支持3萬筆/秒的交易轉發峰值。傳統的集中式架構最大特點就是將所有的數據都集中存儲于中心節點上，并且整個系統的業務單元都集中部署在這個中心節點上，系統所有功能都依靠大型高端設備來提供處理能力，因此集中式架構在單臺設備發生故障后影響范圍比較大。而分布式架構在分散的結構部署下，單臺設備故障導致的運行風險相對較小。

　　基于分布式架構在互聯網企業中的多年成功運行，網聯決定采用分布式架構來支持單機房3萬筆/秒的處理能力。應用服務通過分布式部署，來減少單臺服務器的壓力，將3萬筆/秒的處理能力分布到上百臺云服務器上處理，每臺云服務器來分流處理交易請求。

　　此外，高并發的轉接請求和海量數據存儲會成為單數據庫服務器的瓶頸，會對系統的穩定性和性能造成極大的問題。為解決該問題，網聯在數據庫上采用了分庫分表的分布式數據架構。數據庫的分庫分表方案可以輕松的將計算、存儲、I/O并行分發到多臺服務器上，充分利用多臺服務器的處理能力，降低了單點服務器的負載并提高了數據庫操作效率，提升了整個系統的性能。在技術選型上，網聯采用成熟的分庫分表基礎組件，每個機房部署N個數據庫實例，因此每臺數據庫服務器只需每秒處理3萬/N筆的并發請求。此外，網聯機房的網絡采用多條高速鏈路互聯，實現超高速帶寬，也給高并發數據量請求提供了保障。

　　網聯通過“三地六中心”部署，以及單機房分布式服務架構和分布式數據庫架構的方式完成了對18萬筆/秒的實時交易轉接。

　　分批次清分對賬

　　在網聯交易轉接模式下，小明支付成功后獲得了自己的商品，但是招行和工行之間還沒有完成最終資金清償，網聯會對所有交易信息進行清分軋差，清分軋差數據為招商銀行-1000，財付通備付金工行賬戶+1000，網聯會生成清算指令并提交中國人民銀行大額支付系統，由大額支付支付系統完成各家銀行機構資金的統一清算。

　　但是，網聯單日交易規模達數十億筆，且數據分布在多地六個處理中心，面對如此海量的數據，如何在確保結果準確的前提下提升清算實效？且更要確保證結果的正確？

　　為了減輕數據集中處理帶來的延遲和網絡帶寬的消耗，網聯對數據分批次進行清分，并按場次將軋差凈額提交人行大額進行清算。即將交易按照時間片進行切分，每一個分片稱作一個交易批次，在批次時間切換后，對批次數據進行清分處理。

　　有別于傳統系統日終集中處理模式，盡量將數據的處理分散開，避免集中處理造成的性能瓶頸和系統壓力，同時針對本IDC的交易數據均在本地完成清分處理，只將清分結果通過跨城網絡進行上報集中處理平臺。集中處理平臺作為大腦，對清分的流程進行編排，在預定的清算時點，系統會對尚未清算且已完成IDC級數據匯總的批次清分數據進行集中軋差，形成用于提交人行大額支付系統進行清算的凈額數據，進而完成資金的最終清償。

　　完成凈額數據的最終清償，參與機構和銀行需要交易的最終憑證，即各自的交易流水文件（包括對賬匯總流水及交易明細）。據估計峰值為每個批次6.48億筆原始數據，按機構和收付款行拆分后數據量變為三倍，要求每個批次結束后2小時內提供對賬文件。

　　同時網聯是“三地六中心”的分布式架構，交易信息分布化，系統設計從以下幾個方面解決了分布式海量數據的及時對賬問題：按時間維度分批對賬，平臺對交易按照一定的時間間隔進行切片，一天會切成多個交易批次，每個批次作為一個獨立的對賬處理過程。

　　與傳統的集中式日切處理模式相比，多批次對賬提高了對賬效率，避免了大批量數據集中處理的壓力。按空間維度多點對賬，交易數據分布在6個機房，對賬平臺直接在每個機房進行本地計算、生成明細文件、計算本地匯總數據。明細文件保存在當前機房，匯總文件上報集中處理平臺。即將整體邏輯按照縱向和橫向進行多維度的拆分，通過最大化的并行處理提升處理效率；多點對賬同時平均分配了數據量，避免了單點大數據量的壓力。最后，在保證數據源完整性、對賬性能高效性的同時，通過出錯自動重試的流程設計，保證對賬文件的數據完整性。

　　在這種網聯清算模式下的支付業務中，小明完成了實時交易，支付機構、付款行和收款行完成了各自的最終清賬和對賬文件回執，在千千萬萬這樣的場景中，網聯通過分布式高性能的架構，支持了高并發下的實時交易轉接處理以及批量交易的清算對賬。

　　作者供職于網聯

責任編輯：韓希宇