支付流程

? ? 對于支付系統來說，它最重要的其實是安全，所以整個支付流程采用秘鑰加簽的方式進行操作，一共四對秘鑰，以支付寶在線支付為例子，首先通過RSA2算法生成商戶公鑰以及商戶私鑰，同時支付寶平臺會提供支付寶公鑰和支付寶私鑰，將支付寶公鑰下載到平臺項目中，同時將商戶公鑰上傳到支付寶后臺，當用戶在前端表單中填寫好充值金額后，生成對應商戶訂單，如果用戶選擇支付，將會把支付價格、訂單號以及訂單描述三個參數排列組合后利用商戶私鑰進行加簽操作，同時將密文url進行重定向到支付寶統一支付接口，支付寶平臺會利用商戶公鑰進行驗簽操作，驗簽通過后將對支付寶錢包余額進行減量操作，同時利用支付寶私鑰對回調參數進行加密，包括商戶訂單號，支付寶訂單號以及支付狀態，支付成功后，支付寶平臺會將帶參進行回跳操作，回調到平臺后，利用支付寶公鑰對參數進行解密，隨后利用回調的商戶訂單號或者支付寶訂單號對平臺的錢包余額以及訂單狀態進行修改操作。

支付一致性問題

? ? 由于我們平臺的充值業務會面臨一些高并發情況，也就是單用戶可能同一時間點同時支付充值操作，如果一秒內同時有三筆50元的支付請求成功，后臺可能會出現支付一致性問題，也就是余額可能只增加50的情況，這里為了保持數據一致性，我們采用了redis的setnx分布式鎖進行操作，當單用戶進行余額修改流程之前，先利用商戶uid作為key獲取分布式鎖，余額修改完成后，釋放分布式鎖，一般情況下，考慮到程序的健壯性，防止服務宕機意外報錯等情況發生，會將釋放鎖放到異常捕獲機制的finally中，因為理論上finally肯定會執行，不會出現死鎖問題，您覺得finally會百分之百執行嗎？其實不一定，因為機房可能會發生物理斷電的問題，即使進入try代碼塊，finally也不一定會執行，這樣就造成了死鎖問題，所以需要給分布式鎖設置一個10秒的生命周期，如果10秒內沒有修改成功，我們會認為該操作發生了異常自動釋放鎖。

分布式鎖問題

? 設置了過期時間，如果業務還沒有執行完成，但是redis鎖過期了，怎么辦?

? 加鎖的時間是30秒.如果加鎖的業務沒有執行完,那么到 30-10 = 20秒的時候,就會進行一次續期,把鎖重置成30秒.那業務的機器萬一宕機了呢?宕機了定時任務跑不了,就續不了期,那自然30秒之后鎖就解開了.

具體使用redisson模塊

友商QPS問題

? ? 在做三方支付平臺對接的時候，實際上支付寶的統一支付接口是有qps限制的，qps限制是100，也就是一秒內只支持100單的支付請求，超出的會直接返回403狀態碼，其實這種設計也是合理的，因為友商沒有必要幫我們承擔高并發請求，所以我在訂單支付和請求支付寶接口之間做了一個緩沖區，生產者不會直接和消費者產生關系，而是通過緩沖區解耦，這個緩沖區就是異步任務隊列，隊列容器我采用redis數據庫，因為redis性能優勢比較明顯，同時內置的list數據類型比較契合隊列這種數據結構，工具類內置了，初始化方法，入隊方法，出隊方法，隊列長度，以及查重唯一方法。

? ? 每當商戶提交支付請求，將訂單id進行入隊操作，遵循fifo原則，在消費者端使用多線程的方式進行消費，也就是出隊操作，這里的線程數我們可以通過變量進行控制，峰值線程數大概維持在80左右，不會突破100，起到一個削峰填谷的作用。

支付回跳問題

? ?這是QA提出一個問題，就是在支付過程中，會有因為網絡因素或者其他原因導致支付寶沒有回跳成功，此時客戶端就會停留在支付頁面動不了，造成問題，其實沒有回跳成功，不外乎兩種結果，就是支付成功，或者支付失敗，解決這個問題可以采用定時任務，每隔十秒檢測訂單狀態為支付中的訂單，通過訂單id做為參數，請求支付寶的訂單查詢接口，用來判斷是否支付成功，隨后定時任務會自動將接口返回的訂單狀態同步到數據庫的訂單狀態中，這里定時任務我采用的是redis中的有序集合，利用zadd方法，將支付中狀態訂單id作為key，delay參數設置為當前時間戳加10秒后時間，入庫。將時間作為score標識物，出隊調用zrangebyscore方法，min_score永遠為0，max_score就是當前時間戳，這樣遍歷會形成一個實踐窗口，只要定時任務進入時間窗口，就會自動執行，非常方便。

延時隊列實現

class DelayRedisQueue:def __init__(self,key):self.key = keyself.r = redis.Redis(decode_responses=True)# 入隊def add(self,uid,delay=0):print("延時隊列入隊，%s秒后執行刪除uid%s的任務" %(delay,uid))self.r.zadd(self.key,{uid:time.time()+delay})# 刪除延時任務def remove(self,uid):return self.r.zrem(self.key,uid)# 出隊邏輯def pop(self):# 起始位置min_score = 0# 區間結束為止max_score = time.time()# 獲取隊列res = self.r.zrangebyscore(self.key,min_score,max_score,start=0,num=1,withscores=False)if res == None:print("暫無延時任務")return Falseif len(res) == 1:print("延時任務到期，返回執行任務的uid%s" % res[0])return res[0]else:print("延時任務沒有到時間")return False

訂單緩存問題 mysql-redis數據一致性問題

????????我的訂單模塊由于讀取的是訂單表，為了分擔數據庫壓力，我們使用redis進行緩存操作，但是如果訂單狀態修改了，redis中的數據需要做同步，這就帶來了mysql-redis的數據同步問題。

????????最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

所以，我們追求的是盡可能保證緩存和數據庫的最終一致性。

??????在開始之前，我們先來科普一下緩存+數據庫讀寫，最經典的Cache Aside Pattern。

? ?????????讀取：先讀取緩存，緩存里沒有，讀取數據庫，然后返回響應，順斌保存緩存

???????????更新：先更新數據庫，然后刪除緩存

為什么是刪除緩存，而不是更新緩存？

????????并發情況下更新緩存可能會帶來種種問題，直接刪除緩存更加穩妥。 緩存更新在很多時候需要耗費資源，直接刪除，用時再從數據庫讀取，寫進緩存，更省性能。

一致性問題

那么我們采用這種先更新數據庫，再刪除緩存，可能會出現什么問題呢？

?假如，我們更新數據庫成功，接下來還沒來刪除緩存，或者刪除緩存失敗怎么辦？

那么很明顯，這時候其它線程進來讀的就是臟數據。

先刪除緩存，再更新數據庫一致性問題

我們看一下，如果先刪除緩存，再更新數據庫可能會帶來什么問題。在并發情況下，先刪除緩存，再更新數據庫，此時數據庫還未更新成功，這時候有其它線程進來了，讀取緩存，緩存不存在，讀取數據庫，讀取的是舊值，這時候，緩存不一致就發生了。

延時雙刪

就是在刪除緩存，更新數據庫之后，休眠一段時間后，再次刪除緩存。利用的也是延時隊列操作

這就是支付系統的介紹。