阿里P8架構師帶你玩轉資料庫 “讀寫分離”
想用資料庫“讀寫分離” 請先明白“讀寫分離”解決什麼問題
有一些技術同學可能對於“讀寫分離”瞭解不多，認為資料庫的負載問題都可以使用“讀寫分離”來解決。
這其實是一個非常大的誤區，我們要用“讀寫分離”，首先應該明白“讀寫分離”是用來解決什麼樣的問題的，而不是僅僅會用這個技術。
什麼是讀寫分離？
其實就是將資料庫分為了主從庫，一個主庫用於寫資料，多個從庫完成讀資料的操作，主從庫之間通過某種機制進行資料的同步，是一種常見的資料庫架構。
一個組從同步叢集，通常被稱為是一個“分組”。
資料庫分組架構解決什麼問題？
大多數網際網路業務，往往讀多寫少，這時候，資料庫的讀會首先稱為資料庫的瓶頸，這時，如果我們希望能夠線性的提升資料庫的讀效能，消除讀寫鎖衝突從而提升資料庫的寫效能，那麼就可以使用“分組架構”（讀寫分離架構）。
用一句話概括，讀寫分離是用來解決 資料庫的讀效能瓶頸 的。
但是，不是任何讀效能瓶頸都需要使用讀寫分離，我們還可以有其他解決方案。
在網際網路的應用場景中，常常資料量大、併發量高、高可用要求高、一致性要求高，如果使用“讀寫分離”，就需要注意這些問題：
資料庫連線池要進行區分，哪些是讀連線池，哪個是寫連線池，研發的難度會增加；
為了保證高可用，讀連線池要能夠實現故障自動轉移；
主從的一致性問題需要考慮。
在這麼多的問題需要考慮的情況下，如果我們僅僅是為了解決“資料庫讀的瓶頸問題”，為什麼不選擇使用快取呢？
為什麼用快取
快取，也是網際網路中常常使用到的一種架構方式，同“讀寫分離”不同，讀寫分離是通過多個讀庫，分攤了資料庫讀的壓力，而儲存則是通過快取的使用，減少了資料庫讀的壓力。他們沒有誰替代誰的說法，但是，如果在快取的讀寫分離進行二選一時，還是應該首先考慮快取。
為什麼呢？
快取的使用成本要比從庫少非常多；
快取的開發比較容易，大部分的讀操作都可以先去快取，找不到的再滲透到資料庫。
當然，如果我們已經運用了快取，但是讀依舊還是瓶頸時，就可以選擇“讀寫分離”架構了。簡單來說，我們可以將讀寫分離看做是快取都解決不了時的一種解決方案。
當然，快取也不是沒有缺點的
對於快取，我們必須要考慮的就是高可用，不然，如果快取一旦掛了，所有的流量都同時聚集到了資料庫上，那麼資料庫是肯定會掛掉的。
對於常見的資料庫瓶頸是什麼呢？
其實是資料容量的瓶頸。例如訂單表，資料量只增不減，歷史資料又必須要留存，非常容易成為效能的瓶頸，而要解決這樣的資料庫瓶頸問題，“讀寫分離”和快取往往都不合適，最適合的是什麼呢？
資料庫水平切分
什麼是資料庫水平切分？
資料庫水平切分，也是一種常見的資料庫架構，是一種通過演算法，將資料庫進行分割的架構。一個水平切分叢集中的每個資料庫，通常稱為一個“分片”。每一個分片中的資料沒有重合，所有分片中的資料並集組成全部資料。
水平切分架構解決什麼問題呢？
大部分的網際網路業務，資料量都非常大，單庫容量最容易成為瓶頸，當單庫的容量成為了瓶頸，我們希望提高資料庫的寫效能，降低單庫容量的話，就可以採用水平切分了。
而有少部分程式員，會沒有分析資料庫的效能瓶頸是什麼，就貿貿然的使用“讀寫分離”，殊不知“水平切分”才是正道。
歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！