部落格站的架構漸進升級最佳化，億級日寫量架構又是什麼樣呢？

部落格現在每天新增3000多的文章量，速度已經很慢，如果後期我要做一個app資料量肯定更大，到時該怎麼保證訪問速度

上面的問題是部落格網站在傳統架構下經常遇到遇到效能瓶頸期！如果每天3000多的文章量就存在慢的問題，就要考慮架構的適量改進了。

傳統架構的最佳化

那麼是否增加並均衡負載多個應用服務可以提升併發請求響應速度。同時考慮加入Redis，提升讀取效能呢？當然了，這是必經之路！

上圖是我們最常用的一種傳統架構模式，Nginx作為均衡負載，客戶端和Web容器進行無狀態的請求和響應，Nginx與Web容器的負載保持IP模式，主要是滿足web session。這個過程若產生Web 容器壓力，增加伺服器即可，但是往往壓力並不在此處，而是來自資料庫。因此下一步可以考慮讀寫分離的設計，一般常用的方式是一寫兩讀。這樣就可以減輕一臺資料庫的讀寫壓力。

我們可以透過上述資料庫主從分離的方式來做，這時候要注意資料庫查詢和更新的改造，可以透過Service層註解攔截的方式減少程式碼改造量。紅色箭頭部分是寫入主庫並進行從庫複製，灰色箭頭部分是一個WEB容器對應一個從庫的方式分解查詢壓力。

但是讀的方面依然遇到很大的併發壓力時，可以進一步納入Redis形成查詢快取，進一步提升讀的效能。

對於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不用考慮複雜的關係問題，只關注文章內容的編輯問題。

當作者認為完成了寫入，就提交文章，進入稽核狀態，稽核過程可以充分利用訊息系統，形成文字稽核的事件化，對過濾敏感詞、涉黃等等都問題進行實時流式處理，由訂閱的管道推動給關係型資料庫叢集，形成完整的資料事務關係，那麼就把解決高併發的寫入問題轉變成了佇列推送的大吞吐資料計算問題。之後文章查詢就針對關係型資料庫叢集，形成一套快取機制、分散式查詢體系，就容易得多了！

最後

就說這麼多吧，實際上大廠的分散式資料計算比我推理的肯定是要複雜許多許多，我只是站在技術合理性的角度，給大家一個方向性的思考，建立高併發、海量資料的網站，我們應該遵循的一個過程，說到底就是用最小的成本，逐步深化，防止一開始的過渡技術。總之關係型資料庫分庫分表的模式除非萬不得已，一定要慎用！因為一旦用開了，就很難掉頭了，系統運維會淹沒在資料維護的複雜性問題上。