讀寫分離
讀寫分離，字面上了解是講讀和寫分開。擁有多台資料庫，主節點負責寫入和少量讀取，多個從節點負責分擔查詢。
緩存，在絕大多數項目的地位舉足輕重。緩存，它具有在快速響應大量請求，保護下層資料庫不被過量請求壓垮等優點。但是，緩存能完全代替資料庫嗎？當然是不能。
那麼，接下來，看這樣一個例子
大多數的應用最開始都是單體結構，一個程式包，一個資料庫，好一點會有一個緩存層。現在有每秒8000個請求，其中1000個是寫入請求，7000個是讀取請求。4000個讀取請求能在緩存層得到結果并正确響應。那麼，這個時候，将會有3000個讀取請求進入資料庫，1000個寫入請求進入資料庫，共4000個請求，4000個請求進入資料庫後，如果資料庫性能低一點，會直接将資料庫沖垮。那有沒有好的解決方法呢？有，MySql主從複制。主庫負責寫入，從庫負責分擔查詢。
MySql主從複制
這張圖是MySql經典架構圖。在這裡引用，向大家說明基本原理。使用MySql主從複制最少需要兩台資料庫做主從架構，1台主資料庫，用來進行寫入操作。1台從資料庫，用來分擔查操作。
主庫把SQL請求記錄到自己的binlog日志中，從庫去請求主庫的binlog日志，并将binlog日志寫到中繼日志中，然後從庫重做中繼日志的SQL語句，并執行到從庫。
這個同步過程可以同步進行，也可以異步進行。同步是指，主庫确認從庫收到消息才會送出。異步則是寫入和推送消息變更分開。大多數情況下，我們的業務都是需要異步同步。
MySql主從複制延時
由此發現，異步同步資料的方式，同步時間不太好掌握。這樣會帶來一些問題。比如：
- 連續多次對同一資料進行變更。第一次變更後的資料還未同步到從庫，第二次變更緊接着就進行。這樣會導緻，第二次變更的内容有可能是錯誤的。
- 資料變更後，頁面進行清單展示，有可能展示到變更前的資料。
- 内部系統調用，内部實時統計有可能讀取到舊資料。
如何解決這一問題呢？
- 程式上進行規避（例如：使用緩存層對新添加或者新修改的内容進行緩存一定時間）
- 資料庫同步時間以及同步效率進行摸底，并配置相應的參數（MySql同步模式配置、參數調整）
一般情況下，MySql主從同步時間是毫秒内延時，壓力上來後，才會明顯感覺到延時問題存在。
MySql主從複制優缺點
優點：
- 對開發者透明
- 打破系統讀性能瓶頸
- 資料庫進行備份時，可是選擇從庫進行備份，降低對主庫影響
- 使持久層變成高可用、高性能架構
缺點：
- 主從同步延時
- 需要系統對同步延時造成的資料不一緻進行補償
雲頂雲（yundingyun.com）是國内首批專注于雲計算與大資料服務的提供商，緻力于“讓雲計算更簡單”。做為阿裡雲五星授權服務中心，雲頂雲緻力于為企業和政府提供方案咨詢、架構設計、部署實施、系統定制、運維托管、技術教育訓練等全方位“4S”級公有雲、私有雲定制化服務。