博客站的架構漸進升級優化，億級日寫量架構又是什麼樣呢？

傳統上建設一個博客網站須要：一個反向代理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>」原創文章，轉載請務必顯示文章來源