傳統上建設一個博客網站需要：一個反向代理Nginx、一個應用服務、一個資料庫MySQL，就能建立起來標準的WEB站，
如果每天3000多的文章量就存在慢的問題，就要考慮架構的適量改進了，
傳統架構的優化
那么是否增加并均衡負載多個應用服務可以提升并發請求回應速度，同時考慮加入Redis，提升讀取性能呢？當然了，這是必經之路！
上圖是我們最常用的一種傳統架構模式，Nginx作為均衡負載，客戶端和Web容器進行無狀態的請求和回應，Nginx與Web容器的負載保持IP模式，主要是滿足web session，這個程序若產生Web 容器壓力，增加服務器即可，但是往往壓力并不在此處，而是來自資料庫， 因此下一步可以考慮讀寫分離的設計，一般常用的方式是一寫兩讀，這樣就可以減輕一臺資料庫的讀寫壓力，
我們可以通過上述資料庫主從分離的方式來做，這時候要注意資料庫查詢和更新的改造，可以通過Service層注解攔截的方式減少代碼改造量，紅色箭頭部分是寫入主庫并進行從庫復制，灰色箭頭部分是一個WEB容器對應一個從庫的方式分解查詢壓力，
當讀的方面依然遇到很大的并發壓力時，可以進一步納入Redis形成查詢快取，進一步提升讀的性能，
如上圖所示，Redis一方面可以作為Web雙容器的Session共享池，這樣就實作了分布式環境下Web容器的Session解耦，那么最大的好處就是Nginx代理不用非得Ip hash了，因為系結ip這種情況容易出現訪問傾斜，Redis另一方面可以配合MyBatis類似的資料訪問框架，成為讀操作的二級快取，這樣就能最大化地提升資料庫讀的性能，
要是這一步也做了，讀的問題基本上就可以水平擴展了，實際上最大的問題還是在資料庫寫的問題，因為要是這一步你們都遇到了，我相信寫入問題肯定也一樣會出現瓶頸的，常說禍不單行，福無雙至么，
對于MySQL的寫入優化其實比讀取優化要難得多，往往涉及到對資料的改造，例如常做的分庫分表，就是典型的動資料，需要將資料表按照資料增長的一個范圍形成一個表，存放在分布式中的一個MySQL資料庫中，集中式的路由表協助分布式庫表的注冊和發現，這樣寫入程序就必須先從路由表中判斷資料庫路由地址，其實如果不到萬不得已的情況，盡量不要用這種模式，因為這個程序把問題最大復雜化了！至少一開始讀寫分離就要重新規劃，跨表聚合都耦合在了上層應用程式實作，
那么寫入優化第一步對MySQL進行磁區是必要的，例如：RANGE磁區、LIST磁區、HASH磁區、復合磁區，需要注意的是根據業務需要來規劃磁區，例如文章寫入具有明顯的日期性，那么基于日期的Range磁區就挺不錯，但是，往往有熱度的文章，互動就很頻繁，那么對于文章和互動就應該打上熱度標簽，將熱度分類標簽作為LIST磁區的切分項，通過復合磁區的方式，將有熱度的互動資料遷移在熱度磁區上，
混合架構的優化方案
好了，做了上面這些，要是單庫壓力還是巨大，那么就不能再單純考慮關系型RDBMS的存盤形式了，需要考慮引入支持K-V的NoSQL支撐寫入，
先給一個黑科技吧，就將MySQL master主庫引擎InnoDB做替換，嘗試使用MyRocks引擎，但是這個需要進行嚴格的業務兼容性測驗，
MyRocks實際上就是RocksDB，RocksDB在對寫入性能上有著甩傳統資料庫幾十條街的性能提升（前提是最好上SSD固態存盤），可以看看我的另一篇回答創作：為什么分布式資料庫這么喜歡用kv store？ ，從底層資料結構的邏輯上分析，就能理解為什么K-V存盤強悍的寫入能力，雖然在范圍查找上不如傳統的RDBMS，但是讀寫分離機制恰恰彌補了這一點，但是這個黑科技，最為不確定的就是讀寫復制的穩定性，這個需要——測驗！測驗！測驗！
好，我們再去推測一下百度、知乎這些大廠在面對每天億級甚至是幾十億級的資料記錄寫入怎么辦？
這個時候MySQL資料庫單庫寫基本沒戲，單機I/O都撐不住，那一定會采取分布式NoSQL+關系型資料庫集群的混合方案，也就是K-V存盤模型的分布式資料庫應對頻繁地插入更新操作，但業務的完整性關系，最終落地在關系型資料庫集群，復雜密集的業務關系，還是需要關系表來維護比較合適，
百度、知乎這些大戶，我推理猜測，他們對于實時性操作較高的業務，例如文章不斷地編輯，應該是在分布式的大資料平臺上進行KV存盤和訪問，完成臨時性處理，而不著急更新密集的業務關系表，等正式提交后，一定有一個延時的排隊程序才會進行RDBMS資料庫維護關系表的事務完整性，
上述只是一個推理猜測圖，并不一定是精確無誤的，僅供參考，
如圖我們可以看到引入了大資料平臺Hadoop，主要是想利用HBase極高性能的K-V讀寫，尤其是對文章內容的草稿編輯，基本上屬于準實時的操作，如果萬人在線在MySQL資料庫上這么干，資料庫的寫入就得崩潰了！那么對于文章可以形成一個檔案的K-V關系在HBase的稀疏表上盡情寫入，實際上更新也只是內容版本的一次迭代，HBase不用考慮復雜的關系問題，只關注文章內容的編輯問題，
當作者認為完成了寫入，就提交文章，進入審核狀態，審核程序可以充分利用訊息系統，形成文字審核的事件化，對過濾敏感詞、涉黃等等都問題進行實時流式處理，由訂閱的管道推動給關系型資料庫集群，形成完整的資料事務關系，那么就把解決高并發的寫入問題轉變成了佇列推送的大吞吐資料計算問題，之后文章查詢就針對關系型資料庫集群，形成一套快取機制、分布式查詢體系，就容易得多了！
最后
就說這么多吧，實際上大廠的分布式資料計算比我推理的肯定是要復雜許多許多，我只是站在技術合理性的角度，給大家一個方向性的思考，建立高并發、海量資料的網站，我們應該遵循的一個程序，說到底就是用最小的成本，逐步深化，防止一開始的過渡技術，總之關系型資料庫分庫分表的模式除非萬不得已，一定要慎用！因為一旦用開了，就很難掉頭了，系統運維會淹沒在資料維護的復雜性問題上，
本文是公眾號“讀位元組<read-byte>”原創文章，轉載請務必顯示文章來源
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/275365.html
標籤：架構設計
上一篇：編程九十天之特別紀念篇