今天早起把架構的第四章學完了。保證存儲數據的高可用。
關係型數據庫是因爲完整的事務的特性，爲大多數企業採用。當達到海量數據的時候只能考慮集羣方式去優化了。而真正面對海量數據的優化方案主要有"讀寫分離"和"分庫分表"。
讀寫分離是把讀庫和寫庫分開，寫庫會實時同步數據到讀庫，可能存在的問題就是同步延遲，不能實時看到寫入的數據。
業務分庫是指給每一項核心業務專門設置數據庫，分開存儲。這樣做會增加很多技術挑戰，很多sql查詢語句都失效了。join聯查語句部分要整改，其次是每個數據庫都只能處理自己的事務，要考慮分佈式事務解決方案，再者就是服務器的數量和成本增加了。
每增加一種技術延伸，原有的很多東西都要跟着改變，架構越複雜，變化越大。所以初創公司不建議一開始設計就弄分庫分表，一個項目的成功概率和失敗概率一樣大，有的項目可能幾年也累積不到一萬個用戶，弄億級的數據庫沒有意義，單機就行了，連集羣都不需要考慮。
分表可分爲垂直拆分和水平拆分兩個緯度，垂直拆分沒有技術含量，就相當於把蛋糕豎着切，而水平拆分可以根據多種算法和規則拆分，可以類比爲把一個excel的一個sheet頁的上億數據按照某種規則拆分到多個不同sheet裏面，等要查詢數據的時候需要同時從那些拆分好的sheet裏面查數據。常用的規則有範圍路由(根據某列有序的值的範圍)、hash路由(根據hash值)、配置路由(根據自定義配置表)。
水平拆分之後，很多sql語句功能也要變化纔能有效，比如join操作、count()操作、order by 排序操作。
上面是關係型數據庫的存儲，對於非關係型，也就是Nosql,全稱是not only sql.不僅僅是sql,它是對關係型存儲的一種補充。
世間萬物是互補的，沒有一個完美的終極方案，只有特定領域的優勢互補。火車沒有替代汽車，飛機也沒有替代火車。
關係型數據庫的最大特點是強約束驗證，它要進行大量的驗證保證數據的完整性和一致性，這樣會犧牲大量的性能，在千萬的級別它勉強適合用於檢索……會往上會有瓶頸，其次它的設計決定了它不適合做全文檢索，全文檢索可以用一個成語類比"大海撈針"。還有，關係型數據庫是按每列每個字段存儲，所以它不能直接存儲類似於set、list之類的數據結構。我們不能設計一個萬能的存儲技術。
nosql的方案有4種，而且幾乎被互聯網企業大量使用:
1.鍵_值存儲:課代表叫redis,微信和微博都是用它。
2.文檔數據庫:課代表爲MONGODB.
3.列式數據庫:課代表爲Hbase,它本質是也是大數據的解決方案框架。
4.全文檢索引擎:課代表是Elasticsearch, 我最近也在學習它。
Redis我接觸最多，它除了可以做緩存使用之外還有很多妙用，比如做商場的秒殺活動，秒殺本質是幾秒鐘內幾萬次請求，如果是訪問關係型數據庫的話，數據庫肯定承受不了，而redis的數據是在內存中的，直接訪問內存是沒有問題的，不需要考慮事務，只需要考慮是否賣超了，這就是秒殺最關注的點。它還可以做分佈式系統的session共享和分佈式鎖。微博最常用的操作就是把熱點數據和明星發的微博都存到緩存中，這樣都是爲了提高系統性能和保全關係型數據庫的訪問壓力問題。
每種方案都有各自的特點，只有某個業務場景符合某種技術的時候纔要考慮到它，比如列式數據庫只有對於針對某列的統計的時候纔會發揮巨大作用，因爲平常關係型數據庫會把一行信息都查出來，太浪費性能了。又比如我們去歐洲旅行，首選的交通工具是飛機，但假如你的需求是拍沿途風景，那麼幾天幾夜的火車也是可以考慮的。
緩存還會有一些常用問題
緩存穿透
比如某些數據在數據庫裏和緩存裏都沒有，那麼每次都還是需要去數據庫查詢，當有些黑客刻意用這個查詢去攻擊的時候，可能會讓你的應用服務器崩潰。常用的解決辦法是如果沒有對應值，也要在緩存生成一個鍵值對，返回空內容，這樣緩存就可以保護數據庫了。
緩存雪崩
大量緩存失效或者緩存生成時間很長，都會造成大量請求直接繞過緩存去請求應用服務器，可能會讓應用癱瘓，這點和地球非常類似，大氣層就像緩存一樣保護着地球，一些隕石就是請求……
解決雪崩的方案是可以對更新緩存加一把更新鎖，確保每次只有一個請求更新緩存，其它請求會直接返回null ，另一種方案是採用後定時去更新緩存。