"網易寶"是網易公司為方便用戶進行網上交易推出的安全、穩定、快捷的在線支付平臺，為用戶提供了多種方便的在線充值、交易管理、在線支付帳戶管理、代收、提現等服務。網易寶現更名為網易支付。
 

網易寶有限公司是網易旗下的第三方支付公司。依托網易郵箱、游戲、門戶網站等強勢產品優勢，致力于構建具有網易特色的綜合支付平臺，為企業和用戶提供"安全、便捷、人性化"的在線支付解決方案。

業務覆蓋:B2C、B2B、C2B2C; 服務線上線下產品，包括網絡游戲、電子商務、在線教育、生活繳費、保險行業、彩票行業。

網易寶支撐了整個集團業務絕大部分的支付場景，平均每天的支付訂單有100萬單，接近1億的交易額。因此，一個嚴謹實用的系統是必不可少的，下面就從我的理解上說說網易寶的系統是如何實現高可用的。
 

網易寶的所有核心應用和中間件都是集群部署的，通過負載均衡，平均分配流量。

對于業務系統， 在nginx服務器(nginx集群部署，負載均衡使用LVS)上配置了負載均衡策略，路由請求到后端的應用服務器resin。如果web應用集群某臺機器掛了，nginx通過心跳健康檢查，3秒內能檢測到，把這臺機器從可用列表中剔除出去。

中間件dubbo的consumer基于負載均衡算法， 獲取zookeeper上統計的provider的負載情況，決定請求哪臺provider。Kafka也是類似的原理。如果dubbo服務的某臺provider掛了，與provider維持長連接的zookeeper心跳線程會檢測到，把provider從服務的可用provider列表中剔除，并快速通知到所有依賴該服務的consumer(也是維持的TCP長連接)，consumer更新本地緩存的provider列表。

對于有狀態的服務器，都有數據備份機制。

數據庫主庫會異步同步數據到備庫。數據庫主庫掛了，如果切到備庫，可能會丟失部分業務數據(異步復制，網絡穩定情況下10ms以內的延遲，不是同步寫多份的)。Kafka每條消息都會復制到不同的機器(broker)上。Zookeeper上的數據也是多寫的。Kafka的主broker掛了或者zookeeper的主服務器掛了，通過選舉算法選舉出新的leader。Leader用于讀寫，slavers用于備份。Leader掛了，從slavers中選舉出新的leader快速恢復服務。Kafka和zookeeper是做了數據高可靠性保證的，極小概率會出現丟失數據的情況。
 

多機房部署上，網易寶有杭州、北京兩地機房。杭州是主機房，北京是備，不是多活的。 北京的機房服務器數量較少，數據庫服務器性能較差，數據復制也有秒級的延遲。所以不到萬不得已，是不會切到備用機房的。目前網易支付已經在搭建義橋的機房，2017年實現濱江機房和義橋機房的雙活,解決機房的單點問題。

綜上所述，在同一個機房，網易寶無論是無狀態的服務器，還是有狀態的服務器，從存儲層，到中間件層，到應用層，都不存在單點問題。機房的單點問題也會在不久后解決。

更新不頻繁的基礎熱點數據，如配置項、所有商戶信息、網關數據，在應用啟動時，加載到本地緩存。減少對數據庫的頻繁調用。

網易寶的session管理使用中心化的memcached集群，業務流程中的一些狀態數據，也是存放到memcached。系統之間使用文件數據交互的，文件保存到FTP。需要持久化的業務數據保存到中心化的數據庫。 不管是業務數據，還是非業務數據，都不會保存到本地應用服務器，保證應用無狀態化，使得應用集群可以快速的橫向擴展。

為了保證核心支付服務的穩定性，數據庫上做了讀寫分離。核心業務的讀寫走主庫。對于讀實時性要求不高的查詢場景，查詢備庫。如商戶系統訂單的查詢請求。對于耗時長的sql的查詢場景，查詢異構庫，如商戶的對賬單下載。

§

§ 熱點賬戶處理異步化

為了避免熱點賬戶上的行鎖的激烈競爭影響系統吞吐，網易寶對熱點賬戶的余額更新和資金流水生成，做了異步處理。業務完成后如果需要變動熱點賬戶的金額，先生成緩沖流水，然后由調度任務異步去消費緩沖流水去更新余額、生成資金流水。使熱點賬戶的并發鎖競爭變成了串行處理，大大降低了行鎖競爭導致的線程阻塞，提高了系統的吞吐。

提現、退款處理對實時性的要求不高，通過異步化，對于處理失敗的訂單可以用重試機制補償。避免了同步調用失敗給用戶不好的體驗。

關鍵詞： 網易寶