數據可靠+負載均衡：主從復制 + 分庫分表
一、主從復制
原理解析：
從庫生成兩個線程，一個 I/O 線程，一個 SQL 線程；
I/O 線程去請求主庫的 binlog，並將得到的 binlog 日志寫到 relay log(中繼日志) 文件中；
主庫會生成一個 log dump 線程，用來給從庫 I/O 線程傳 binlog；
SQL 線程會讀取 relay log 文件中的日志，並解析成具體操作，來實現主從的操作一致，而最終數據一致；
binlog:
二進制日志，記錄mysql的數據更新，主要用於主從復制。
主從復制的方式（面試題）：
Statement：基於 SQL 語句的復制，statement-based replication, SBR
優點：日志量小，節約IO，提高性能。 缺點：某些情況下會導致 master-slave中的數據不一致。
Row：基於行的復制，row-based replication, RBR
優點：精准 缺點：日志量大
Mixed：混合模式復制，mixed-based replication, MBR【推薦】
一般的復制使用STATEMENT模式保存binlog 對於STATEMENT模式無法復制的操作使用ROW模式保存binlog MySQL會根據執行的SQL語句選擇日志保存方式。
主從復制的類型：
同步復制： slave同步完成后才提交事務
異步復制：不關心slave是否同步便提交事務【推薦】
半同步復制：部分slave同步完成后便提交事務
redolog與binlog的區別（面試題）：
1.redolog是存儲引擎產生的，binlog是mysql server產生的。
2.redolog用於宕機后臟頁的恢復，binlog主要用於主從復制。
二、讀寫分離
（面試題：什么是讀寫分離）
寫操作（delete/update/insert）走主庫，讀操作（select）走從庫。
常用的讀寫分離中間件：
mysql-proxy：mysql官方提供的。
dbproxy：美團點評公司技術工程部DBA團隊(北京)提供的。【推薦】
mycat：民間社區提供的【不推薦】
讀寫分離需要高可用，不能單點：
三、分庫分表
把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的瓶頸問題。
水平拆分：按照不同的表(或者 Schema)來切分到不同的數據庫中。【很少場景能如此做】
垂直拆分：根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多台數據庫上。【基本都需要這么做】
拆分帶來的問題？
拆分原則難以把控
跨庫查詢
主鍵唯一性受到挑戰
跨庫事務帶來的性能損耗
分布式主鍵生成方式（面試題）：
UUID：
優點：可用性高、性能高
缺點：無序，不自增
中間件自增：Redis/ZK
優點：簡單
缺點：可用性問題、ID可靠性較差
雪花算法： Twitter 公布的分布式主鍵生成算法，它能夠保證不同進程主鍵的不重復性，以及相同進程主鍵的有序性。在同一個進程中，它首先是通過時間位保證不重復，如果時間相同則是通過序列位保證。【推薦】
優點：相對有序，性能高
缺點：需要發現與容忍“時鍾回撥”
數據庫號段模式：一台數據庫的一張表做為號段存儲，每次要產生ID時，動態去申請一批次在內存中使用【推薦】
優點：自增有序
缺點：高可用與性能相對差一些