多讀實例數據一致性問題

一、背景

大部分業務都是讀多寫少場景,通過讀寫分離增加讀節點來增加負載

二、數據庫同步方式

在從節點同步主節點時,可以設置同步方式

  1. 異步複製(Asynchronous replication)

MySQL默認的複製即是異步的,主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端,並不關心從庫是否已經接收並處理,這樣就會有一個問題,主如果crash掉了,此時主上已經提交的事務可能並沒有傳到從上,如果此時,強行將從提升爲主,可能導致新主上的數據不完整。

  1. 全同步複製(Fully synchronous replication)

指當主庫執行完一個事務,所有的從庫都執行了該事務才返回給客戶端。因爲需要等待所有從庫執行完該事務才能返回,所以全同步複製的性能必然會收到嚴重的影響。

  1. 半同步複製(Semisynchronous replication)

介於異步複製和全同步複製之間,主庫在執行完客戶端提交的事務後不是立刻返回給客戶端,而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製,半同步複製提高了數據的安全性,同時它也造成了一定程度的延遲,這個延遲最少是一個TCP/IP往返的時間。所以,半同步複製最好在低延時的網絡中使用。

三、問題

因爲性能和網絡不可靠,絕大部分都不使用全同步方案。那麼就存在一個問題,多個讀節點可能存在數據不一致的情況,此時如果讀負載的策略是隨機策略,那麼第一次請求到S1節點,第二次請求到S2節點,客戶端返回的兩次結果是不一樣,可能S1節點版本再S2之前,第二次讀到S2舊版本,就產生事務隔離問題,所以必須保證同一客戶端請求都是一個讀節點。

四、解決

可以根據客戶端的唯一信息取模路由到相同的讀節點。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章