項目瓶頸一般是數據庫，因為機器瓶頸可以用負載均衡器加很多機器解決，數據庫讀取的瓶頸可以用多個從庫來解決，可是并發寫入如何提高呢？特別是那種需要馬上得到插入結果的，不能用消息隊列解決的如何做呢？
1 回答
皈依舞
TA貢獻1851條經驗 獲得超3個贊
個人一些看法：（什么語言都差不多的，我這邊是Java的）
省略前頭的部分內容，畢竟是比較簡單的演化過程
我們將session做成一個session服務器，browser1通過負載均衡請求服務器，服務器將session信息存儲到session服務器中，當想要獲取時就反向進行。（缺點：目前session Server是單點的，如何解決單點，保證可用性）
我們可以將Session Server也做成集群，其適合用于Session數量與web服務數量大的情況下，更改架構后，也要修改應用存儲session的業務邏輯。
接下來我們再看看數據庫，讀寫都要經過數據庫，當用戶量達到一定量時，數據庫又將成為一個瓶頸，則我們將如何解決？我們可以使用數據庫的讀寫分離，主從庫，并通過統一的數據訪問模型進行訪問，將所有讀操作引入到Slave服務器，將寫操作引入到主庫當中，由于數據庫讀寫分離，所以應用程序也要有相應的變化，使用數據訪問模塊讓應用程序開發人員不用理會讀寫分離的存在，這樣多數據源讀寫代碼對我們的業務就沒有了侵入（代碼層的演變，如何支持多數據源、如何封裝對業務沒有侵入、如何使用現用的ORM框架實現數據讀寫分離、是否更換ORM、其優缺點？）
當我們訪問過大，I/O過大，我們數據的讀寫分離又將遇到這幾個問題，主從庫復制時是否延遲（分機房部署、跨機房傳輸），應用對于數據源的路由問題，接著我們為了提高服務器，增加了CND和反向代理服務器，使用CDN可以解決不同地方訪問速度問題、反向代理可以在機房中緩存用戶的資源。
這時文件服務器又出現了瓶頸，我們將文件服務器改為分布式文件服務器集群，我們要考慮到：如何不影響線上的業務訪問，是否需要業務部門幫忙清理數據，是否需要備份服務器，是否需要重新做域名解析。
這時我們的數據庫又出現了新的瓶頸，我們選擇專庫專用的方式，進行數據庫的垂直拆分，可以解決寫數據、并發、量大的問題，分庫后又將帶來一些新的問題：跨業務的事務（分布式事務）
當某個數據的訪問量、數據量、日志等過大達到瓶頸時，這時我們就要進行數據庫的水平拆分，我們將User拆分成Users1和Users2，水平拆分即將同一個數據表的數據拆分到兩個數據庫當中，這時我們就解決了單數據庫的瓶頸。
水平拆分后，SQL路由出現一些問題，假設我們想知道某個用戶是存在Users1還是Users2中，且由于分庫，主鍵的策略也將有所不同，同時也將面臨一個分頁的問題（后臺管理系統在進行展示時還要考慮分頁的問題），當完成后，我們又發現應用服務器的搜索量上升，這時我們將應用服務器的搜索功能提取出來做成搜索引擎，同時部分場景使用NoSQL提高性能，
當然以上架構還存在部分問題，如負載均衡服務器是單點，因此也可以將負載均衡服務器做成集群，進行主從的熱備，同時做一個自動切換的解決方案。
過程中：安全性、數據分析、監控、反作弊........
繼續發展：SOA架構、服務化、消息隊列、任務調度、多機房........
- 1 回答
- 0 關注
- 1029 瀏覽