APP
一、什么是主從復制
主從復制，是用來建立一個和主數(shù)據(jù)庫完全一樣的數(shù)據(jù)庫環(huán)境，稱為從數(shù)據(jù)庫，主數(shù)據(jù)庫一般是準實時的業(yè)務數(shù)據(jù)庫。
像在mysql數(shù)據(jù)庫中，支持單項、異步賦值。在賦值過程中，一個服務器充當主服務器，而另外一臺服務器充當從服務器。此時主服務器會將更新信息寫入到一個特定的二進制文件中。并會維護文件的一個索引用來跟蹤日志循環(huán)。這個日志可以記錄并發(fā)送到從服務器的更新中去。
當一臺從服務器連接到主服務器時，從服務器會通知主服務器從服務器的日志文件中讀取最后一次成功更新的位置。然后從服務器會接收從哪個時刻起發(fā)生的任何更新，然后鎖住并等到主服務器通知新的更新。
二、主從復制的作用（好處，或者說為什么要做主從）—— 重點
1、做數(shù)據(jù)的熱備，作為后備數(shù)據(jù)庫，主數(shù)據(jù)庫服務器故障后，可切換到從數(shù)據(jù)庫繼續(xù)工作，避免數(shù)據(jù)丟失。
2、架構的擴展。業(yè)務量越來越大，I/O訪問頻率過高，單機無法滿足，此時做多庫的存儲，降低磁盤I/O訪問的評率，提高單個機器的I/O性能。
3、讀寫分離，使數(shù)據(jù)庫能支持更大的并發(fā)。在報表中尤其重要，由于部分報表sql語句非常的慢，導致鎖表，影響前臺服務。如果前臺使用master，報表使用slave，那么報表sql將不會造成前臺鎖，保證了前臺速度。
（1）在從服務器可以執(zhí)行查詢工作(即我們常說的讀功能)，降低主服務器壓力;（主庫寫，從庫讀，降壓）
（2）在從主服務器進行備份，避免備份期間影響主服務器服務;（確保數(shù)據(jù)安全）
（3）當主服務器出現(xiàn)問題時，可以切換到從服務器。（提升性能）
三、主從復制的原理
1、數(shù)據(jù)庫有個 bin-log 二進制文件，記錄了所有sql語句。
2、我們的目標就是把主數(shù)據(jù)庫的bin-log文件的sql語句復制過來。
3、讓其在從數(shù)據(jù)的relay-log重做日志文件中再執(zhí)行一次這些sql語句即可。
4、下面的主從配置就是圍繞這個原理配置
5、具體需要三個線程來操作：
（1）binlog輸出線程：每當有從庫連接到主庫的時候，主庫都會創(chuàng)建一個線程，然后發(fā)送binlog內容到從庫。在從庫里，當復制開始的時候，從庫就會創(chuàng)建兩個線程進行處理。
（2）從庫I/O線程：當START SLAVE語句在從庫開始執(zhí)行之后，從庫創(chuàng)建一個I/O線程，該線程連接到主庫并請求主庫發(fā)送binlog里面的更新記錄到從庫上。從庫I/O線程讀取主庫的binlog輸出線程發(fā)送的更新并拷貝這些更新到本地文件，其中包括relay log文件。
（3）從庫的SQL線程：從庫創(chuàng)建一個SQL線程，這個線程讀取從庫I/O線程寫到relay log的更新事件并執(zhí)行。
可以知道，對于每一個主從復制的連接，都有三個線程。擁有多個從庫的主庫為每一個連接到主庫的從庫創(chuàng)建一個binlog輸出線程，每一個從庫都有它自己的I/O線程和SQL線程。主從復制如圖? 幫助理解：
四、數(shù)據(jù)庫讀寫分離
RD：數(shù)據(jù)量太大，數(shù)據(jù)庫扛不住了，幫忙申請一個從庫，讀寫分離。DBA：數(shù)據(jù)量多少？RD：5000w左右。DBA：讀寫吞吐量呢？RD：讀QPS約200，寫QPS約30左右。額，數(shù)據(jù)庫讀寫分離雖然不難，但并不是所有的“數(shù)據(jù)庫扛不住”的場景，都應該用讀寫分離。
1、什么是數(shù)據(jù)庫讀寫分離？
一主多從，讀寫分離，主動同步，是一種常見的數(shù)據(jù)庫架構，一般來說：
-
主庫，提供數(shù)據(jù)庫寫服務
-
從庫，提供數(shù)據(jù)庫讀服務
-
主從之間，通過某種機制同步數(shù)據(jù)，例如mysql的binlog
一個組從同步集群通常稱為一個“分組”。
2、分組架構究竟解決什么問題？
大部分互聯(lián)網(wǎng)業(yè)務讀多寫少，數(shù)據(jù)庫的讀往往最先成為性能瓶頸，如果希望：
（1）線性提升數(shù)據(jù)庫讀性能
（2）通過消除讀寫鎖沖突提升數(shù)據(jù)庫寫性能
此時可以使用分組架構。一句話，分組架構主要解決“數(shù)據(jù)庫讀性能瓶頸”問題，在數(shù)據(jù)庫扛不住讀的時候，通常讀寫分離，通過增加從庫線性提升系統(tǒng)讀性能。
3、為什么不喜歡用 讀寫分離 架構？
首先需要明確的是：不是任何讀性能瓶頸都需要使用讀寫分離，我們還可以有其他解決方案。在互聯(lián)網(wǎng)的應用場景中，常常數(shù)據(jù)量大、并發(fā)量高、高可用要求高、一致性要求高，如果使用“讀寫分離”，就需要注意這些問題：
（1）數(shù)據(jù)庫連接池要進行區(qū)分，哪些是讀連接池，哪個是寫連接池，研發(fā)的難度會增加；
（2）為了保證高可用，讀連接池要能夠實現(xiàn)故障自動轉移；
（3）主從的一致性問題需要考慮。
在這么多的問題需要考慮的情況下，如果我們僅僅是為了解決“數(shù)據(jù)庫讀的瓶頸問題”，為什么不選擇使用緩存呢？
4、為什么用緩存？
緩存，也是互聯(lián)網(wǎng)中常常使用到的一種架構方式，同“讀寫分離”不同，讀寫分離是通過多個讀庫，分攤了數(shù)據(jù)庫讀的壓力，而存儲則是通過緩存的使用，減少了數(shù)據(jù)庫讀的壓力。他們沒有誰替代誰的說法，但是，如果在緩存的讀寫分離進行二選一時，還是應該首先考慮緩存。
為什么呢？緩存的使用成本要比從庫少非常多；緩存的開發(fā)比較容易，大部分的讀操作都可以先去緩存，找不到的再滲透到數(shù)據(jù)庫。
當然，如果我們已經(jīng)運用了緩存，但是讀依舊還是瓶頸時，就可以選擇“讀寫分離”架構了。簡單來說，我們可以將讀寫分離看做是緩存都解決不了時的一種解決方案。當然，緩存也不是沒有缺點的：對于緩存，我們必須要考慮的就是高可用，不然，如果緩存一旦掛了，所有的流量都同時聚集到了數(shù)據(jù)庫上，那么數(shù)據(jù)庫是肯定會掛掉的。
五、數(shù)據(jù)庫水平切分架構
1、什么是數(shù)據(jù)庫水平切分
對于常見的數(shù)據(jù)庫瓶頸是什么呢？
其實是數(shù)據(jù)容量的瓶頸。例如訂單表，數(shù)據(jù)量只增不減，歷史數(shù)據(jù)又必須要留存，非常容易成為性能的瓶頸，而要解決這樣的數(shù)據(jù)庫瓶頸問題，“讀寫分離”和緩存往往都不合適，最適合的是什么呢？——? 數(shù)據(jù)庫水平切分。
水平切分，也是一種常見的數(shù)據(jù)庫架構，一般來說：
-
每個數(shù)據(jù)庫之間沒有數(shù)據(jù)重合，沒有類似binlog同步的關聯(lián)
-
所有數(shù)據(jù)并集，組成全部數(shù)據(jù)
-
會用算法，來完成數(shù)據(jù)分割，例如“取?！?/span>
一個水平切分集群中的每一個數(shù)據(jù)庫，通常稱為一個“分片”。
2、水平切分架構究竟解決什么問題？
大部分互聯(lián)網(wǎng)業(yè)務數(shù)據(jù)量很大，單庫容量容易成為瓶頸，如果希望：
（1）線性降低單庫數(shù)據(jù)容量
（2）線性提升數(shù)據(jù)庫寫性能
此時可以使用水平切分架構。一句話總結，水平切分主要解決“數(shù)據(jù)庫數(shù)據(jù)量大”問題，在數(shù)據(jù)庫容量扛不住的時候，通常水平切分。
3、總結
（1）讀寫分離，解決“數(shù)據(jù)庫讀性能瓶頸”問題
（2）水平切分，解決“數(shù)據(jù)庫數(shù)據(jù)量大”問題
（3）對于互聯(lián)網(wǎng)大數(shù)據(jù)量，高并發(fā)量，高可用要求高，一致性要求高，前端面向用戶的業(yè)務場景，微服務緩存架構，可能比數(shù)據(jù)庫讀寫分離架構更合適。
本文摘自 ：https://www.cnblogs.com/
