mysql 三高
高並發：同時處理的事務數高
高性能：事務/SQL的執行速度高
高可用：系統可用的時間高
如何實現三高
高並發：通過復制和擴展，將數據分散至多個節點
高性能：復制提升速度，擴展提升容量
高可用：節點間身份切換保證隨時可用
實現三高的手段
復制
目的：數據冗余
手段：binlog傳送
收貨：並發量提升、可用性提高
問題：占用更多硬件資源
擴展
目的：擴展數據庫容量
手段：數據分片分庫、分表
收貨：性能、並發量提升
問題：可能降低可用性
切換
目的：提高可用性
手段：主從身份切換
收貨：並發量提升
問題：丟失切換時
演進
dble分了兩個數據分片，每個數據分片都是一個獨立的數據庫集群，一主兩備，MHA manager負責管理每一片的主備的健康，如果有問題的話，MHA manager負責主備的切換，而且MHA manager在主備切換的時候會通知DBLE，讓DBLE的流量導到新上來的主庫上去。這個架構在很多公司或者雲服務廠商叫作DRDS，分布式數據庫服務。在幾年前比如在阿里雲買DRDS服務，現在阿里雲沒有這個服務了，其實阿里雲就是提供一個類似架構的mysql集群。
問題：這么一個架構，說掛就掛！
因為有一個單點問題，DBLE是單點的，比如DBLE宕機了，下面的數據庫再健壯也沒用，因為客戶端連接的是DBLE，業務永遠不可能只連接MYSQL A或者MYSQL B，因為MYSQL分庫分表了，MYSQL A或者MYSQL B永遠都是一部分數據，所以業務直接連上沒有意義，必須通過DBLE，而DBLE單點的問題就是成了這個系統架構最薄弱的點。
搭建多個DBLE，每個DBLE都做相同的配置，配置它連接MYSQL A和MYSQL B，然后每個DBLE都可以獨立的訪問，這樣其實不可以！因為分庫分表了，虛擬表和虛擬數據庫的信息是存在DBLE上的，進一步說每個表按照什么列分配的，比如按時間，三年前的放在A庫，三年后的放在B庫，這個信息怎么分，元數據是放在DBLE上，現在DBLE一個變成多個，它們之間的元數據如何同步？很難同步！比如業務要新建一個表，新的表的數據是存在DBLE上的，比如有什么字段，怎么分表，都是存在DBLE上，比如客戶端連接的是第一個DBLE，第一個DBLE記錄了創建新表，但另外兩個不知道，下次別的客戶端連接另外兩個DBLE，另外兩個DBLE都不知道有新表創建，所以說多個DBLE之間的數據是需要同步的，比如讓一個DBLE當主DBLE，其中的當備DBLE，可不是不可以，但DBLE可以借助zookeeper，zookeeper是一個經典的分布式協調服務，這個服務可以保存很多數據和元數據，而且在保存數據量不大的時候可以做到高可用，而且不需要DBLE從主復制到備的問題，任何的元數據都存到zookeeper上，遇到任何元數據的問題都從zookeeper拉回來，這樣就用zookeeper存儲表信息、分片等信息，當客戶端在其中一個DBLE上創建新表插入了新數據或者修改了表的元數據的時候，DBLE會把數據存儲到zookeeper集群里，然后另外的DBLE在需要元數據的時候，從zookeeper集群獲取，這樣就完美解決了多個DBLE節點數據同步問題。
那為什么MYSQL 不能用zookeeper做數據同步？因為用zookeeper做數據同步代價非常大、性能非常差，因為MYSQL數據大，幾個G的。
但現在看還有一些問題，比如如何實現負載均衡，比如有多個業務應用，分攤開DBLE上，人為分散開。業務是可以分散開，但是有個問題，MHA manager怎么分散開，MHA manager需要知道DBLE的IP，給MHA一個DBLE IP可以，但MHA manager修改MYSQL的主從IP信息的時候，它調一個DBLE，DBLE會把信息存儲在zookeeper，別的DBLE也會知道，但配置在MHA manager上IP 所屬的DBLE掛了呢，MHA manager就找不到DBLE了，如果主備切換了的話，MHA manager就不知道告訴誰了，因為MHA manger只能配置一個DBLE IP，但是腳本里只能配一個，也可以配置多個，但是很麻煩，有點多余！
用keepalived可以實現，把每一個DBLE掛一個VIP，就是虛擬IP，這個虛擬IP供給MHA manager使用，也可以給客戶端使用，就好比客戶端和MHA manager都連接這個IP，DBLE上都安裝keepalived，如果其中一個DBLE掛了，那么兩邊的keepalived會自動選擇一個優先級高的，把VIP拽過來，也就是說同樣的一個IP，之前綁定在宕機之前的服務器上，轉移之后會綁定在另外正常的優先級高的服務器上，這樣的話客戶端和MHA manager在調用DBLE的時候，會不知不覺中調用新的DBLE。
但這種架構也有問題，對於MHA manager沒問題，它能找到DBLE就可以，但對於客戶端來說，所有的客戶端都連接一個VIP，所有的壓力都壓在一個DBLE身上，業務量大的話，被切換后的DBLE還會掛，業務流高峰不敢保證單點不被沖垮。這時候引用SLB或者HaProxy。
SLB是各個雲服務廠商都提供的負載均衡服務，保證SLB負載均衡器的高可用，我們不用管它，我們只需要告訴它把進來的請求分發到哪幾個服務器就可以，然后雲服務廠商會給我們提供一個SLB的IP，我們所有的業務配置這個SLB的IP，它會給我們轉發到三個DBLE。假如你想自己搭的話，也可以用HaProxy，但HaProxy會占用一台服務器，HaProxy作為負載均衡器，所有的業務都調用HaProxy，然后轉發給三個DBLE，這樣就解決了多個DBLE負載不均衡問題，避免了單點宕機。用HaProxy就要面臨自己解決單點失效的問題，因為這時候HaProxy也是單點，這個單點失效的問題往往要把單點變為多點，這樣需要搞多台HaProxy服務器，然后HaProxy再裝Keepalived，用HaProxy+keepalived這種經典架構來保證負載均衡器的高可用。也就是keepalived先把VIP綁定在其中一台負載均衡器上，然后這台負載均衡器掛了的話，keepalived會把VIP自動轉移到另一台負載均衡器，客戶端就會走另一台負載均衡器，負載均衡器就會客戶端均衡負載到多個DBLE上，多個DBLE再把請求轉發給兩個數據分片上。
然后Mysql再實現讀寫分離！也就是DBLE現在都是走的主庫，然后加上配置讀寫分離，配置好多個DBLE就可以讀走備庫、增刪改走主庫，這樣就行程了一個高性能、高可用、高並發的架構集群！