4.搭建大規?？蓴U展系統
大綱
- 分布式系統
- 數據庫系統
- 經典架構
- 設計原則：CAP理論
- 一致性介紹
- 關系型數據庫
- ACID vs. BASE
- sharding 分片
- MYSQL數據庫
- Cassandra
- 實時系統：Kafka，Storm
** What is Scalability **
擴展性，當遇到許多用戶的同時訪問，不影響原有性能。平衡負載。性能是單個的用戶體驗，可擴展是在系統的層面，整體的訪問效果，更在乎一個統計量，例如一個網站，90%用戶訪問時的響應時間。
Distributed System
Classic Master/Slave
4.png
如何檢測一臺機器是否宕機？
- 第一種情況，Slave工作節點宕機，這個時候Master節點需要能檢測出來，并把該Slave的工作遷移到另外一臺機器上。
- 一般是由于某個時段過于繁忙，造成機器的“假死”，假死后，Master節點已經把工作遷移到別的工作節點上，而它本身確認為還可以繼續提供服務，多個節點服務于同一份數據，這個時候就容易造成數據不統一。
- 一種解決辦法是使用一種lease，當工作節點擁有lease時，才能提供服務，否則則會主動下線，避免了數據不統一。當工作節點的lease快到期的時候，則會主動向Master節點申請lease，Master會檢查是否合法，如果失效，則進行服務遷移。
- 第二種情況，Master節點宕機，此時需要備用的Master節點能夠加測到，以替換該Master節點對外繼續服務。
- 主備節點可以維持一種heartbeat，這樣的話當heartbeat中斷后，備用節點就可以提升為主節點，繼續服務。
- 分布式的一致性問題，分布式鎖
- Chubby
- Zookeeper
CAP Theorem
- Consistency 不同的客戶端對同一份數據總是擁有同樣的view，一致性。
- Availability 所有的客戶端總是可以讀寫，高可用。
- Partition tolerance 分區的可容忍性，跨全球物理網絡的分區，系統扔工作良好，分布式。
Pick any two. You can't have all three.
5.png
Real world examples of CAP
- Amazon's Dynamo. AP: Data become consistent over time.
- Google's BigTable. CP
- Hbase. CP
- DynamoDB. AP
- CA 一般應用于事物，高可用，強一致性。
Database System
Relational DBMS
傳統系統的事物必須擁有如下特性：
Earlier System were designed for ACID properties:
- A Atomic，原子性，要不操作完成，要不什么都不操作
- C Consistent，一致性，由數據庫內部保障或應用保障
- I Isolated，隔離性，每個事務之間都隔離，每個事務都不能看到別的事務的中間狀態
- D Durable，持久性
ACID vs. BASE
"Basically Available, Soft state, Eventually consistent"
在微博系統中，A發了一個消息，他自己馬上可以看到，但是關注A的人，只要在一定時間能可以看到就可以了，并不是要求馬上就可以看到。
應用拆分
6.png
- 系統拆分，盡量保障子系統的功能的垂直
- 要十分小心循環依賴，有可能啟動失敗
數據庫拆分
- Horizontal Scaling（Sharding）
- 當某個表數據量非常大時，則需要水平分表，對應用的影響較大
- 使用 Database Access Layer來屏蔽底層數據的存儲對應用的影響
- Functional Scaling（Scale out）
Stateless
Session Vs. Cookie
7.png
異步通信
RPC
8.png
有效利用Cache
9.png
Consistency & Replication
- 為了達到可靠性，需要把數據復制到多個數據源。
- 當需要修改某個數據，就帶來了問題，是否能保障同時修改。
- 讀取的時候，讀多份，當超過一半的數據源一致，則認為其可靠。
- 寫入的時候可以寫入到日志，最終通過異步方式寫入。
一致性
- 強一致性 系統中某個數據被更新后，后續任何對該數據的操作，都應該拿到是該數據更新過的數據。傳統關系型數據庫。
- 弱一致性 系統中某個數據被更新后，后續對該數據的操作，不一定拿到的是更新后的值，有一個窗口期。
- 最終一致性 屬于弱一致性的一種。
Consistent Hashing
Distributed Hash Table
10.png
- 良好的分布式哈希，應該具有單調性，在服務器節點的增減，不應該造成哈希的重定位。
一致性hash算法
11.png
- 將服務器和數據都記性hash計算，假設分布在一個連續的hash環上，對數據進行hash后，定位在hash環上的一個點，然后就行順時針移動，把它交由在hash環上遇到的第一個服務器去處理，不會因為服務器節點的變化引起哈希重定位。
容錯性和擴展性
12.png
- 當Server3 宕機后，對原數據A,B,C都不會造成影響，只有數據D又影響。
13.png
- 當增加一臺Server4，只影響了數據B，其他也不會造成影響，具有較好的容錯性和擴展性。
虛擬節點
14.png
- 如圖所示，Server1和Server2分布不均勻，導致Server1的壓力非常大。
15.png
- 一種解決辦法，對一臺Server多次hash，形成多個虛擬節點，這樣可以均衡負載。
一致性hash案例
16.png
- Cassandra
- Amazon's Dynamo
- HBASE
- MongoDB
NoSQL Database
- 水平分區
- gets() sets()
- key/value
- 不支持jion等
- 億級的數據
Cassamdra
17.png
Write Data Flows
18.png
分布式系統設計模式
19.png
20.png
Scalability Principle
21.png
4.大數據系統
大綱
- 大數據系統：Hadoop
- MapReduce，BigTable，GFS三篇Paper
- Spark入門
- 海量數據處理技巧
- 聊天系統設計
- 估算機器
Hadoop 理念的產生
Google三輛馬車
- MapReduce：簡易的數據處理在大型的集群
- Google File System
- BigTable：結構化書分布式存儲
GFS
22.png
- GFS msater 主服務器
- 維護File namespace
- 創建chunk的64位唯一句柄
- 維護GFS到chunk的映射信息，chunk的位置信息
- 整個系統的全局控制，租約的管理，lease
- 垃圾回收
- chunk的復制，備份
- 與chunkserver維持heartbeat
- GFS chunkserver 數據塊服務器
- GFS的文件被劃分為固定大小的數據塊
- GFS client 客戶端
- 首先訪問master節點，獲得chunk handle，chunk locations
- 然后訪問chunkserver，獲得數據
MapReduce
23.png
Big Table
24.png
