《從0開始學架構》讀書筆記

高性能

任務分解(微服務)

簡單的系統更容易高性能、更容易拓展

高可用

本質是經過冗餘實現高可用(多臺、多機房、多通道), 可是冗餘帶來了更大的複雜性. 好比任務分配器(例nginx)鏈接檢測、管理、維護、中斷處理.

常見冗餘形式 1主3備、4主0備、3主1備等

思考: zookeeper屬於1主多備, 而memcache集羣屬於全主0備, 根據具體業務場景進行選型.

最大難點: 存儲高可用(有狀態)

分佈式環境: 某個時間點, 數據確定不一致.

常見公式: 數據+邏輯=業務

存儲高可用的難點不在於如何備份數據, 而在於如何減小或規避數據不一致對業務形成的影響.

引伸 CAP 定理

不可能同時知足 一致性、可用性和分區容錯性. 最多同時知足兩個.

引入狀態決策: 斷定當前是否異常, 進行糾正.

可是又引來更復雜問題: 狀態決策的高可用也是沒法知足的.

常見狀態決策: 獨裁式(單點)、協商式(主備) 和 民主式(選舉)

民主選舉

每一個單體做出決策, 按多數取勝, 引入新問題(腦裂).

如何解決腦裂問題: 投票節點數必須超過總節點數的一半.

但又引入新問題: 若是超過一半節點故障, 而不是腦裂, 則致使選舉直接失敗, 系統宕機.

可拓展性

1. 預測變化

2. 應對變化(變化層防腐, 穩定層) 系統拆分變化層、穩定層

3. 觀察問題理解問題角度不一樣 提煉抽象層、實現層, 舉例: 規則引擎

4. 低成本 低成本與高可用存在本質上的衝突. 引入新技術, 新思路節省資源.

5. 安全 功能安全: XSS、CSRF、Sql注入 架構安全: DDOS(難以實現), 依靠運營商強大帶寬、流量清洗

存儲高性能

主從 -> 從提供讀服務

主備 -> 備不提供服務

行式數據庫和列式數據庫對比:

• mysql : 行式數據庫, 查庫已行爲維度

• hbase : 列式數據庫

業務讀取更近的多個列, 行式數據庫佔優. 若是隻是統計某個字段, 不必取行後再找列, 而只須要查詢一列就能夠了. IO將大大減小. 別且列的存儲類似度高, 壓縮比 比行式更有優點.

關於CAP理論

上面咱們提到了CAP理論, 這裏咱們詳細說一下

分佈式系統上理論是沒有 CA 的, 緣由很簡單, 當咱們犧牲P時, 一致性就沒法保證, 若是保證一致性, 就須要禁止寫入, 就沒法保證可用, 因此當分區故障時, 一致性和可用性是沒法同時保證的.

CP: 當優先保證一致性時, 犧牲可用性.

AP: 當優先保證可用性時, 各自維護數據返回, 無一致性.

CAP細節:

• CAP關注的是數據而不是系統

• CAP 是理論忽略網絡延遲的, 不然任務分區都不能保證一致性, 但並不意味着沒法使用分佈式, 分具體業務場景, 有些很是重要的信息沒法忽略, 能夠互相主備, 全部操做都發生在主數據庫上

BASE

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。

基本可用, 軟狀態, 最終一致性.