場景
mysql主從複製的常見使用場景，當我們的讀寫流量過大的情況下，尤其是讀流量過大的情況下，mysql主從讀寫分離就很有必要了。
我們使用主庫寫入，讀取從庫來分離讀寫流量，而這時候讀流量不斷增加，那我們只需要擴充套件從庫就可以了。
主從複製的原理
資料庫是怎麼完成主從複製的呢，這裡就要說到binlog了，這是儲存資料庫行為的二進位制日誌檔案。從庫會有乙個io執行緒來讀取這個binlog，讀取之後寫入乙個叫做relay log的日誌檔案中，而主庫也會建立乙個log dump的執行緒來傳送binlog給從庫；同時，從庫會建立乙個sql執行緒將relay log中的內容寫入從庫。來實現主庫資料到從庫資料的一致性。
log dump執行緒是非同步操作，也就是當你有資料寫入主庫的時候，不會等到資料同步到從庫之後再返回寫入成功，而是直接返回寫入成功。
從庫獲取資料先寫入relay log是因為直接寫入從庫可能很耗時，導致主從同步的延遲變長。
既然寫入主庫之後就返回成功，然後同步資料，那這時候就有可能傳送主從資料不一致的問題，因為如果主庫的資料還沒有寫入到binlog檔案中的時候主庫宕機了，那麼就會導致binlog檔案缺失，從而從庫資料和主庫資料不一致的問題，但是這種情況很少很少，而基於效能來考慮，這種情況還在我們可接受範圍之內。
主從讀寫分離的優缺點
主從讀寫分離固然可以讓我們更好的應對大量的讀寫請求，但是讀請求量非常大的情況下，並不是盲目的擴充套件從庫就可以了，因為大量的從庫會有大量的io執行緒來讀取binlog，這樣主庫的壓力就會變大。
還有主從資料庫的同步肯定會有一些延遲，考慮以下情況，我之前的乙個專案，用到了分紅功能，後台審核之後會給使用者發放分紅，這是乙個非同步操作，我們會在審核之後把分紅資料的id放到佇列中，然後取出佇列中的分紅id到從庫之中查詢分紅資料，那麼這時候從庫要是沒有同步到資料，就會出現查到的資料狀態不對或者資料不存在的問題。那麼分紅就進行不下去了。
怎麼辦呢，我們後來採用了直接將所有分紅資料放到佇列之中的方法，這樣取出來就不用再次查詢了，但是這樣的弊端就是佇列中的資料量會變大，但是這在我們的可接受範圍之內。
除此之外還有其他的辦法，比如將資料放到快取之中，取出來id到快取中查詢，但是這樣快取也會很大。而且要保證快取資料的一致性，那麼像更新這種操作就會很危險，建議只有建立操作使用快取。
還有一種方法是取出來查詢的時候直接查詢主庫，但是這樣主從讀寫分離就失去了意義。
總結一下三種方法：
這裡我們分析了主從讀寫分離的執行過程和優缺點，今天就到這裡啦
感謝極客時間的唐揚老師開設的《高併發系統設計》專欄，這裡的內容都是學完以後自己的總結，提煉，思考。
Mysql主從複製應對高併發
這裡有我之前寫的一篇文章 分庫分表會用到讀寫分離，因為使用不同的儲存引擎，來分別應對讀場景和寫場景。那用到讀寫分離，就一定要用到主從複製，比方說我們需要向乙個庫裡邊寫資料，另外乙個庫之讀，這就考慮到資料同步的問題。顧名思義，高併發就是每秒很多的事要去處理。其實所謂的高併發的解決方案，也就是分散壓力。...
docker執行mysql主從備份，讀寫分離
1 從docker官方下拉mysql的image 開啟搜尋mysql 在docker中執行 預設tag為latest docker pull mysql mysql server 也可以指定mysql版本 docker pull mysql mysql server 5.7 2 設定目錄 為了使my...
mysql讀寫分離，主從複製，主從延遲
為了提公升資料庫的效能，一般會採用讀寫分離，即寫請求去主庫，讀請求去從庫。支援開啟多個io執行緒，可以提公升效率。開啟mysql的semi sync 半同步複製功能，即資料落庫，寫入binlog，並至少同步給一台從庫的relay日誌，才算寫成功。從庫開啟多個sql執行緒，可以併發讀取relay日誌，...