由於阿里雲的主從延遲帶來的問題
實很簡單，就是基於主從複製架構，簡單來說，就搞乙個主庫，掛多個從庫，然後我們就單單只是寫主庫，然後主庫會自動把資料給同步到從庫上去。
主庫將變更寫入 binlog 日誌，然後從庫連線到主庫之後，從庫有乙個 io 執行緒，將主庫的 binlog 日誌拷貝到自己本地，寫入乙個 relay 中繼日誌中。接著從庫中有乙個 sql 執行緒會從中繼日誌讀取 binlog，然後執行 binlog 日誌中的內容，也就是在自己本地再次執行一遍 sql，這樣就可以保證自己跟主庫的資料是一樣的。
這裡有乙個非常重要的一點，就是從庫同步主庫資料的過程是序列化的，也就是說主庫上並行的操作，在從庫上會序列執行。所以這就是乙個非常重要的點了，由於從庫從主庫拷貝日誌以及序列執行 sql 的特點，在高併發場景下，從庫的資料一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的資料可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。
而且這裡還有另外乙個問題，就是如果主庫突然宕機，然後恰好資料還沒同步到從庫，那麼有些資料可能在從庫上是沒有的，有些資料可能就丟失了。
所以 mysql 實際上在這一塊有兩個機制，乙個是半同步複製，用來解決主庫資料丟失問題；乙個是並行複製，用來解決主從同步延時問題。
這個所謂半同步複製，也叫semi-sync複製，指的就是主庫寫入 binlog 日誌之後，就會將強制此時立即將資料同步到從庫，從庫將日誌寫入自己本地的 relay log 之後，接著會返回乙個 ack 給主庫，主庫接收到至少乙個從庫的 ack 之後才會認為寫操作完成了。
所謂並行複製，指的是從庫開啟多個執行緒，並行讀取 relay log 中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。
主要問題在下面:
以前線上確實處理過因為主從同步延時問題而導致的線上的 bug，屬於小型的生產事故。
是這個麼場景。有個同學是這樣寫**邏輯的。先插入一條資料，再把它查出來，然後更新這條資料。在生產環境高峰期，寫併發達到了 2000/s，這個時候，主從複製延時大概是在小幾十毫秒。線上會發現，每天總有那麼一些資料，我們期望更新一些重要的資料狀態，但在高峰期時候卻沒更新。使用者跟客服反饋，而客服就會反饋給我們。
我們通過 mysql 命令：
show statusseconds_behind_master，可以看到從庫複製主庫的資料落後了幾 ms。
一般來說，如果主從延遲較為嚴重，有以下解決方案：
1.dml未走索引導致的主從延遲
應用程式頻繁做delete/update操作，但是sql語句不能走索引路徑，導致update/delete的處理時間很長。 主庫上可以多併發dml，但是所有的更新操作在從庫是單執行緒同步的，這樣
一來就容易造成主從延遲。解決的辦法就是找到批量更新的語句，在更新的表上新增合適的索引優化。如何加索引參考：mysql索引優化思路
2.集中dml操作導致的主從延遲
應用程式持續高併發的dml操作，會導致從庫同步的速度跟不上主庫產生主從延遲。正確的應對辦法是：
3.大表ddl導致的主從延遲
表的ddl變更（例如加列，加索引等）禁止直接通過線上賬號進行，需要dba進行評審。評審通過後才能操作。一般大表的ddl變更可以在從庫先執行，所有從庫做完後做資料庫主從切換，然後在老主庫變更
如果確實是存在必須先插入，立馬要求就查詢到，然後立馬就要反過來執行一些操作，對這個查詢設定直連主庫。
不要試圖在資料庫層解決併發的讀操作問題，至少不要在主從架構的資料庫層解決。要在資料庫層之上架構乙個redis這樣的分布式快取來解決，它是專門幹這個的。其效能肯定遠高於從備機讀取資料。分布式快取也存在著一些限制，例如不能完全支援事務處理。這取決於你的應用場景。對於一般的網際網路應用，併發壓力大但不要求支援事務，可以考慮分布式快取。對於銀行這樣嚴格要求強一致性的應用，對於寫入延遲一般沒什麼要求（延遲幾個小時都可以接受，資料不出錯就行），可以適用完全同步的模式。
如果還是經常性的短時間延遲，那就嘗試加大從庫的硬體配置，比如上sata ssd，pcie等
延遲的監控到位，可通過pt-heart-beat來準確監控延遲值，及時發現檢視。
5.5以後版本的，可以考慮採用半同步複製，能解決少量延遲引起的問題，不過對tps效能損耗較大
公升級到mysql 5.7吧，多執行緒複製，幾乎完美解決單執行緒複製引起的從庫延遲。
最重要的是盡量避免讓任何一台mysql伺服器跑滿
Salesforce 記錄資料查重
使用方法 objectapiname 物件api名稱 newlist 要新增的資料 oldlist 要對比的老資料 注意 newlist和oldlist的泛型必須是同一sobjecttype 對比的字段只包含自定義字段 如果有重複則會return newlist中乙個sobject public s...
解決主從資料庫同步延遲問題
場景 需要在主機寫入之後，保證在備機一定能夠讀取到已經寫入的資料，也就是需要主從架構下的強一致性。主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事情 只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。主從資料庫支援這種完全的同步...
減少mysql主從資料同步延遲問題的詳解
基於區域網的master sl e機制在通常情況下已經可以滿足 實時 備份的要求了。如果延遲比較大，就先確認以下幾個因素 1.網路延遲 2.master負載 3.sl e負載 一般的做程式設計客棧法是，使用多台sl e來分攤讀請求，再從這些sl e中取一台專用的伺服器，只作為備份用，不進行其他任何操...