分布式系統理論
1、 CAP: 分布式系統只能滿足其中兩個?
- Consistency ：一致性
- Availibility：可用性
- Partitions Tolerance ：分區容錯性
C,A ： SQL 傳統的數據庫。 兩段機制。
C,P ：悲觀枷鎖機制，分布式加鎖機制。加鎖機制與SQL不太一樣。 這里的C為最終一致性。 放棄C后的特例，既可以保證可用性，也可以保證最終一致性。
A,P ： 只保證分區容錯和可用性，例如 DNS
2、數據一致性：
2.1 強一致性，無論在哪個節點上修改，其他節點必須馬上看到
2.2 弱一致性：存在某一個不一致狀態的時間段。 存在不一致性窗口。有可能兩個節點始終不一致
2.3 最終一致：弱一致性的特例，可以略過中間態直接保證最后狀態一致。
2.4 數據一致性的實現技術：
1)Quorum系統NRW策略： 法定票數
R ： 為了完成一次讀操作最少需要的副本數
W： 為了完成一次寫操作最少需要的副本數
N：總共擁有的副本數
強一致性： R + W > N
弱一致性： R + W < = N 最多只能保證最終一致性。
2)??2PC
3)Paxos算法
4)?vectors clock（向量時鐘）
三、事務 (transaction)
????ACID：
?A: 原子性： 需要每次事務操作要只有“有” 或“無”兩種狀態： 如果一部分事務操作失敗，那么整個事務操作失敗，結果數據庫狀態保持操作之前的狀態不變。原子性系統必須保證在任何情況下（包括斷電，程序錯誤，系統崩潰）， 對于外界來看，遞交一次事務時不可以拆分的，并且中斷的事務時不存在的。
? C: 一致性： 一致性保證任何事物都可以將數據庫從一個合法狀態轉換成另一個合法狀態。 所有數據庫的寫入必須符合事先設立的條件，包括約束，級聯，觸發，或者所有的組合。 這個雖然無法保證程序員編程時都是正確的，但是至少可以保證編程錯誤不能違背設定好的條件。
I:隔離性： 隔離特性保證同時進行事務操作產生的系統狀態結果與序列操作相同。 隔離性的主要目標就是并發控制。由于并發控制，不完整事務將不存在。
D:持久性： 持久性意味著一旦事務遞交，將會被保持，即便斷電，宕機，錯誤。 例如在關系性數據庫中，一旦一組SQL語句執行以后，結果將會被永久保存（即便數據庫在執行后馬上被崩潰）。 為了避免斷電，事務必須存放在非易失性存儲內存中。
BASE：用于對分布式系統的評估
最終弱一致性，可用性優先，采用樂觀的方法，適應變化，更簡單，更快
NoSQL數據庫存儲模型
NoSQL數據存儲模型
列式模型：
數據模型： 數據案列存儲， 將統一列數據存在一起，同一個節點上或者同一個數據集中
優點： 查找迅速， 可擴展性比較強，易于實現分布式
缺點： 功能相對有限
應用場景： 主要用于分布式文件系統或者分布式存儲 ,海量數據存儲，背后依托分布式文件系統
典型產品： Google bigTable, facebook Cassandra ,hadoop HBase, Hypertable
鍵值模型（key-value）：
應用場景： 內容緩存。用于處理大量并行數據高訪問高負載場景
優點：查找迅速
缺點，數據無結構，只能當做字符串和二進制數據。
典型產品： Redis, Dynamo（亞馬遜），Riak
文檔模型：
數據模型： 與鍵值模型類似，但是value指向結構化數據，一個鍵可以多個值。多個鍵值對附加了一個容器。鍵值可以嵌套。
優點： 數據格式要求不嚴格，無需事先定義格式。 所有記錄不需要擁有相同的字段，可以單獨臨時增加。 每一個文檔理論上可以不需要和其他文檔有任何關系。
缺點： 查詢性能不高，比起SQL還是很好的， 缺乏統一查詢語法。
應用場景： 主要用于web應用。
典型產品： MongoDB, ?CounchDB，RethinkDB
圖式模型：
數據模型： 圖結構模型
優點： 利用圖結構相關算法提高性能，滿足特殊場景的應用需求。 例如，社交網站的推薦模型
缺點： 難以實現分布式，功能相對定向，只能適用于特定場景。
應用場景： 社交網絡，推薦系統，關系圖譜
典型產品： Neo4J，Infinite Graph
MongoDB
一、MongoDB相關介紹
- Scalable, high performace, open source, schema free, document no-sql oriented database.
- 適合存儲，Humongous( huge + monstrous)
- Document Database ： JSON, BSON 存儲格式
- Schema free
- High performance
C++: 開發
Full index support : 支持完全索引
No transactions (has atomic operations)： 不支持事務
Memory-mapped files (delayed writes)?： 操作在內存中完成，而后同步硬盤
- Scalable：
Replication : 復制
Auto-sharding: ?分片
- Document-based queries: 支持基于文檔的查詢, 可以返回一個文檔，或者一個游標指向結果集
Flexible document queries expressed in JSON/Javascript : 支持json, javascript的表達式
- Map/Reduce
Flexible aggregation and data processing : 靈活數據聚合
Queries run in parallel on all shards： 在各shard上面并行進行
- 支持GridFS存儲文件系統
- Store files of any size easily ： 可以用于存儲各種大小文件的文件系統 ，海量小文件
- Geospatial Indexing: 支持空間索引
Find object based on location （find closes n items from x ）
- Many Production Deployment : 商業化應用還算廣泛。
- Dynamic queries ： 動態查詢
- Query profiling ： 支持查詢性能剖析
- Replication and fail-over support： 能夠復制并且自動完成故障節點轉移，通過選舉協議自動選舉出主節點。
- 特別適用于：
Websites : 高并發，
Caching：通常用redis， Hbase
High volume, low value ：海量低價值數據
High Scalibility ：
Storage of program objects and json ： 始于json對象開放的場景，多為web開發
- 不適用應用：
Highly transactional ： 需要使用事務
Ad-hoc business intelligence ： 商業決策
Problems requiring SQL ： 需要SQL接口
二、MongoDB 數據結構
面向collection的數據庫 ：
數據庫：數據庫無需創建
表：在mongodb中為集合(collection)， collection中為文檔對應傳統的行
集合： 集合也無需事先定義
三、安裝
這里就不過多介紹
/etc/yum.repos.d/mongodb-org-3.2.repo [mongodb-org-3.2] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.2/x86_64/ gpgcheck=0 enabled=1
四、副本集架構
1.master/slave:主從架構，master 負責讀寫，slave 只能讀（不建議使用）
2.復制集架構(replica set)基本概念：
副本及成員：
- 主節點（primary node）： 接受讀寫，操作通過選舉產生
- 從節點（second node）：保存一個副本
1） 優先級為0的從節點（Priority 0 Replica Set）: 存儲一個副本，參與選舉，但是不能被選舉。只能讀不能寫。
2） 隱藏節點（Hidden Replica）: 儲存一個副本，參與選舉，不能被選舉，不能被程序看見，所以不讀也不寫，只是保存副本用于特定工作，例如做備份等工作。
3） 滯后節點（Delay Replica）： 與隱藏節點類似，但是存儲的是一個時間段以前的信息，例如1小時以前的信息，用于回滾備份。
3.arbiter 節點： 沒有副本只參與投票
副本構架策略：
- 副本數量策略（Deploy an Odd Number of Members）：使得選舉可以正常進行，如果沒有使用arbiter節點
- 考慮添加容錯節點（Consider Fault Tolerance）： 容錯數是指，多少個節點掛掉，其他還能正常選舉出主節點的機制。詳見官方文檔。
- 使用隱藏節(hidden Replica, Delay Replica)點和滯后節點用于特殊功能（backup or reporting）
- 把讀取壓力很大的需求負載均衡到多個從節點上（Load Balance on Read-Heavy Deployments）: 當負載沒那么大時候，可以收回
- 在目前節點節點壓力沒有完全飽和時添加新的節點。 （Add Capacity Ahead Demand）
節點的地理分布（Distribution of Members）
- 要地理分布節點到不同個數據中心，以防某個中心掛掉
- 使得大部分節點集中存放，使得選舉不會受到網絡影響
- 給操作打標（Target Operations with Tag Set）
啟動日志功能，防止意外服務中斷。例如斷電
副本集的高可用:
- 選舉行為（Replica Set Elections）:
選舉因素：
Heartbeats: 心跳信息
Priority Comparisons: 優先級選擇
Optime: 最有時間時間戳，選擇擁有最近更新時間戳的節點
Connections: 可以與大部分節點通信的優先
Network Partitions：如果主節點宕機，但是從節點很分散不在同一個數據中心，則有可能從節點全都變成只讀模式，所以建議大部分節點放在同一個數據中心中
選舉觸發條件：
新增節點(initiation of new replica set)
從節點與主節點不能通信
主節點宕機
選舉優先權（Vetoes In Elections）: 沒有選舉權(Vetoes)的節點，不可以選舉，但可以被選舉為主節點。通常副本節點可以最多50個但是，可以選舉的只有7個，剩下的不參與選舉但是可以被選為主節點
- 副本及崩潰時的回滾機制（Rollbacks During Replica Set Failover：當宕機的主節點恢復時，由于數據和從節點不同步，原主節點回滾回與其它節點相同的狀態。 MongoDB會盡量避免回滾，因為回滾意味著丟失原主節點最新寫進的操作。
回滾數據的收集： 回滾數據存放在dbPath下面rollback/目錄中格式如下
<database>.<collection>.<timestamp>.bson
##?例如
records.accounts.2011-05-09T18-10-04.0.bson
使用：?bsondump工具讀取回滾數據，使用mongorestore來恢復到新的主節點中。
避免數據回滾：提高 write concern {w:1} 級別來避免回滾，使用 w:majority 來確定，所有數據在第一時間同步到從節點。
回滾限制： 默認不得回滾超過300M以上的數據，如果需要回滾大于300M的數據，則需要人工干預
副本集的讀寫機制： 對于客戶端來說，副本集存在與否是完全為知的。
- 副本集寫操作規則（Write Concern for Replica Sets）
默認寫規則： 默認寫規則只寫入主節點
修改默認寫規則：
cfg?=?rs.conf()
cfg.settings?=?{}
cfg.settings.getLastErrorDefaults?=?{?w:?“majority”,?wtimeout:?5000?}
rs.reconfig(cfg)
用戶也可以通過副本集標簽來自定義寫規則
- 副本集讀偏好規則（Read Preference）：
primary: 默認選項，因為主節點存放最新寫入的內容
primaryPreferred：大多是情況從主節點讀取，如果主節點讀取不到則通過從節點讀取。
secondary：所有的讀操作都可以從從節點讀取.
secondaryPreferred：有限使用從節點讀取。
nearest：從網絡等待時間(latency)最短的節點讀取
不建議使用從節點讀取來增加讀性能，建議使用shard增加讀性能。
- 副本集節點的讀取挑選機制（Read Preference Process）:
讀節點選擇標準：如果選擇讀取非主節點的偏好，可供讀取成員節點的選擇規則（Member Selection）如下
1）列入所有可用成員節點，參考節點成員類型（從節點，主節點，或者所有成員節點）
2）如果使用了標簽，則去除標簽（tag）不能匹配的節點
3）選擇可用節點中絕對距離最近的節點。
4）建立一個ping距離表，選擇絕對最近的節點
5）隨機選擇
申請關聯鏈接（Request Association）：節點選擇完畢后，申請與節點建立關聯關系。由于不同節點之間數據會略有差異，所以讀取偏好確定后，就會和某一個節點建立關聯，保證讀取的數據連續。這個關系在一下三種情況下會被打破。
1） 應用選擇另一個節點作為讀取偏好
2） 連接斷開
3） 客戶端收到套接字斷開。原因可能是網絡故障，服務器連接錯誤觸發重試，這些對于客戶端來說都是不可見的。
自動重試：
1） 客戶端盡可能長的使用同一連接。
2） 如果連接斷開則，使用以后的讀節點偏好（read preference modes）連接一個新節點。
3） 如果嘗試在同一讀寫偏好條件下連接三個節點都失敗，則返回錯誤信息。
4） 如果檢測到宕機信息，驅動會快速刷新副本集信息。
對于shard集群的讀取偏好：
1） 對于shard的副本集，規則和普通副本集類似。
2） 不指定偏好的鏈接，默認為primary
3）計算距離是從mongos到mongod的舉例而不是客戶端到mongod的距離。
- 復制過程（Replication Processes）
副本集操作日志（Replica Set Oplog）
1） Oplog Size：根據系統有默認值，但是可以通過oplogSizMB 指定， 64-bit Linux 為5%可用空間。
2） Oplog Status: 通過rs.printReplicationInfo() 查看oplog狀態
副本集同步Replica Set Data Synchronization
1） 初始化同步（Initial Sync）：同步所有源數據到一個空的副本主機中。
復制整個數據庫，執行源數據庫的修改，建立所有的索引
2）復制（Replication）：初始化同步以后，接連不斷的同步后續的操作到副本中。
3） 合法性和持久存儲
4） 多線程復制
5） 提前獲取索引來提高復制的通量。
副本集配置：
配置參數：
replSet: 副本集名稱
oplogSize： 操作日志大小，初始化為磁盤可用空間的5%。第一次初始化后，將以后無法更改。 最好開始指定。
fastsync： 完成快速同步。
replIndexPrefectch：副本索引預取。
選舉觸發：
一個新節點剛剛上時，不能馬上觸發選舉，過一段時間以后才會觸發。
優先級為0的節點，不能觸發選舉，沒有被選舉權，只能選舉發生時參與選舉
七、sharding構架
sharding構架的介紹
- 應用場景：
大數據量，并且高吞吐量數據時
高并發查詢，使得單臺服務器CPU壓力過大
數據量過大，一臺服務器無法存放
操作數據量過大，內存壓力和I/O壓力過大
如果系統已經接近極限時，再使用shard會變得比較困難， 如果在可預見的將來系統將會被使用到極限，則最好盡快使用shard
- sharding三部分：
Shards： 分片存儲的數據，為了保證High Availablility 和 data consistency， 每個shard建議被做成副本集
1）Primary Shard ： 可以存儲沒有分片的collection
2）Shard Status： sh.status() 用于查看shard的整體狀態
Query Routers: mongos服務， 直接與客戶端交互的，代理客戶從shard上面讀取數據組合后返回給客戶端。
1）可以使用一個或多個。
2） 如果使用多個，需要前端負載均衡，或者反向代理。需要配置前端代理保證每一個客戶端的鏈接只能鏈接同一個mongos
Config servers:??存儲集群元（metadata）數據用于把整體數據映射到各shard的中。
1）生產環境中最好使用三個做冗余。并且是單獨主機，如果是多組shard集群，則每個集群一組Config Server
- Shard Keys 相關
Range Based Sharding： 范圍分區,優點是讀取時容易鎖定在有限個shard上，但是寫入時有可能集中在某一個shard。
Hash Based Sharding: 哈希算法分區，優點是寫入分散，缺點是讀取時有肯能信息分散在所有shard上，會降低讀性能。
Shard keys 不能改變。
選擇sharding key 的標準
1） 應該在哪存數據
2）?應該在哪的到希望的數據
- shard 集群的高可用：生產環境下的shard集群是沒有單點故障的。
mongos部分： 每個程序可以擁有獨立的mongos, 某一個mongos不可用不會影響數據完整。
shard mongod部分：
1） 如果shard mongod 為主節點，則重新選舉一個主節點。
2） 如果shard mongod 為從節點，并與主節點斷開，但是仍然可以保存所有數據
3） 如果某一個節點毀滅性損壞，另外兩個節點依然會保存著所有數據。
shard 副本相關： 如果某個shard副本整個損壞， 則這部分shard數據全部不可以訪問。另外的shard還可以訪問
Config server相關：
1） 如果一個或兩個不可用，則只能讀不能做片分離和片移動
2） 如果全部不可用，則不可恢復。
重命名Config server 相關：
1） 如果命名或地址改變。必須重啟mongod 和 ?mongos
2）盡量使用DNS名來避免主機名改變的麻煩。
shard key相關:
1）盡可能確保key可以使得數據分布均勻。
2）可以分攤寫壓力
3） 可以使mongos把大部分的讀操作定位在有限個shard上面。
shard的工作機制
- Shard Collection Balancing：
基本法則
讀數據盡可能來自于少的分片，寫數據盡可能分離，最差寫情況讀的時候根本不知道在哪個分片上，全shard掃描
shard key 應該是主鍵，查詢時候經常用到的鍵。
同時選擇分片鍵時候，盡量避免跨分片查詢
分片時候，盡量先垂直切割，避免熱區數據。然后再水平切割
chunk 64 默認
分片越小越容易遷移。
rebalance功能可以使得不均衡的分布變得均衡
sharding:新增shard,移除shard
mongo的監控命令：
mongodump
mongorestore
mongoexport
mongoinport
mongodb mapreduce
mongodb GridFS
原創文章，作者：nene，如若轉載，請注明出處：http://www.www58058.com/90990
