mysql讀寫分離在專案實踐中的應用

工程背景介紹：我們開發了一個萬能介面，使用者通過這個介面中傳入資料，我們拿到資料進行復雜的邏輯處理然後再將資料各種匹配展示分發等操作，處理的流程相當龐大，介面中我們只保留了接收資料和返回一個本次請求的id的操作，其餘操作都是非同步到其他程式中處理的。

返回id的操作是需要和資料庫進行兩次連線，一次讀庫得到最新的id 然後把id更新到資料庫。

專案出現問題：我們以為自己的程式就像上圖中的那樣執行，一次請求，讀庫，寫庫，返回id，其餘非同步處理。但是沒有考慮高併發，強壓力寫的效能問題，在高併發下，多個介面執行緒同事訪問資料庫，這樣的情況會出現併發同步的問題，當然這點我們是考慮到了 ，使用執行緒鎖可避免資料的幻讀，重複讀等。可一旦這樣大量的介面執行緒堆積，很快伺服器cpu將扛不住發生宕機！

那如果不試用執行緒同步鎖呢，很明顯不只是資料的錯亂問題將發生，資料庫在極大執行緒的訪問壓力下也將抗不住，cpu使用率達到85%！程式面臨著癱瘓的風險。

解決方式：

1.資料庫叢集？

好處：增加資料庫伺服器，壓力隨之分攤到幾個伺服器中，減小資料庫壓力

壞處：硬體成本大 資料庫主從問題 雜湊一致性問題 單點故障問題

2.介面伺服器叢集

好處：訪問壓力被分攤到幾個伺服器中 執行緒的堆積問題得到有效解決

壞處：硬體成本大 單點故障問題 nignx負載均衡伺服器的搭建 操作複雜

 

以上兩種方案都是增加硬體成本，加大了開發難度，難以真正實施

終極解決方案：讀寫分離的應用！

好處：硬體成本不變 釋放了資料庫壓力 再也不用擔心資料庫和伺服器壓力了

壞處：無

 

實現思路：

1.對讀庫操作解耦合，增加快取服務ecache(也可以是其它如redis),讀不再直接面對資料庫，只有快取中沒有資料時才把資料庫中的資料讀寫到快取之中，這樣資料庫的讀壓力完全被釋放！

2.對寫資料庫進行非同步操作，在更新資料庫操作中增加訊息中介軟體rabbitmq(也可以是其它如activemq，spring對前者支援較好)，我們將更新後的id寫入到rabbitmq中，單執行緒消費mq到資料庫，由於此時跟新後的id已經返回給客戶，寫庫的操作並不需要高時效性。這樣資料庫的寫壓力也完全被釋放！

這個時候我們來看看整個操作，讀寫均不再直接面對資料庫，但是資料庫中的資料依然沒有錯亂，快取的操作速度極快，介面伺服器也不再有很多的執行緒擠壓，我們在硬體成本不變的情況下解決了資料庫和伺服器壓力過大，可以說是一種完美的解決方案

至此，壓力的問題成功解決，當然問題的解決並非是一撮而就的，這裡還有著一些其它的問題，比如分散式事務的解決，這裡不再一一贅述，後面我們找機會仔聊聊這些分散式服務的經典問題！

以上內容希望幫助到大家，很多PHPer在進階的時候總會遇到一些問題和瓶頸，業務程式碼寫多了沒有方向感，更多PHP大廠PDF面試文件，PHP進階架構視訊資料，PHP精彩好文免費獲取可以關注公眾號：PHP開源社群，或者訪問：

2021金三銀四大廠面試真題集錦，必看！

四年精華PHP技術文章整理合集——PHP框架篇

四年精華PHP技術文合集——微服務架構篇

四年精華PHP技術文合集——分散式架構篇

四年精華PHP技術文合集——高併發場景篇

四年精華PHP技術文章整理合集——資料庫篇