網絡安全,互聯網金融,高併發

轉載自：http://m.zhihujingxuan.com/26957.html

推出一款互聯網金融理財產品，如何安全高效的處理用戶高併發的購買請求?

2015-10-06 20:00:09來源:知乎精選

話題：  網絡安全, 互聯網金融, 高併發

 

【梁川的回答(17票)】:

此類問題比較相似電商網站的秒殺/搶購、微信搶紅包。

此類業務通常都涉及分佈式系統。而對於分佈式系統而言，因爲所謂的CAPS理論：服務的可用性、可靠性、數據的一致性三個要素並不能同時知足，所以通常都遵循所謂的BASE理論。

CAP理論：

Consistency：一致性， 數據一致更新，全部數據變更都是同步的

Availability：可用性

Partition tolerance：分區容錯性，系統可靠性

BASE理論：

Basically Available：基本可用

Soft-state：軟狀態/柔性事務

Eventual Consistency：最終一致性

所以依賴於不一樣的場景，你們的處理方式不盡相同。

例如像微信紅包，發放的紅包是能夠沒被搶到的。而秒殺、搶購通常會被搶光。

又好比像小米搶購手機，因爲其限量的手機臺數是小米本身定義的，搶購的手機臺數能夠有必定程度的偏差的（多或少一點）。而對於淘寶秒殺、搶購通常要求保證很少也很多。

在具體使用場景上，互聯網金融的投標過程更相似於電商的秒殺和搶購。

此類應用重點要解決以下一些問題：

一、超賣

例如融資金額爲1000萬，在最後的搶購中，可投金額只剩下1萬元，可能會有多個投資者同一瞬間都投標成功，致使用戶投資的金額超過了融資額。

解決超賣問題的方案是保證用戶投標過程，對投資金額的增減採用事務，且要保證事務操做的原子性。

二、少賣

典型場景題主提到了：用戶投標搶到了，但因支付失敗等緣由沒正常完成搶購到訂單支付。

解決少買問題的方案是對搶購訂單設定時效性，定時對超過期效未支付的訂單釋放掉。

三、刷單做弊

例如黃牛採用批量註冊多個帳戶並用多帳戶併發搶購、用秒殺工具（按鍵精靈/autohotkey、觸摸精靈、phantomjs、selenium等）或自行開發的工具搶購、變換IP地址（例如ADSL、代理服務器） 來搶購。

解決辦法通常採用限制同一帳戶併發請求數、驗證碼、token、IP地址限制、帳戶黑名單等方式。

四、服務器過載保護

解決辦法通常採用服務降級、限流。能夠參考微信紅包的思路： 有損服務，柔性可用，大系統小作。談談微信紅包海量運營--發10億個紅包難在哪裏？

五、外部渠道的瓶頸

相似秒殺、搶購、搶紅包這樣的活動，外部最大的瓶頸在於支付渠道。

支付渠道的瓶頸主要分爲兩大類：

第一類：第三方支付平臺的穩定性、流量瓶頸、系統併發性能等

第二類：某個銀行渠道自己穩定性和流量瓶頸，例如使用工行卡支付的佔比太高，致使工行流量過載。

解決辦法：

對支付渠道的穩定性及流量瓶頸，能夠多接入幾家第三方支付或直連銀行，在多家支付渠道將備份容災、分流。

對銀行渠道的穩定性及瓶頸，第三方支付通常會在同一家銀行的多個接口作渠道路由及分流。

另外在產品層面，除了實時秒殺/搶購外，能夠考慮預定、引導用戶提早進行帳戶充值使用帳戶支付的方式。

六、網絡、服務器及硬件設備容災

例如網絡癱瘓、服務器癱瘓、網卡、存儲出問題之類。

解決辦法通常採用系統升級擴容（水平擴展、垂直擴展）、容災、備份等。

七、性能

在性能上，常規的CDN、頁面靜態化、數據庫讀寫分離、緩存、異步化（消息隊列）、柔性事務等方案均可以用上。

這裏重點說一下超賣問題，超賣問題的本質善於高併發狀況下數據庫事務瓶頸的技術解決辦法。

超賣問題有兩種方案：

a、採用數據庫事務ACID來保證

若是使用的mysql，能夠採用mysql的線程池技術，經過請求排隊及請求合併，提升數據庫事務併發處理能力。

因爲在秒殺這樣高併發的事務處理狀況下，數據庫因爲死鎖檢測等因素性能直線降低。

具體能夠參考淘寶在秒殺業務的解決方案：秒殺場景下MySQL的低效--緣由和改進l

淘寶是採用修改mysql源代碼方式來定製的，開源方案能夠參考MariaDB的thread_pool系列參數，尤爲是thread_pool_oversubscribe參數。

能夠參考：秒殺應用的MySQL數據庫優化

此種方式的思路適合於須要徹底保證ACID的場合，像支付系統核心交易、帳戶、帳務。

b、採用redis+mysql結合的方式

因爲redis自己的高性能，能夠將投資總金額及餘額存放在redis，用redis完成投資用戶的搶購排號，而後經過消息隊列或日誌同步（例如kafka）方式將數據同步到mysql中。

爲保證redis操做原子性，建議採用redis lua腳本在redis服務器端完成總的投資金額/餘額的操做。

此種方式可能存在以下兩個問題：

redis與mysql數據同步延遲問題：能夠在用戶取號後，等待幾秒，保證消息隊列或日誌同步到mysql。

redis癱瘓問題：經過限流等方式避免redis過載，經過redis集羣保證redis高可用性。

網上關於微信紅包、電商網站的秒殺架構討論比較多，如下幾篇文章值得參考。

談談微信紅包海量運營--發10億個紅包難在哪裏？

雙十一數據庫核心技術

京東商城雙十一技術實戰 -PPT-騰訊大講堂

小米網搶購系統的設計經驗

微信紅包

【技術篇】——如何爲紅包提供穩定支付體驗

微信紅包系統設計 & 優化

微信紅包

【技術篇】——如何在服務有損的狀況下保證用戶體驗