資料內容:
針對上面起源版本問題我們做一些解決辦法。
可靠的DB
我們引入一個DB,把同步進程每次同步的位置寫入到DB里面去,同步進程重啟的時候首先從DB找到自 己的o?set,然后從o?set后面開始數據同步就可以了。
流水記錄
參考mysql的方式,把所有的寫入數據按照時間的先后用流水日志的方式記錄下來不能被修改,在沒有 同步到別的機房前也不能被刪除。 經過上面的修改后我們得到修改版本一。
把修改版本一放到生產環(huán)境跑了幾天后,又會發(fā)現一些問題:
性能低下
同步進程每次同步一條數據都要修改Mysql同步o?set,導致同步進程性能低下
單機磁盤空間不夠
因為物理機器上會混部多個服務,每個服務都在往磁盤寫入數據 跨機房同步本身又比較慢 可能導致單機磁盤空間被打爆,磁盤被打爆后數據再也無法寫入了。
數據回環(huán)
Server A的數據被同步進程A同步到B機房以后, 被寫入到數據流水B,然后同步進程B又把這個流水同 步給了A機房,就這樣形成了一個循環(huán)回路浪費了網絡帶寬和資源。