目錄
分佈式事務保證高可用 串行化級別
- 允許多個獨立事務資源，參與到一個全局事務中，要求原子性，存儲級別必須設置爲 串行化級別
- 由XA事務實現，XA事務由一個或多個資源管理器、一個事務管理器、一個應用程序組成，採用二階段提交協議，2PC
- 內部XA事務，事務提交時，準備階段，先將事務xid寫入。再進行二進制日誌binlog寫入，如果事務提交前，MYSQL數據庫拓機，重啓後會先檢查UXID事務是否已提交，若沒有再進行一次提交操作
一、配置mysql主從模式的原因
1）Mysql內建的複製功能是構建大型、高性能應用程序的基礎。在實際企業應用環境當中，單臺mysql數據庫是不足以滿足日後業務需求的。
譬如當服務器發生故障，而沒有備份服務器來提供服務時，業務就必須得停止，這樣會對企業帶來巨大的損失。
2）爲了提高數據庫服務器的穩定性，加快數據處理的效率，保護數據免受意外的損失，我們採用mysql的主從複製方式，分離對數據庫的查詢和更新操作，使用從服務器上備份的數據保證來數據的安全性和穩定性
二、Mysql主從複製的原理
1）MySQL 的 Replication 是一個異步的複製過程，從一個 MySQL instace(我們稱之爲 Master)複製到另一個MySQL instance(我們稱之 Slave)
在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程(Sql 線程和IO 線程)在 Slave 端，另外一個線程(IO 線程)在 Master 端。
2）在執行這個主從複製之前，首先必須打開 Master 端的Binary Log(MySQL-bin.xxxxxx)功能，否則無法實現。
在啓動 MySQL Server 的過程中使用“log-bin” 參數選項
在 my.cnf 配置文件中的 MySQLd 參數組中增加“log-bin” 參數項
三、Mysql主從複製的過程
3.1、主從複製詳細過程
1） Slave 上面的IO 線程連接上 Master，並請求從指定二進制日誌文件的指定位置(或者從最開始的日誌)之後的日誌內容。
2） Master 接收到來自 Slave 的 IO 線程的請求後，通過負責複製的 IO 線程根據請求信息讀取指定日誌指定位置之後的日誌信息，返回給 Slave 端的 IO 線程。
返回信息中除了日誌所包含的信息之外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 BinaryLog 中的位置。
3）Slave 的 IO 線程接收到信息後，將接收到的日誌內容依次寫入到 Slave 端的RelayLog （中繼日誌文件）文件的最末端，並將讀取到的Master 端的bin-log 的文件名和位置記錄到master-info 文件中，
以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log 的哪個位置開始往後的日誌內容，請發給我” 。
4）Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容後，會馬上解析該 Log 文件中的內容成爲在 Master 端真實執行時候的那些可執行的 Query 語句，並在自身執行這些 Query。
這樣，實際上就是在 Master 端和 Slave 端執行了同樣的 Query，所以兩端的數據是完全一樣的。
四、MySQL支持的複製類型與MySQL複製應用類型
4.1、MySQL支持的複製類型 sql複製
1）基於語句的複製statement： 在主服務器上執行的SQL語句，在從服務器上執行同樣的語句。MySQL默認採用基於SQL語句的複製，效率比較高。一旦發現沒法精確複製時，會自動選着基於行的複製。
2）基於行的複製row：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
3）混合類型的複製mixed: 默認採用基於語句的複製，一旦發現基於語句的無法精確的複製時，就會採用基於行的複製
4.2、MySQL複製應用類型
1）數據分佈 (Data distribution )
2）負載平衡(load balancing)
3）讀寫分離(split reading and writting)
4）高可用性和容錯性 (High availability and failover )
分庫分表
索引+分庫分表實現數據高性能讀
垂直分庫
按照業務模塊來劃分出不同的數據庫；避免過早優化；用戶服務的用戶數據庫，看架構師水平
水平分表
將表中不同的數據行按照一定規律分佈到數據庫不同的表；不建議
水平分庫分表 類似mysql+redis
拆分出來的表保存在不同的數據庫
使用的“冷熱數據分離”（將一些使用較少的歷史數據遷移到其他的數據庫中。而在業務功能上，通常默認只提供熱點數據的查詢）
緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源的瓶頸
跨庫join的問題
如果有多個join的，要麼是設計不合理，要麼是技術選型有誤
首先要考慮下垂直分庫的設計問題，如果可以調整，那就優先調整
1.全局表
所謂全局表，就是有可能系統中所有模塊都可能會依賴到的一些表。比較類似我們理解的“數據字典”。爲了避免跨庫join查詢，我們可以將這類表在其他每個數據庫中均保存一份。同時，這類數據通常也很少發生修改（甚至幾乎不會），所以也不用太擔心“一致性”問題。
2.字段冗餘
“訂單表”中保存“賣家Id”的同時，將賣家的“Name”字段也冗餘
3.數據同步
定時將指定的表做同步。當然，同步本來會對數據庫帶來一定的影響，需要性能影響和數據時效性中取得一個平衡。這樣來避免複雜的跨庫查詢
4.系統層組裝
調用不同模塊的組件或者服務，獲取到數據並進行字段拼裝
分佈式存儲 mysql
業務拆分，提高吞吐量，穩定性
主從複製，擴展讀，最終一致性
採用Dual-master架構，設置stabdby Master，解決單點Master故障問題，方便停機維護
正常情況下，仍舊是隻有主master負責寫，standby負責讀，避免數據寫入的衝突，防止數據不一致情況
當停機維護時，修改配置文件（read only），standby同步完成後，接管開始寫入數據
拓機時，需要複製未同步的二進制日誌到standby，直到同步後才能夠接收寫
分庫分表 進一步擴展讀寫性能
提升讀性能，分表：訂單表，以用戶分成256張，userid%256；提升寫性能，分庫
分庫+分表：對於 userid = 262145的訪問，256個庫，每個庫1024個表
temp = 262145 %（庫數量256 * 每個庫的表數量1024）= 1
庫id = temp / 每個庫表數量 = 0
表id = temp % 每個庫表數量 = 1
將被路由到第 0 個庫，第 1 個表
缺點：1.跨表的事務變爲分佈式事務，關聯查詢複雜2.必須要用路由字段userid；3.擴容導致路由策略變更，需要數據遷移
解決：1.結合搜索引擎，構建一張經常被關聯的大表；2.Hbase，藉助region server天然支持分佈式併發讀寫
Hbase、redis
消息隊列
安全 https 對稱加密，通信過程進行加密
分佈式系統穩定性分析
日誌分析
訪問量、最耗時的頁面、404請求佔比
集羣監控：
CPU利用率、磁盤、內存、網絡、qps【每秒查詢數】、rt【響應時間】、tps【每秒事務數】
首頁在緩存中靜態化、依賴管理與優雅降級、核心鏈路開關
Mysql 超賣方案
分庫分表時，下單和減庫存不在同一個事務中，導致超賣；
分離實際庫存與頁面的瀏覽庫存，保證下單和減庫存在同一個事務中
適合innodb的行鎖，myisam是表鎖，性能差；但是行鎖也不夠快，可用連接數會被沾滿導致數據庫拒絕服務
利用innodb行鎖，庫存分成多行記錄，即分拆行鎖，庫存10000被拆分成5行庫存2000的記錄