一、背景
大部分業務都是讀多寫少場景,通過讀寫分離增加讀節點來增加負載
二、數據庫同步方式
在從節點同步主節點時,可以設置同步方式
- 異步複製(Asynchronous replication)
MySQL默認的複製即是異步的,主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端,並不關心從庫是否已經接收並處理,這樣就會有一個問題,主如果crash掉了,此時主上已經提交的事務可能並沒有傳到從上,如果此時,強行將從提升爲主,可能導致新主上的數據不完整。
- 全同步複製(Fully synchronous replication)
指當主庫執行完一個事務,所有的從庫都執行了該事務才返回給客戶端。因爲需要等待所有從庫執行完該事務才能返回,所以全同步複製的性能必然會收到嚴重的影響。
- 半同步複製(Semisynchronous replication)
介於異步複製和全同步複製之間,主庫在執行完客戶端提交的事務後不是立刻返回給客戶端,而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製,半同步複製提高了數據的安全性,同時它也造成了一定程度的延遲,這個延遲最少是一個TCP/IP往返的時間。所以,半同步複製最好在低延時的網絡中使用。
三、問題
因爲性能和網絡不可靠,絕大部分都不使用全同步方案。那麼就存在一個問題,多個讀節點可能存在數據不一致的情況,此時如果讀負載的策略是隨機策略,那麼第一次請求到S1節點,第二次請求到S2節點,客戶端返回的兩次結果是不一樣,可能S1節點版本再S2之前,第二次讀到S2舊版本,就產生事務隔離問題,所以必須保證同一客戶端請求都是一個讀節點。
四、解決
可以根據客戶端的唯一信息取模路由到相同的讀節點。