這篇文章沒有什麼操作性，主要是讓夥伴們開拓視野的，通過一些使用場景，並沒有太多上手的操作。
讀多寫少的業務場景
- 普遍來說，絕大多數系統都是讀多寫少的
也就是select語句執行的多，而insert、delete、update這樣的操作執行的很少，比如
上面都是屬於讀多寫少的範疇，就那在線購物來說
我們在淘寶上看的多買的少，也就是貨比三家後才下單，我們在貨比三家的過程中，其實產生了很多查詢的操作，只有在下單的時候才產生了insert操作。
再比如我們在手機上看了多條新聞，纔回復一條評論。再有就是58同城、大衆點評也都是讀多寫少。
因爲數據庫就爲CRUD這些操作設計的，所以這些場景，關係型數據庫就足以應付了，無論使用MySQL呀、Oracle呀都是沒有問題，如果併發量很大的話，可以組建MysQL集羣來應對。
寫多讀少的場景
比如說我們使用滴滴出行app預約了專車，形成開始後，滴滴app就會實時上傳專車的線路信息，這麼做也是爲乘客安全考慮的。上傳的數據都會保存在數據庫裏，而且這些數據都是很少查詢，只有在乘客報警或者發生糾紛的情況下，滴滴纔會調取這次專車出行的數據，所以這是明顯的一個寫多讀少的場景。
大學食堂也是寫多讀少的場景，寫多讀少的業務場景裏，使用普通的關係型數據庫可以嗎？
寫多讀少的解決方案1
- 如果寫多讀少是低價值的數據，可以採用NoSQL數據庫來存儲這些數據
什麼是低價值的數據呢？比如說線路的座標，雖然數據很多，但是每條數據的價值不是很大，用MySQL這樣的關係型數據庫去存儲，那麼事務上的開銷就讓我們無法承受。因爲在事務這個機制下面，寫入數據之前都要先寫undo日誌、然後還要寫redo日誌，都沒有問題了，等到事務提交的時候，再把redo日誌裏面的數據同步到數據文件裏。
在讀多寫少的場景下，雖然事務下的數據庫寫入速度並不是特別快，但是寫入的業務量並不是很大，所以看不出很麼問題。但是，在寫多讀少的場景裏，每一秒的寫入大量數據，事務機制就會拖累寫入的速度，因此說傳統的關係型數據庫就不太適合了，但我們要獨闢蹊徑纔行。
就目前來說，最好的辦法是使用NoSQL數據庫，比如Mongodb這樣的NoSQL產品的讀寫性能非常好，這是因爲NoSQL數據庫拋棄複雜的表結構和字段約束，甚至去除了事務機制，在寫入數據的時候，不需要做sql語法校驗和優化，也不用寫undo、redo日誌，那麼數據的寫入速度，是遠遠超過關係型數據庫的。
保存低價值數據使用NoSQL數據庫是再適合不過了。我們在創建數據的時候，需要創建兩個數據源
寫多讀少的解決方案2
- 如果是高價值的數據，無法承受數據的丟失，可以用TokuDB來保存
比方說刷卡消費的數據就非常重要，因爲所有的NoSQL數據庫都是不支持事務的，所以它們不適合保存高價值數據，還得傳統的關係型數據庫纔行，但是傳統的MySQL數據庫寫入性能是非常低下的。所以我們需要專門爲寫入優化的數據庫產品，恰好MySQL有一個數據庫引擎叫TokuDB，它可以帶着事務保持數據的高速寫入。
- TokuDB的寫入速度是InnoDB的9~20倍，數據的壓縮比大概是InnoDB的15倍
光是這個寫入速度都趕上NoSQL數據庫了，那麼TokuDB可以說是MySQL領域最好的引擎了，所以我們在設計業務系統的時候，傳統的數據可以保存在普通的MySQL數據庫裏面，但是大規模寫入的數據我們可以使用TokuDB來存儲。至於怎麼安裝TokuDB數據庫呢？可以百度下，這方面的資料非常多。
寫多讀多的業務場景
這種場景比較特殊，並不常見。比如說微信、qq具有離線留言的功能，即便對方沒有上線，我們發出去的消息會被臨時存儲在數據庫上，等到對方上線的時候，就能收到這些離線的消息了，微信、QQ的用戶量很大，很多離線的消息要存儲，很多用戶上線後還要去獲取離線消息
所以在數據庫這端來是看，離線消息的存儲就是讀多寫多的，傳統的關係型數據庫，是沒有辦法應對這個場景的，所以我們呢只能求助NoSQL數據庫了。包括微信朋友圈也是讀多寫多的場景，那麼朋友圈的數據也是存儲在NoSQL數據庫上的
數據庫集羣的方案缺點
不管什麼樣的業務場景，只要用到了數據庫，就要建立集羣，關係型數據庫可以搭建集羣，NosQL數據庫也可以搭建集羣。
其實
- 數據庫集羣的讀寫速度低於單節點的數據庫實例
用MySQL舉個例子，下圖有三個MySQL節點搭建的集羣，用MyCAT來管理集羣，
當我們要保存一條商品記錄的時候，MyCat要生成全局主鍵，然後還要看商品是什麼類型的，如果是是電器類型的商品，就會把sql語句轉發給第一個Mysql存儲；如果是是廚具就會轉發給第二個Mysql，依次類推，如果是食品的商品會轉發給第三個mysql節點。正因爲MyCAT要做這些額外的工作，在這裏回有少許的損耗，所以數據庫的集羣寫入速度，肯定比不上單節點的MySQL的。
數據庫集羣方案的優點
有童鞋會產生疑問，既然集羣的速度趕不上單節點的速度，那我我們爲什麼還要搞集羣呢？下面就說下原因
- 數據庫集羣能支持更大規模的併發訪問，並且存放更多數據
- 比如單節點的難以支持500個併發連接，用上集羣后數量就會翻倍。單節點在高併發的時候，實際性能很多童鞋是深有體會，比如很多大學的校園網都是單節點的部署，等到期末考試後，大家在同一天去校園網查詢考試成績，當天的校園網加載速度是非常慢的，瀏覽器半天也刷不出來網頁，單節點的數據庫支持1萬的併發訪問都很困難，我們怎麼敢在網站上使用單節點的數據庫呢？所以我們必須要對數據庫做集羣，併發性才能上去。
- 用了集羣可以存放更多數據，因爲InnoDB引擎單表數據量如果超過2000萬，這個數據表讀寫速度就會明顯的下降，因此我們可以把數據切分存儲到不同的mysql節點上，這樣每個節點上單表數據就會減少了，整個集羣能保存的數據量就更多了
- 能增強抵禦故障的能力
我們再給MysQl節點配上冗餘的備份節點，比如第一個MySQL節點掛掉了，它的備份節點就可以立即投入使用，這樣抵禦故障的能力就會被單節點好很多