分布式、高並發、高性能場景(搶購、秒殺、搶票、限時競答)數據一致性解決方案


技術指標:

PV(Page View, 頁面瀏覽量)在千萬級別
QPS(Query Per Second, 每秒處理請求數)在百萬級別
數據量在千億級別
接口響應速度不能超過150毫秒
用戶提交請求到頁面呈現不能超過3秒

架構設計:
1. 從LAMP架構轉為面向服務架構(服務可以用多種開發語言實現,不受一種開發語言限制)
2. 對海量數據做Sharding分片,分庫分表
3. 從有狀態服務改為無狀態接口服務(便於分布式部署)
4. 精心設計的數據層(存儲、壓縮、索引)
5. 分布式系統最終瓶頸(CPU、內存、存儲、網絡)
6. 日志服務化,每個服務可以用不同的開發語言,考慮多種開發語言的兼容性,定義標准化的日志是把分布在不同機器上的日志關聯起來的唯一且有效的辦法
7. 對請求入口做負載均衡后再到達應用層

頁面優化:
1. 靜態文件壓縮,優化HTTP請求連接數,以減少寬帶需求,讓頁面更快加載出來
2. 靜態資源做CDN部署
3. 前后端做數據分離,讓搜索服務解耦,在高並發情況下更靈活做負載均衡(前端使用Vue.js、AngularJs等,數據來源可以不限編程語言)
4. 后端數據大部分來自緩存,加載快,給用戶更快的體驗

后端編碼:
1. 高並發多線程寫入同一個文件的時候,會存現“線程安全”的問題,導致結果和預期不一致,常用的方法是給代碼邏輯加上“鎖”。
2. 秒殺和搶購的場景中,還有另外一個問題,就是“超發(超賣)”,如果在這方面控制不慎,會產生發送過多的情況。我們也曾經聽說過,某些電商搞搶購活動,買家成功拍下后,商家卻不承認訂單有效,拒絕發貨。這里的問題,也許並不一定是商家奸詐,而是系統技術層面存在超發風險導致的。

數據層架構優化:
1. 商品詳情、商品庫存等,可以放在緩存(redis集群),避免頻繁去數據庫取數據,提高商品信息的讀能力
2. 數據庫讀寫分離,分庫分表實現負載均衡
3. 如果數據庫有查詢緩存功能,則使用數據庫查詢緩存功能(Query Cache功能,如果使用,記得定時清理碎片:Flush Query Cache)
4. 其他數據庫細節優化(參考其他網絡文章)

系統層優化:
1. 修改linux內核參數,適應高並發場景(具體參考網絡相關文章)

業務優化:
秒殺和搶購收到了“海量”的請求,實際上里面的水分是很大的。有很多是第三方搶購輔助工具發送的請求,這些都是屬於作弊的手段。

作弊方法和防御方法:
1. 作弊行為:同一個帳號,一次性發出多個請求
防御方法:在程序入口處,1個帳號只允許接收一個請求,其他請求過濾。或者,自己實現一個服務,將同一個賬號的請求放入一個隊列中,處理完一個,再處理下一個。

2. 多個賬號,一次性發送多個請求
很多帳號注冊功能,在發展早期是沒有任何限制的,很容易就能注冊很多個帳號。因此,一些特殊的工作室會編寫自動注冊腳本,積累一大批“僵屍帳號”(微博中的僵屍粉),數量龐大,專門做各種“刷”的行為,如搶購、刷票、轉發抽獎等。
防御方法:
1).使用創新的驗證碼,比如回答問題或者執行某些簡單的操作,把真實的用戶和輔助工具區分來開。
2).直接禁止IP,雖然可能導致誤傷,但是在實際場景中可以獲得很好的效果。

3. 多個帳號,多個IP發送不同請求
“灰色工作室”發現單機IP請求頻率被控制后,他們有的新的進攻方案:不斷變換IP。(IP來源有隨機代理IP、被植入木馬的肉雞,數量龐大等)
防御方法:這種場景下的請求,已經很難分辨出真實用戶或輔助工具。通常只能通過設置業務門檻來限制這種請求,或者通過帳號行為的“數據挖掘”來提前清理它們。
僵屍帳號有一些共同的特征,就是帳號很可能屬於同一號碼段,甚至是連號,活躍度不高,等級低,資料不全等。根據這些特點,適當設置參與門檻,例如限制參與的帳號等級等。通過這些方法,也可以過濾掉一部分僵屍帳號。
(黃牛賬號也是有一些共同特征的,例如經常搶票和退票,節假日異常活躍等)

系統瓶頸/災難預案:
1. 最簡單的就是有降級的預案,流量超過系統容量后,先把哪些功能砍掉, 需要有明確的優先級 。
2. 線上全鏈路壓測,就是把現在的流量放大到我們平常流量的五倍甚至十倍(比如下線一半的服務器,縮容而不是擴容),看看系統瓶頸最先發生在哪里。我們之前有一些例子,推測系統數據庫會先出現瓶頸,但是實測發現是前端的程序先遇到瓶頸。
3. 搭建分布式系統,搭建在線Docker集群, 所有業務共享備用的Docker 集群資源,這樣可以極大的避免每個業務都預留資源,但是實際上流量沒有增長造成的浪費。

 

結語:我們的挑戰都一樣,就是數據量,bigger and bigger,用戶體驗是faster and faster,業務是more and more。

 

總結: 

1. 面向服務架構(不限開發語言)
2. 有狀態服務改為無狀態接口服務(便於分布式部署)
3. 海量數據分片,分庫,分表(阿里雲RDS開啟讀寫分離)
4. 前端靜態資源做CDN中轉
5. 最終硬件瓶頸(CPU、內存、存儲、網絡)
6. 日志服務化(把分布在不同機器上的日志關聯起來的唯一且有效的辦法)
7. 對請求入口做負載均衡后再到達應用層

 

個人總結-大數據高並發場景數據庫方便解決方案


場景評估:用戶量估計1億,日數據量幾千萬,總日志數據幾億條
第一期
1,垂直字段拆分,大表拆分小表base+extent
2,使用內存數據庫Redis存放熱門數據以提高性能和減少數據庫負載
3,優化索引設計,查詢分析優化
4,優化數據庫配置文件
5,使用MySQL 8,提高性能
6,讀寫分離,數據庫主從配置,降低數據庫鎖的頻率,提高數據庫總體性能
7,升級硬件,使用固態硬盤和高頻率處理器提升MySQL的IO性能和數據處理能力
第二期
1,水平拆分,單庫水平拆分表,可拆分99個表,每表一千萬,一共支持10億條數據。考慮聯合查詢問題,增加冗余字段,設計關聯關系映射索引表,自增長起始編號累加
2,采用微服務思維,在業務層面上垂直切分,將不相關的業務的數據庫分隔,每個庫只承擔業務的一部分數據,這樣整體的可用性就能提高。比如商品庫,用戶庫,訂單庫,日志庫,統計庫,歸檔庫等。
3,前后台數據庫分離,冷熱分離,每天定時抽取數據同步
4,使用Sphinx搜索引擎

當數據量很龐大的時候,盡量避免COUNT等操作!一定要的話也可以選擇計算粗略值

 

參考文章:

https://www.cnblogs.com/soundcode/p/5590710.html (保證分布式系統數據一致性的6種方案)
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency (分布式系統事務一致性解決方案)
https://zhuanlan.zhihu.com/p/21994882 (分布式系統理論基礎 - 一致性、2PC和3PC)
https://www.zhihu.com/question/50176389/answer/119724104 (網絡游戲如何保證數據一致性?)
https://coolshell.cn/articles/10910.html (分布式系統的事務處理)
https://blog.csdn.net/zhoudaxia/article/details/38067003 (如何解決秒殺的性能問題和超賣的討論)
http://www.cnblogs.com/wangrudong003/p/7111789.html (.NetCore+Jexus代理+Redis模擬秒殺商品活動)
http://www.cnblogs.com/zhenghui317/p/5577345.html (千萬級規模高性能、高並發的網絡架構經驗)
http://mt.sohu.com/it/d20170403/131798804_255931.shtml (去哪兒網機票搜索系統的高並發架構設計是怎樣的?)
http://blog.csdn.net/xiaemperor/article/details/38234979 (NodeJS優缺點及適用場景討論)
http://www.cnblogs.com/dinglang/p/6133501.html (緩存在高並發場景下的常見問題)
http://blog.csdn.net/qq_34341290/article/details/53316173 (高並發搶購思路)
http://blog.csdn.net/jimlong/article/details/47805047 (PHP解決搶購、秒殺、搶樓、抽獎等阻塞式高並發庫存防控超量的思路方法)
http://www.jb51.net/article/100050.htm (php結合redis實現高並發下的搶購、秒殺功能的實例)

 

版權聲明:本文采用署名-非商業性使用-相同方式共享(CC BY-NC-SA 3.0 CN)國際許可協議進行許可,轉載請注明作者及出處。
本文標題:高並發高性能場景(搶購、秒殺、搶票、限時競答)解決方案
本文鏈接:http://www.cnblogs.com/sochishun/p/7003190.html
本文作者:SoChishun (郵箱:14507247#qq.com | 博客:http://www.cnblogs.com/sochishun/)
發表日期:2017年6月13日


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM