文章目錄
一、互聯網架構的發展
1.1 早期的單機MySQL
互聯網發展早期，網站的訪問量一般都不大，使用單個數據庫可以輕鬆應付，那時候更多的是靜態網站，動態交互類型的網站並不多。
但是，上述架構存在一些瓶頸：
- 數據量的過大時，一個機器放不下。
- 數據庫的索引(B+Tree)也佔據大量磁盤空間。
- 訪問量(讀寫混合)，一個實例承受不了。
1.2 Memcached(緩存)+MySQL+垂直拆分
Memcached作爲一個
獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然後又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。
隨着訪問量的上升，使用單機MySQL架構的網站開始出現數據庫性能問題，程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，又出現了了新的問題：
- 文件緩存不能在多臺web機器上共享。
- 大量的小文件緩存提高了IO壓力
1.3 MySQl主從讀寫分離
Memcached只能緩解數據庫的讀取壓力，讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。
1.4 分庫分表+水平拆分+MySQL集羣
隨着數據量的持續猛增，MySQL主庫的寫壓力開始出現瓶頸，開始將數據庫引擎由使用表鎖的MyISAM替換爲使用行鎖的InnoDB。同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。
雖然MySQL推出了MySQL Cluster集羣，但性能也不能很好滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。
1.5 當今互聯網的架構
MySQL的擴展瓶頸：MySQL數據庫經常存儲一些大文本字段，導致數據庫表非常大，在做數據庫恢復的時候非常的慢，不容易快速恢復數據庫。關係數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要複雜的技術來實現）、大數據下IO壓力大、表結構更改困難、正是當前使用MySQL的開發人員面臨的問題。
大數據時代的三V：海量Volume、多樣Variety、實時Velocity。
互聯網需求的三高：高併發、高可擴、高性能。
二、NoSQL介紹
NoSQL(NoSQL = Not Only SQL)，意即"不僅僅是SQL"，泛指非關係型的數據庫。隨着互聯網的發展，傳統的關係數據庫在應付超大規模、高併發的、SNS類型的、純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。
例如谷歌或Facebook每天爲他們的用戶收集萬億比特的數據。這些類型的數據存儲不需要固定的模式，無需多餘操作就可以橫向擴展。
2.1 NoSQL的優點
-
易擴展
NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。 -
大數據量高性能
NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下表現優秀。這得益於它的無關係性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。 -
多樣靈活的數據模型
NoSQL無需事先爲要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件非常麻煩的事情。
2.2 RDBMS vs NoSQL
RDBMS(關係型數據庫管理系統)特點
- 高度組織化結構化數據
- 結構化查詢語言（SQL）
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言，數據定義語言
- 嚴格的一致性
- 基礎事務
NoSQL(非關係型數據庫)特點
- 代表着不僅僅是SQL
- 沒有聲明性查詢語言
- 沒有預定義的模式
- 鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫
- 最終一致性，而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能，高可用性和可伸縮性
非關係數據庫中，Redis(一專多能，數據類型豐富)、Memcache(高速緩存)、Mongdb(支持海量數據)。Redis簡單來說就是：KV+Cache+Persistence。
2.3 NoSQL數據庫的四大分類
三、分佈式數據庫的CAP原理
3.1 傳統的ACID特性
關係型數據庫的事務遵循ACID四個特性。
A (Atomicity) 原子性 |
事務是一個不可分割的工作單位。 |
|---|---|
C (Consistency) 一致性 |
事務的運行不會改變數據庫原本的一致性約束。 |
I (Isolation) 獨立性 |
事務的執行不能被其他事務干擾，併發執行的各個事務之間不能互相干擾。 |
D (Durability) 持久性 |
事務一旦被提交，對數據庫中數據的改變就是永久性的。 |
3.2 NoSQL的CAP特性
根據CAP原理將NoSQL數據庫分成了滿足CA原則、滿足CP原則、滿足AP原則三大類。
-
CA
滿足 一致性、高可用性的系統；一般在可擴展性上不太強大。 -
CP
滿足 強一致性、分區容忍性的系統；一般性能不是很高。 -
AP
滿足 高可用性、分區容忍性的系統；一般對一致性要求低一點。
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
3.3 BASE
BASE是爲了解決關係數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案，它的思想是通過讓系統放鬆對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。
BASE其實是下面三個術語的縮寫：
- 基本可用（Basically Available）
- 軟狀態（Soft state）
- 最終一致（Eventually consistent）
3.4 分佈式+集羣
分佈式系統(Distributed System)
由多臺計算機和通信的軟件組件通過計算機網絡連接（本地網絡或廣域網）組成。分佈式系統是建立在網絡之上的軟件系統。正是因爲軟件的特性，所以分佈式系統具有高度的內聚性和透明性。因此，網絡和分佈式系統之間的區別更多的在於高層軟件（特別是操作系統），而不是硬件。分佈式系統可以應用在不同的平臺上如：Pc、工作站、局域網和廣域網上等。
簡單來講：
-
分佈式： 不同的多臺服務器上面部署不同的服務模塊（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務和組內協作。
-
集羣： 不同的多臺服務器上面部署相同的服務模塊，通過分佈式調度軟件進行統一的調度，對外提供服務和訪問。