背景：2013年8月，微信紅包上線。2014年春節微信紅包引爆社交支付。2015年春晚紅包搖一搖，推動微信紅包在全國迅速普及。此後，每逢節假日或特殊日子，人們都會自主的興起發紅包，使微信紅包成為熱點。微信紅包的火熱帶動微信支付的迅猛發展，按當時的發展速度預估，到2015年底，每天的微信支付交易記錄會達到20億。而原有的使用者交易記錄儲存系統無法承受業務迅猛發展帶來的衝擊，一些瓶頸逐漸凸顯出來。本文將就：微信支付背後的交易記錄系統的重構優化歷程進行一次全面的呈現。

歷年春節紅包收發總量

由於老的交易記錄儲存系統是採用key/value的方式儲存使用者資料，每個使用者的所有交易記錄儲存在一個value中，隨著使用者交易資料的不斷增長，單個value資料會不斷變大，最終單個value的20M上限會導致使用者新增資料無法寫入。

老系統將交易記錄的寫入流程放在了支付的關鍵路徑上，然而，從整個支付業務場景來看，交易記錄應該屬於使用者支付後的應用場景（如：檢視交易詳情、確認交易狀態等）。所以將交易記錄寫入流程與支付關鍵路徑解耦合能優化提升支付的效率和體驗。

老系統中交易記錄的種類不全：這裡的主要原因是在業務發展過程中有些場景的交易記錄並沒有納入進來（如：收紅包記錄和派獎收入等）。記錄不全對使用者會造成體驗上的損害。

記錄查詢方式過於簡單：老的系統裡把所有的交易記錄按時間順序排到一起，使用者只能通過不斷下拉的方式來檢視。當用戶想查詢某種型別交易，或某條歷史的交易記錄是，只能通過人肉遍歷，非常不方便。

老交易記錄系統互動介面

針對當時的業務背景和問題，我們需要開發一套能夠支援海量資料儲存、高效能、高可靠、查詢靈活的交易資料儲存系統。

方案：採用關係型資料庫儲存需要分庫分表，擴充套件不方便。採用簡單的分散式kv儲存，能夠解決資料水平擴充套件的問題，但是對單個使用者的資料儲存和管理存在問題（老系統存在的問題，單個value過大）。因此我們採用基於分散式kv儲存平臺tssd，對使用者資料進行分檔管理。（畫圖示意儲存結構）

使用者資料儲存示意圖

每個使用者的資料由若干個value組成。其中一個value為根節點，儲存使用者分檔資料的元資訊。其餘value為資料節點，儲存使用者實際資料。使用者的資料按時間的順序分檔，根節點中儲存每檔資料的時間範圍條數等資訊，當用戶按順序翻頁查詢時，根據請求的資料的起始偏移和條數，能夠快速查詢到所需要的資料。如果要查詢某一條交易記錄，先通過記錄的時間在根節點中查詢到對應的資料節點，再從該節點快速查詢到該條資料。

資料分檔是為了解決資料增長後單個value大小成為瓶頸的問題。那麼儲存使用者資料元資訊的根節點隨著資料的增加是否也會成為瓶頸？這裡的答案是肯定的，按照業務實際的資料大小，一個根節點管理20萬條使用者資料時，其大小就會達到瓶頸，需要對根節點進行分檔。如果我們再用一個元資料節點來管理分檔的根節點，那麼隨著資料的增長，這個節點也需要再分，需要再增加一層節點來管理。這樣資料就像一個不斷增高的樹一樣，對讀寫訪問的效能造成影響。

怎樣來管理一個不斷增長的資料，同時保證資料的訪問維持在一個相對固定的深度？首先我們再來看看使用者資料的特點，按時間資料寫入。訪問主要是近期的資料，越老的資料訪問頻率越低。因此，我們將根節點的分檔資料按照一個鏈的方式串起來，最新的在鏈頭，最老的在鏈尾。當用戶訪問新的資料時，平均只需要2次查詢（根節點+資料節點），訪問較老資料時需要遍歷根節點的鏈，由於這個鏈是有序的，所以可以採用二分查詢，時間複雜度為O（logn）。

資料分檔組織示意圖

分類和統計功能是使用者查詢交易記錄的一個基本需求。分類能夠讓使用者快速定位到想要檢視的交易記錄；統計功能能夠一目瞭然某月的收入和支出情況。但是採用key/value的儲存平臺不能像關係型資料庫那樣方便的按條件查詢。根據業務的訪問場景，所有的分類和統計查詢都是在一定時間範圍內的，而我們的資料是按時間來組織的，因此，對於分類請求，我們可以取指定時間段內的資料進行遍歷。由於使用者平均的資料在800條左右，一般查詢時間範圍在一個月左右，這樣實際遍歷的資料條數在幾十條，因此時間延時可以滿足需求。對於統計請求，是按自然月，這樣我們可以將歷史月的統計計算出快取起來，而對當前月的統計實時計算。

歷史資料問題：歷史資料問題是一個很繁瑣很耗人力的問題。前面提到過，老的交易記錄系統中使用者的資料並不全，為了保證新系統中歷史資料完整，需要從不同的資料來源匯出資料，而且每份資料都不是完整的，只有他們合在一起才是完整的。對於一條交易記錄，其中部分欄位要以微信支付資料來源為準，部分欄位要以財付通資料來源為準，因此對歷史資料的整合、清洗和校驗需要微信支付、財付通等各團隊同事的配合。最終我們用了6個月左右的時間完成了723億條歷史資料整理、校驗和匯入。

資料異常問題：資料的完整性和可靠性是儲存系統要提供的最基本保證，因此係統在對資料的所有寫和修改操作都記錄了詳細的流水。在最初灰度資料階段，我們發現當底層儲存平臺出現大量超時的異常情況下，總會存在少量使用者的資料丟失的現象。通過分析流水日誌，發現超時個別使用者的少量資料發生了回退的現象。進一步分析發現是因為儲存層超時時間遠遠大於我們請求的超時時間，當業務的寫請求超時後，會發起新的寫請求，而這時老的寫請求後到達覆蓋了新請求的資料。針對這種場景，由於底層暫不支援CAS機制，因此我們採用全鏈路的排隊機制，讓單個使用者的請求在每一層都落在指定的伺服器和程序上，排隊執行，避免資料覆蓋。

資料覆蓋示意

節假日效應：微信支付中紅包占了很大的比例。而紅包的節假日效應非常明顯，在春節除夕這樣的節假日，請求量能達到平時的10倍。還有一些提前難以預計到的特殊日子（如：5.20，11.11等），請求量也會突然翻倍。針對這種場景，如果用大量機器資源去扛節假日峰值，一會造成資源的浪費，此外還會加重運維擴容、縮容機器的工作。因此，我們在節假日高峰採用一些柔性策略，削弱峰值請求的影響。當請求峰值大於我們預設的閾值，就把大於這個閾值的請求先快取到接入機的本地磁碟，當峰值過後再將這些請求按一定速度落到底層儲存。在未落底層儲存前，這些記錄無法查詢，因此那些記錄能夠做消峰的柔性處理，需要結合業務場景，在實際應用中，我們只會將紅包的請求做消峰處理，而對其他支付請求不會做這樣的處理。

2017年春節請求量與平時請求量對比

資料安全：使用者的交易資料是非常敏感的資料，一旦資料洩露，會對使用者造成極大的損害，同時對微信支付也會是致命的打擊。因此使用者的資料安全問題是頭等重要的問題。如何保證使用者的資料安全？目前我們從三個方面來做：

1. 訪問控制：所有請求必須帶票據訪問，票據是使用者身份的認證，保證只有該使用者發起的請求才能訪問該使用者的資料。對於非使用者發起的訪問（客服查詢、退款請求等）需要公共票據。此外，系統內部伺服器訪問有白名單控制，非白名單內的伺服器無權進行訪問。

2. 資料脫敏和加密：使用者資料內的敏感欄位要進行脫敏或加密，比如：使用者的微訊號、微信uin、商戶號等資訊，都要進行加密處理。同時，對使用者的身份id進行虛化，即使使用者資料洩露，也無法跟具體的個人對應起來。

3. 人員制度規範：在資料安全方面，出現問題往往是在人這個環節。開發人員和運維人員往往具有較高的資料操作許可權，因此，對開發人員和運維人員的安全意識培養，和完備的管理制度是非常必要的。收斂資料操作許可權，許可權最小化。對於線上所有的運維操作和開發測試工具許可權我們都接入到公司敏感許可權管理系統，使得資料操作許可權集中掌握在少數人手中，如果出現數據洩露問題首先從這些掌握操作許可權的人問責。同時，所有的資料操作都會記錄操作流水，可以用於對資料操作異常的審計，以及出現問題後的追查。

通過對微信交易記錄系統的重構，使用者資料的完整性、準確性得到極大的提高。其中零錢明細之前因為資料不全的投訴已經沒有，整體投訴率下降67%。使用者的活躍度得到極大的提升。當前的日交易記錄數接近幾十億（含紅包收），總資料量已破萬億。在交易記錄的查詢體驗上也更加方便。在資料的儲存和管理方面，我們遵循行業內的安全標準來要求，以保證使用者的個人資訊和資料安全。

新交易記錄系統互動介面

“滴“一下就可以支付的時代已經來臨，“微信支付，一定會是一個全球性的支付”。伴隨“無現金生活”在全球範圍內的普及，我們的舞臺也將越來越大。目前新的交易記錄系統是基於當前支付業務的特點和需求，後續隨著支付業務的發展，支付場景會更加豐富，支付的形式會更加多樣化，對於交易記錄的需求和挑戰也會不斷變化。未來我們對系統的優化方向，是提供更加全面、實時、準確、安全的使用者交易記錄儲存和查詢平臺。而我們追求的是“儘可能把交易系統做好，給使用者帶來最好的體驗”！

出處：https://mp.weixin.qq.com/s/MHQONoedfL2lIGjMfnQL3w

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

-END-