數據庫主從復制，讀寫分離，分庫分表，分區講解
隨著互聯網應用的廣泛普及，海量數據的存儲和訪問成為了系統設計的瓶頸問題。對于一個大型的互聯網應用，每天幾十億的PV無疑對數據庫造成了相當高的負載。對于系統的穩定性和擴展性造成了極大的問題。通過數據切分來提高網站性能，橫向擴展數據層已經成為架構研發人員首選的方式。
mysql主從復制原理
主要涉及三個線程：binlog 線程、I/O 線程和 SQL 線程。
- binlog 線程 ：負責將主服務器上的數據更改寫入二進制日志(Binary log)中。
- I/O 線程 ：負責從主服務器上讀取二進制日志，并寫入從服務器的中繼日志(Relay log)。
- SQL 線程 ：負責讀取中繼日志，解析出主服務器已經執行的數據更改并在從服務器中重放(Replay)。
這張圖就很清晰表達出流程
1：主庫db的更新事件(update、insert、delete)被寫到binlog
2：從庫發起連接，連接到主庫
3：此時主庫創建一個binlog dump thread線程，把binlog的內容發送到從庫
4：從庫啟動之后，創建一個I/O線程，讀取主庫傳過來的binlog內容并寫入到relay log
5：還會創建一個SQL線程，從relay log里面讀取內容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db.
主從同步復制模式：
讀寫分離：
MYSQL讀寫分離的原理其實就是讓Master數據庫處理事務性增、刪除、修改、更新操作(CREATE、INSERT、UPDATE、DELETE)，而讓Slave數據庫處理SELECT操作，MYSQL讀寫分離前提是基于MYSQL主從復制，這樣可以保證在Master上修改數據，Slave同步之后，WEB應用可以讀取到Slave端的數據。
數據庫分區：
分區并不是生成新的數據表，而是將表的數據均衡分攤到不同的硬盤，系統或是不同服務器存儲介子中，實際上還是一張表。另外，分區可以做到將表的數據均衡到不同的地方，提高數據檢索的效率，降低數據庫的頻繁IO壓力值，分區的優點如下：
- 相對于單個文件系統或是硬盤，分區可以存儲更多的數據;
- 數據管理比較方便，比如要清理或廢棄某年的數據，就可以直接刪除該日期的分區數據即可;
- 精準定位分區查詢數據，不需要全表掃描查詢，大大提高數據檢索效率;
- 可跨多個分區磁盤查詢，來提高查詢的吞吐量;
- 在涉及聚合函數查詢時，可以很容易進行數據的合并;
1、水平分區
這種形式分區是對表的行進行分區，通過這樣的方式不同分組里面的物理列分割的數據集得以組合，從而進行個體分割(單分區)或集體分割(1個或多個分區)。所有在表中定義的列在每個數據集中都能找到，所以表的特性依然得以保持。
2、垂直分區
這種分區方式一般來說是通過對表的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分區，每個分區都包含了其中的列所對應的行。
什么時候考慮使用分區?
- 一張表的查詢速度已經慢到影響使用的時候。
- sql經過優化
- 數據量大
- 表中的數據是分段的
- 對數據的操作往往只涉及一部分數據，而不是所有的數據
分庫分表：
分庫分表的原因：
- 隨著單庫中的數據量越來越大，相應的，查詢所需要的時間也越來越多，相當于數據的處理遇到了瓶頸
- 單庫發生意外的時候，需要修復的是所有的數據，而多庫中的一個庫發生意外的時候，只需要修復一個庫(當然，也可以用物理分區的方式處理這種問題)
什么時候考慮使用分庫?
單臺DB的存儲空間不夠
隨著查詢量的增加單臺數據庫服務器已經沒辦法支撐
分庫解決的問題：
其主要目的是為突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。
垂直拆分
將系統中不存在關聯關系或者需要join的表可以放在不同的數據庫不同的服務器中。
按照業務垂直劃分。比如：可以按照業務分為資金、會員、訂單三個數據庫。
需要解決的問題：跨數據庫的事務、jion查詢等問題。
水平拆分
例如，大部分的站點。數據都是和用戶有關，那么可以根據用戶，將數據按照用戶水平拆分。
按照規則劃分，一般水平分庫是在垂直分庫之后的。比如每天處理的訂單數量是海量的，可以按照一定的規則水平劃分。需要解決的問題：數據路由、組裝。
什么時候考慮分表?
- 一張表的查詢速度已經慢到影響使用的時候。
- sql經過優化
- 數據量大
- 當頻繁插入或者聯合查詢時，速度變慢
分表解決的問題
分表后，單表的并發能力提高了，磁盤I/O性能也提高了，寫操作效率提高了
- 查詢一次的時間短了
- 數據分布在不同的文件，磁盤I/O性能提高
- 讀寫鎖影響的數據量變小
- 插入數據庫需要重新建立索引的數據減少
垂直分表
水平分表
存儲演變：
單庫單表
單庫單表是最常見的數據庫設計，例如，有一張用戶(user)表放在數據庫db中，所有的用戶都可以在db庫中的user表中查到。
單庫多表
隨著用戶數量的增加，user表的數據量會越來越大，當數據量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。
可以通過某種方式將user進行水平的切分，產生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數據剛好是一份完整的數據。
多庫多表
隨著數據量增加也許單臺DB的存儲空間不夠，隨著查詢量的增加單臺數據庫服務器已經沒辦法支撐。這個時候可以再對數據庫進行水平拆分。
數據庫額外小知識：
MySQL 使用自增ID主鍵和UUID 作為主鍵的優劣比較詳細過程(從百萬到千萬表記錄測試)
(1)單實例或者單節點組：
經過500W、1000W的單機表測試，自增ID相對UUID來說，自增ID主鍵性能高于UUID，磁盤存儲費用比UUID節省一半的錢。所以在單實例上或者單節點組上，使用自增ID作為首選主鍵。
(2)分布式架構場景：
20個節點組下的小型規模的分布式場景，為了快速實現部署，可以采用多花存儲費用、犧牲部分性能而使用UUID主鍵快速部署;
20到200個節點組的中等規模的分布式場景，可以采用自增ID+步長的較快速方案。
200以上節點組的大數據下的分布式場景，可以借鑒類似twitter雪花算法構造的全局自增ID作為主鍵。
