（1）可用性
（2）讀效能
（3）一致性
（4）擴充套件性
概念一「單庫」
概念二「分片」
分片解決的是「資料量太大」的問題，也就是通常說的「水平切分」。
一旦引入分片，勢必有「資料路由」的概念，哪個資料訪問哪個庫。
路由規則通常有3種方法：
（1）範圍：range
優點：簡單，容易擴充套件
缺點：各庫壓力不均（新號段更活躍）
（2）雜湊：hash
優點：簡單，資料均衡，負載均勻
缺點：遷移麻煩（2庫擴3庫資料要遷移）
（3）路由服務：router-config-server
優點：靈活性強，業務與路由演算法解耦
缺點：每次訪問資料庫前多一次查詢
大部分網際網路公司採用的方案二：雜湊分庫，雜湊路由
概念三「分組」
分組解決「可用性」問題，分組通常通過主從複製的方式實現。
網際網路公司資料庫實際軟體架構是：又分片，又分組（如下圖）
資料庫軟體架構師平時設計些什麼東西呢？至少要考慮以下四點：
（1）如何保證資料可用性
（2）如何提高資料庫讀效能（大部分應用讀多寫少，讀會先成為瓶頸）
（3）如何保證一致性
（4）如何提高擴充套件性
2.1如何保證資料的可用性？
解決可用性問題的思路是=>冗餘
如何保證站點的可用性？複製站點，冗餘站點
如何保證服務的可用性？復**務，冗餘服務
如何保證資料的可用性？複製資料，冗餘資料
資料的冗餘，會帶來乙個***=>引發一致性問題（先不說一致性問題，先說可用性）
如何保證資料庫「讀」高可用？
冗餘讀庫
冗餘讀庫帶來的***？讀寫有延時，可能不一致
上面這個圖是很多網際網路公司mysql的架構，寫仍然是單點，不能保證寫高可用。
如何保證資料庫「寫」高可用？
冗餘寫庫
採用雙主互備的方式，可以冗餘寫庫
帶來的***？雙寫同步，資料可能衝突（例如「自增id」同步衝突）,如何解決同步衝突，有兩種常見解決方案：
（1）兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id為0,2,4,6…；2寫庫的id為1,3,5,7…
（2）不使用資料的id，業務層自己生成唯一的id，保證資料不衝突
我們公司沒有使用上述兩種架構來做讀寫的「高可用」，而是採用的是「雙主當主從用」的方式：
仍是雙主，但只有乙個主提供服務（讀+寫），另乙個主是「shadow-master」，只用來保證高可用，平時不提供服務。
master掛了，shadow-master頂上（vip漂移，對業務層透明，不需要人工介入）
這種方式的好處：
1）讀寫沒有延時
2）讀寫高可用
不足：1）不能通過加從庫的方式擴充套件讀效能
2）資源利用率為50%，一台冗餘主沒有提供服務
那如何提高讀效能呢？進入第二個話題，如何提供讀效能。
2.2如何擴充套件讀效能？
提高讀效能的方式大致有三種，第一種是建立索引。這種方式不展開，要提到的一點是，不同的庫可以建立不同的索引。
寫庫不建立索引；
線上讀庫建立線上訪問索引，例如uid；
線下讀庫建立線下訪問索引，例如time；
第二種擴充讀效能的方式是，增加從庫，這種方法大家用的比較多，但是，存在兩個缺點：
（1）從庫越多，同步越慢
（2）同步越慢，資料不一致視窗越大（不一致後面說，還是先說讀效能的提高）
我們公司沒有採用這種方法提高資料庫讀效能（沒有從庫），採用的是增加快取。常見的快取架構如下：
上游是業務應用，下游是主庫，從庫（讀寫分離），快取。
我們公司的玩法是：服務+資料庫+快取一套
業務層不直接面向db和cache，服務層遮蔽了底層db、cache的複雜性。為什麼要引入服務層，今天不展開，我們公司採用了「服務+資料庫+快取一套」的方式提供資料訪問，用cache提高讀效能。
不管採用主從的方式擴充套件讀效能，還是快取的方式擴充套件讀效能，資料都要複製多份（主+從，db+cache），一定會引發一致性問題。
2.3如何保證一致性？
主從資料庫的一致性，通常有兩種解決方案：
（1）中介軟體
我們公司的「雙主當主從用」的架構，不存在主從不一致的問題。
第二類不一致，是db與快取間的不一致
常見的快取架構如上，此時寫操作的順序是：
（1）淘汰cache
（2）寫資料庫
讀操作的順序是：
（1）讀cache，如果cache hit則返回
（2）如果cache miss，則讀從庫
（3）讀從庫後，將資料放回cache
在一些異常時序情況下，有可能從【從庫讀到舊資料（同步還沒有完成），舊資料入cache後】，資料會長期不一致。
解決辦法是「快取雙淘汰」，寫操作時序公升級為：
（1）淘汰cache
（2）寫資料庫
（3）在經驗「主從同步延時視窗時間」後，再次發起乙個非同步淘汰cache的請求
這樣，即使有髒資料如cache，乙個小的時間視窗之後，髒資料還是會被淘汰。帶來的代價是，多引入一次讀miss（成本可以忽略）。
除此之外，我們公司的最佳實踐之一是：建議為所有cache中的item設定乙個超時時間。
說完一致性，最後乙個話題是擴充套件性。
2.4如何提高資料庫的擴充套件性？
原來用hash的方式路由，分為2個庫，資料量還是太大，要分為3個庫，勢必需要進行資料遷移，某大廠有乙個很帥氣的「資料庫秒級擴容」方案。
如何秒級擴容？
首先，我們不做2庫變3庫的擴容，我們做2庫變4庫（庫加倍）的擴容（未來4->8->16）
服務+資料庫是一套（省去了快取）
資料庫採用「雙主」的模式。
擴容步驟：
第一步，將乙個主庫提公升
第二步，修改配置，2庫變4庫（原來mod2，現在配置修改後mod4）
擴容完成
原mod2為偶的部分，現在會mod4餘0或者2
原mod2為奇的部分，現在會mod4餘1或者3
資料不需要遷移，同時，雙主互相同步，一遍是餘0，一邊餘2，兩邊資料同步也不會衝突，秒級完成擴容！
最後，要做一些收尾工作：
（1）將舊的雙主同步解除
（2）增加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務）
（3）刪除多餘的資料（餘0的主，可以將餘2的資料刪除掉）
這樣，秒級別內，我們就完成了2庫變4庫的擴充套件。
ok，今天主要分享了我們公司，資料庫軟體架構上：
（1）如何保證資料可用性
（2）如何提高資料庫讀效能
（3）如何保證資料一致性
（4）如何進行秒級擴容
希望大家有收穫，謝謝大家！
資料庫架構設計
當您根據現有的資料庫規劃工作流應用程式時，請記住 將現有資料庫註冊為工作流應用程式之前，請製作該資料庫的乙個備份副本。不要試圖對產品資料庫進行設計更改。將資料庫移動並複製到某個測試環境中，並在該環境中執行所有工作流實現和架構更改。在確保工作流應用程式按照預期的那樣執行之後，請將其部署到生產伺服器中。...
軟體架構設計
首先我們應該了解什麼是軟體架構設計？架構大體分為以下幾種 邏輯架構 模組劃分 介面定義 領域模型 開發架構 技術選型 檔案劃分 編譯關係 物理架構 硬體分布 軟體部署 方案優化 執行架構 技術選型 控制流劃分 同步關係 資料架構 技術選型 儲存格式 資料分布 程式設計師向架構師轉型的關鍵突破 學會系...
軟體架構設計
在嵌入式軟體開發的專案中，很少見到有專案架構師這一工作職稱，但是大型專案的總是會有架構師一說。1 為什麼嵌入式開發很少會出現架構師這一職責。嵌入式開發的專案，一般有兩種模式 一類是 完全由開發人員自己設計 排除庫函式 另一類是基於固有的作業系統進行開發。前者一般都是針對特定應用，所有 的規模不會很大...