分布式系統理論
一、 CAP: 分布式系統只能夠，滿足其中兩個?
1.?Consistency ：?all nodes see the same data at the same time
一個節點修改后，需馬上復制到第二個節點。如果網絡故障，第二個節點將不能同步第一個節點更新的數據。這就是不能滿足一致性。
2.?Availibility：a guarantee that every request receives a response about whether it succeeded or failed
如果數據沒有同步時，兩個節點都可以訪問，這就是可用性。如果想保證一致性需要第二個節點枷鎖，那么在沒有同步之前將不能訪問第二個節點，這就滿足不了可用性。 所以可用性和一致性，只能保證一個。 大部分系統滿足的是可用性，而非一致性。
3.?Partitions Tolerance ： The system continues to operate despite arbitrary partitioning due to network failures
分布式系統一都滿足
C,A ： SQL 傳統的數據庫。 兩段機制。
C,P ：悲觀枷鎖機制，分布式加鎖機制。加鎖機制與SQL不太一樣。 這里的C為最終一致性。 放棄C后的特例，既可以保證可用性，也可以保證最終一致性。
A,P ： 只保證分區容錯和可用性，例如 DNS
二、數據一致性：
1. 強一致性，無論在哪個節點上修改，其他節點必須馬上看到
2. 弱一致性：存在某一個不一致狀態的時間段。 存在不一致性窗口。有可能兩個節點始終不一致
3. 最終一致：弱一致性的特例，可以略過中間態直接保證最后狀態一致。
4.?數據一致性的實現技術：?
1) Quorum系統NRW策略： 法定票數
R ： 為了完成一次讀操作最少需要的副本數
W： 為了完成一次寫操作最少需要的副本數
N：總共擁有的副本數
強一致性： R + W > N
弱一致性： R + W < = N 最多只能保證最終一致性。
MySQL 一主兩從： 寫需要一個， 讀需要一個， 1 + 1 < 3 弱一致性
2) 兩段式提交： 2PC（2 Phase Commit Protocol） 可以保證強一致性?？梢杂糜诜植际绞聞铡Ｐ枰獌深愡M程
需要協調者(coodinator )
事務參與者
第一段： 請求階段，協調者邀請所有參與者可以提交，并確定參與者都同意提交
第二段： 提交階段， 協調者通知所有參與者可以提交，于是同時提交。
3) 時間戳策略
????????????Paxos算法
????????????向量時鐘（vectors clock）
三、事務 (transaction)
????ACID：
Atomicity:?requires that each transaction be “all or nothing”: if one part of the transaction fails, the entire transaction fails, and the database state is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes. To the outside world, a committed transaction appears (by its effects on the database) to be indivisible (“atomic”), and an aborted transaction does not happen.
原子性： 需要每次事務操作要只有“有” 或“無”兩種狀態： 如果一部分事務操作失敗，那么整個事務操作失敗，結果數據庫狀態保持操作之前的狀態不變。原子性系統必須保證在任何情況下（包括斷電，程序錯誤，系統崩潰）， 對于外界來看，遞交一次事務時不可以拆分的，并且中斷的事務時不存在的。
Consistency：?The?consistency?property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules, including?constraints,?cascades,?triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined rules.
一致性： 一致性保證任何事物都可以將數據庫從一個合法狀態轉換成另一個合法狀態。 所有數據庫的寫入必須符合事先設立的條件，包括約束，級聯，觸發，或者所有的組合。 這個雖然無法保證程序員編程時都是正確的，但是至少可以保證編程錯誤不能違背設定好的條件。
Isolation：The?isolation?property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other. Providing isolation is the main goal of?concurrency control. Depending on concurrency control method (i.e. if it uses strict – as opposed to?relaxed?– serializability), the effects of an incomplete transaction might not even be visible to another transaction.
隔離性： 隔離特性保證同時進行事務操作產生的系統狀態結果與序列操作相同。 隔離性的主要目標就是并發控制。由于并發控制，不完整事務將不存在。
Durability： Durability?means that once a transaction has been committed, it will remain so, even in the event of power loss,?crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a?non-volatile memory.
持久性： 持久性意味著一旦事務遞交，將會被保持，即便斷電，宕機，錯誤。 例如在關系性數據庫中，一旦一組SQL語句執行以后，結果將會被永久保存（即便數據庫在執行后馬上被崩潰）。 為了避免斷電，事務必須存放在非易失性存儲內存中。
BASE：用于對分布式系統的評估
Basically Available :This constraint states that the system does guarantee the availability of the data as regards CAP Theorem; there will be a response to any request. But, that response could still be ‘failure’ to obtain the requested data or the data may be in an inconsistent or changing state, much like waiting for a check to clear in your bank account.
Soft state:?The state of the system could change over time, so even during times without input there may be changes going on due to ‘eventual consistency,’ thus the state of the system is always ‘soft.’
Eventually Consistent:?The system will?eventually?become consistent once it stops receiving input. The data will propagate to everywhere it should sooner or later, but the system will continue to receive input and is not checking the consistency of every transaction before it moves onto the next one.
NoSQL數據庫存儲模型
NoSQL數據庫介紹
最早出現于，1998， 具有不提供SQL接口的關系型數據庫， NoREL
2009, NoSQL , 在亞特蘭大，分布式開源系統的討論，
1. 非關系型
2. 分布式
3. 不提供ACID（Atonic, Consistency,Isolated, Durability ）功能
NoSQL 的技術特點
1. 簡單數據模型， 每個記錄就是一個唯一的鍵
2. 元數據和應用數據分離。 元數據用于系統管理，需要專門的元數據管理節點
3. 弱一致性，支持最終一致性
NoSQL的優勢
1. 避免不必要的復雜性，比較適用于web2.0的應用場景
2. 高吞吐量。 google每天吞吐量為幾十個pb
3. 高水平擴展能力， 低端硬件集群，PC服務器集群就可以滿足
4. 不適用對象關系映射。數據模型比較簡單
NoSQL 劣勢
1. 數據模型和查詢語言沒有經過數學模型驗證。
2. 不支持ACID特性。
3. 功能過于簡單。
4. 沒有統一的數據查詢模型。
NewSQL ： SQL 和 NoSQL的中間產品
1.?把SQL和ACID引入到分布環境中，Clustrix, GenieDB, ScaleArc, ScaleBase, NimbusDB，MySQLcluster
2. 改變SQL架構，不用進行水平擴展就可以實現大規模性能提升。
數據庫分類：?
? ?一、?NoSQL
1. 鍵值存儲（key-value）： 無法描述復雜的數據結構
memocache: 只能描述簡單結構
redis : 可以存儲復雜一些的模型
優點查找迅速O(1)
缺點，數據無結構，只能當做字符串和二進制數據。
場景： 主要用于內容緩存。memocahced, redis
主要用于大數據高訪問負載， 或者日志緩存
事例： Redis, Dynamo（亞馬遜）
??2. 列式數據庫： 按列進行管理，分成列族進行管理，將列族分別運行于不同的節點上。
數據模型： 數據案列存儲， 將統一列數據存在一起，同一個節點上或者同一個數據集中
優點： 查找迅速， 可擴展性比較強，易于實現分布式
缺點： 功能相對有限
應用場景： 主要用于分布式文件系統或者分布式存儲 ,海量數據存儲，背后依托分布式文件系統
實例： Google bigTable, facebook Cassandra ,hadoop HBase, Hypertable
?3. 文檔數據庫： 存儲數據時，把每一行，當做一個實體來管理。 每一行都帶有字段的名稱。可以單獨加減字段。
數據模型： 與鍵值模型類似，但是value指向結構化數據，一個鍵可以多個值。多個鍵值對附加了一個容器。鍵值可以嵌套。
優點： 數據格式要求不嚴格，無需事先定義格式。 所有記錄不需要擁有相同的字段，可以單獨臨時增加。 每一個文檔理論上可以不需要和其他文檔有任何關系。
缺點： 查詢性能不高，比起SQL還是很好的， 缺乏統一查詢語法。
應用場景： 主要用于web應用。
實例： MongoDB, ?CounchDB
?4. 圖存數據庫： 存儲圖，關系網絡圖。廣泛應用于社交網絡應用。
數據模型： 圖結構模型
有點： 利用圖結構相關算法提高性能，滿足特殊場景的應用需求。 例如，社交網站的推薦模型
缺點： 難以實現分布式，功能相對定向，只能適用于特定場景。
使用場景： 社交網絡，推薦系統，關系圖譜
實例： Neo4J
? ? 二、SQL?
1. 商業數據庫
2. 開源數據庫
?? ?三、緩存數據庫系統：?
memocached
MongoDB
一、MongoDB相關介紹
1. Scalable, high performace, open source, schema free, document no-sql oriented database.
2. 適合存儲，Humongous( huge + monstrous)
3. Document Database ： JSON, BSON 存儲格式
4. Schema free
5. High performance
C++: 開發
Full index support : 支持完全索引
No transactions (has atomic operations)： 不支持事務
Memory-mapped files (delayed writes)?： 操作在內存中完成，而后同步硬盤
6. Scalable：
Replication : 復制
Auto-sharding: ?分片
7. Document-based queries: 支持基于文檔的查詢, 可以返回一個文檔，或者一個游標指向結果集
Flexible document queries expressed in JSON/Javascript : 支持json, javascript的表達式
8. Map/Reduce
Flexible aggregation and data processing : 靈活數據聚合
Queries run in parallel on all shards： 在各shard上面并行進行
9. 支持GridFS存儲文件系統
10. Store files of any size easily ： 可以用于存儲各種大小文件的文件系統 ，海量小文件
11. Geospatial Indexing: 支持空間索引
Find object based on location （find closes n items from x ）
12. Many Production Deployment : 商業化應用還算廣泛。
13. Dynamic queries ： 動態查詢
14. Query profiling ： 支持查詢性能剖析
15. Replication and fail-over support： 能夠復制并且自動完成故障節點轉移，通過選舉協議自動選舉出主節點。
16. 特別適用于：
Websites : 高并發，
Caching：通常用redis， Hbase
High volume, low value ：海量低價值數據
High Scalibility ：
Storage of program objects and json ： 始于json對象開放的場景，多為web開發
17. 不適用應用：
Highly transactional ： 需要使用事務
Ad-hoc business intelligence ： 商業決策
Problems requiring SQL ： 需要SQL接口
二、MongoDB 數據結構
面向collection的數據庫 ：
數據庫：數據庫無需創建
表：在mongodb中為集合(collection)， collection中為文檔對應傳統的行
集合： 集合也無需事先定義
三、 幾個數據庫的性能比較
memcached： 性能很好，擴展性也很好，但是只能存儲key-value簡單的數據結構，不能存儲
redis： 性能比memcached略低，但是可以存儲復雜一些key-value，支持字典，列表等， 可以存儲在硬盤上
MongoDB： 功能上大大跨出一步。
??RDBMS（關系型數據庫）： 功能上很強，性能和擴展性上很差
四、 安裝
支持rpm包安裝
支持通用二進制文件安裝
五、 CRUD操作
MongoDB 以Documents的形式存儲數據，格式類似JSON鍵值對，BSON是JSON的二進制形式。MongoDB把所有的Documents存儲在collections中，從長公用一些索引鍵。collections 類似于關系型數據庫中的表。通?？梢詧绦械牟僮魅缦?。
C: insert()
R: find()
U: update()
D: remove()
Create, Read, Update, Delete
collection?樣例
{
????name:"sue"
????age:26
????status:?"A"
????groups:?["news","sports"]
}
1.?Read:
2. Write:
Write Concern: Write Concern決定了什么時候報告寫完成
1） Acknowleged: Mongod 確認接到寫命令。
2）Unacknowleged: Mongod 自行處理寫命令，如果發上網絡錯誤也不會告知
3） Journaled: Mongod 先記錄寫日志，然后報告寫命令收到，這一選項可以保證忽然斷電后可以通過日志恢復
4）Replica acknowleged：確認副本都接到寫操作后，報告受到寫操作
原子性和事務
1）MongoDB的原子性操作， 是以每一個頂層Document為單位。
2） 使用$isolated 使一個操作多個Document的操作相互隔離。
3） 類事務支持（Transaction Like Semantics）: 使用類Two phase commit。 這樣可以確保數據的一致性，但是程序可能讀到中間值。
六、索引
索引的優點：
1. 大大的減少了服務器需要掃描的數據量。
2. 索引可以幫助服務器減少排序或臨時表的使用。
3. 實現索引訪問，可以將隨機I/O轉換為順序I/O
指定是搜索鍵，成為順序I/O，后期如果尋找行的其他地方信息，還是需要通過指針回到原行。
索引的缺點：
1. 要存儲一部分內容。
2. 修改后，索引也要修改。
3. 索引與查找鍵匹配才有意義 。
4. 數據量過大，索引也會喪失意義。
索引：三星級別
一顆星： 如果能將相關的記錄放在一起， 降低I/O隨機I/O變為順序I/O。
二顆星： 索引中的數據的存儲順序與查找標準中順序一致。
三顆星： 如果索引中包含了，查詢中所需要的所有數據，成為覆蓋索引。索引中已經包含了所要查找的內容。
索引的類別：
1. 順序索引：
2. 聚集索引：?數據次序與對應的搜索鍵引對齊存放排序，稱為主索引，如果按照索引鍵查找，不需要二次I/O。按照聚集索引的數據文件，也叫作索引順序文件。
3. 非聚集索引： 搜索鍵順序與記錄文件順序不一致存放，
順序索引有效場景：
4. 全值匹配：
匹配最左前綴：
匹配列前綴：組合前綴(name, Age), Name = “user12″ 有效， 而 Age > 80 無效
匹配范圍值
精確匹配某一列， 并范圍匹配另外一列。
只訪問索引的查詢
5. 稠密與稀疏
稠密索引：根據索引中為每個記錄都創建了索引項， 查詢比較快
稀疏索引：沒有為所有記錄創建索引項，只為搜索鍵中的某些鍵值創建索引項，節省內存
只有主索引才可以稀疏
6. 多級索引：
索引指向索引，只有到最后一級才能到數據。
根索引數據量會變小，但是性能會很差。于是產生了B+樹索引
B+書索引：
1.?外層索引的每一個鍵指向下一層索引某一個開頭處
2. 最后一級指向數據磁盤塊的位置
3. 對于B+書來說，每一個葉子節點到根節點的距離相同。
4. 索引層級根據數據量大小動態生成。 必要時可以自動分裂(fan out)或收縮(fan in)層次。少于n/2 ~ n 則收縮
5. 順序索引 ，外層稀疏，內層稠密
7. 主索引與輔助索引：
主索引只能有一個，為聚集索引。
輔助索引必須是稠密索引。
8. 散列索引（harshed ）： 把索引映射至散列桶（bukets）中, 映射通過散列函數進行。
散列索引可以避免訪問索引結構。但是有可能產生偏斜。
需要散列函數：
分布均勻
分布隨機
哈希索引使用場景：
精確匹配： =， IN()
9. 全文索引： fulltext 中的關鍵字，
mysql 中使用sphinx, lucense實現
10. 空間索引： 必須使用空間索引函數獲取相應的查找結果。
11. ?主鍵：唯一鍵
mongodb索引類型：
1. 單鍵索引（single）：
1）簡單單鍵索引
2） 嵌套字段子字段索引：使用”.”表示嵌套關系，db.people.createIndex( { “address.zipcode”:1})
3）?嵌套字段整個索引：把嵌套字段里面的子字段作為整體索引，搜索時，必須子字段順序一致，索引才有效。
2.復合索引（Compound index）：
1）關于索引的順序
????????????db.events.find().sort(?{?username:?1,?date:?-1?}?)
????????????“－1”?代表倒序
????????????“1”???代表正序
3.多值索引（multikey index）：某一字段為數組 。
1）如果建立index的字段是一個數組，則將會自動建立為multikey
2）不允許把兩個數組同時創建為compound index
3）多值索引不能做為sharding key
4）多值索引不能創建為sharshed 索引
5）多值索引不支持覆蓋搜索
6） 也可以通過制定數組中的字段來創建多值索引例如
????????????db.inventory.createIndex(?{?"stock.size":?1,?"stock.quantity":?1?}?)
4. 空間索引：空間索引查詢只能使用空間索引函數。
1） spherical ：根據地球精度為度來建立索引
2） Flat： 在一個平面上面根據絕對位置建立索引
5. 文本索引： 全文索引，支持字符串匹配來查找。
1） 支持字段通配：對于非結構化數據，不清楚哪個字段需要建立索引時，可以根據字段統配，把可以通配的字段都建立成索引
????????????db.collection.createIndex(?{?"$**":?"text"?}?)
????????????此時，所有統配到的字段里面的文字信息，會被當作一個索引
2） 統配后的字符串字段索引，可以與其它字段做成符合索引
????????????db.collection.createIndex(?{?a:?1,?"$**":?"text"?}?)
3） 字符串索引可以自動取出冠詞如（a, an, the etc.）
4)?? 如果創建了字符串索引，不可以使用hint()查詢
5）如果常見字符串索引，則不可以使用排序命令
6. 哈希索引： 支持手動創建哈希索引。
1） harsh 索引不支持compond key
2）harsh 索引不支持范圍查找
3）可以把同一field 同時創建為harsh索引和排序索引，用于精確匹配和范圍匹配
評估索引的標準：
1. 訪問類型：等值查找，散列索引較好，范圍查找順序索引較好
2. 訪問時長：
3. 插入時長：插入新數據，需要更新索引 。
更新散列索引，很簡單，只要添加特定的散列桶
更新順序索引，需要挪動整個索引
4. 刪除時長：
5. 空間開銷：
六、副本集架構
1. master—slave: master 負責讀寫，slave 只能讀（不建議使用）
2.復制集架構(replica set)基本概念：
副本及成員：
1. 主節點（primary node）： 接受讀寫，操作通過選舉產生
2. 從節點（second node）：保存一個副本
1） 優先級為0的從節點（Priority 0 Replica Set）: 存儲一個副本，參與選舉，但是不能被選舉。只能讀不能寫。
2） 隱藏節點（Hidden Replica）: 儲存一個副本，參與選舉，不能被選舉，不能被程序看見，所以不讀也不寫，只是保存副本用于特定工作，例如做備份等工作。
3） 滯后節點（Delay Replica）： 與隱藏節點類似，但是存儲的是一個時間段以前的信息，例如1小時以前的信息，用于回滾備份。
3. arbiter 節點： 沒有副本只參與投票
副本構架策略：
1. 副本數量策略（Deploy an Odd Number of Members）：使得選舉可以正常進行，如果沒有使用arbiter節點
2. 考慮添加容錯節點（Consider Fault Tolerance）： 容錯數是指，多少個節點掛掉，其他還能正常選舉出主節點的機制。詳見官方文檔。
3. 使用隱藏節(hidden Replica, Delay Replica)點和滯后節點用于特殊功能（backup or reporting）
4. 把讀取壓力很大的需求負載均衡到多個從節點上（Load Balance on Read-Heavy Deployments）: 當負載沒那么大時候，可以收回
5. 在目前節點節點壓力沒有完全飽和時添加新的節點。 （Add Capacity Ahead Demand）
節點的地理分布（Distribution of Members）
1. 要地理分布節點到不同個數據中心，以防某個中心掛掉
2. 使得大部分節點集中存放，使得選舉不會受到網絡影響
3. 給操作打標（Target Operations with Tag Set）
啟動日志功能，防止意外服務中斷。例如斷電
副本集的高可用:
1. 選舉行為（Replica Set Elections）:
選舉因素：
Heartbeats: 心跳信息
Priority Comparisons: 優先級選擇
Optime: 最有時間時間戳，選擇擁有最近更新時間戳的節點
Connections: 可以與大部分節點通信的優先
Network Partitions：如果主節點宕機，但是從節點很分散不在同一個數據中心，則有可能從節點全都變成只讀模式，所以建議大部分節點放在同一個數據中心中
選舉觸發條件：
新增節點(initiation of new replica set)
從節點與主節點不能通信
主節點宕機
選舉優先權（Vetoes In Elections）: 沒有選舉權(Vetoes)的節點，不可以選舉，但可以被選舉為主節點。通常副本節點可以最多50個但是，可以選舉的只有7個，剩下的不參與選舉但是可以被選為主節點
2. 副本及崩潰時的回滾機制（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的數據，則需要人工干預
副本集的讀寫機制： 對于客戶端來說，副本集存在與否是完全為知的。
1. 副本集寫操作規則（Write Concern for Replica Sets）
默認寫規則： 默認寫規則只寫入主節點
修改默認寫規則：
????????cfg?=?rs.conf()
????????cfg.settings?=?{}
????????cfg.settings.getLastErrorDefaults?=?{?w:?"majority",?wtimeout:?5000?}
????????rs.reconfig(cfg)
用戶也可以通過副本集標簽來自定義寫規則
2. 副本集讀偏好規則（Read Preference）：
primary: 默認選項，因為主節點存放最新寫入的內容
primaryPreferred：大多是情況從主節點讀取，如果主節點讀取不到則通過從節點讀取。
secondary：所有的讀操作都可以從從節點讀取.
secondaryPreferred：有限使用從節點讀取。
nearest：從網絡等待時間(latency)最短的節點讀取
不建議使用從節點讀取來增加讀性能，建議使用shard增加讀性能。
3. 副本集節點的讀取挑選機制（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的距離。
4. 復制過程（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構架的介紹
1.?應用場景：
大數據量，并且高吞吐量數據時
高并發查詢，使得單臺服務器CPU壓力過大
數據量過大，一臺服務器無法存放
操作數據量過大，內存壓力和I/O壓力過大
如果系統已經接近極限時，再使用shard會變得比較困難， 如果在可預見的將來系統將會被使用到極限，則最好盡快使用shard
2. 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
3. Shard Keys 相關
Range Based Sharding： 范圍分區,優點是讀取時容易鎖定在有限個shard上，但是寫入時有可能集中在某一個shard。
Hash Based Sharding: 哈希算法分區，優點是寫入分散，缺點是讀取時有肯能信息分散在所有shard上，會降低讀性能。
Shard keys 不能改變。
選擇sharding key 的標準
1） 應該在哪存數據
2）?應該在哪的到希望的數據
4. 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的工作機制
1. Shard Collection Balancing：
基本法則
讀數據盡可能來自于少的分片，寫數據盡可能分離，最差寫情況讀的時候根本不知道在哪個分片上，全shard掃描
shard key 應該是主鍵，查詢時候經常用到的鍵。
同時選擇分片鍵時候，盡量避免跨分片查詢
分片時候，盡量先垂直切割，避免熱區數據。然后再水平切割
chunk 64 默認
分片越小越容易遷移。
rebalance功能可以使得不均衡的分布變得均衡
sharding:新增shard,移除shard
mongo的監控命令：
mongodump
mongorestore
mongoexport
mongoinport
mongodb mapreduce
mongodb GridFS
原創文章，作者：以馬內利，如若轉載，請注明出處：http://www.www58058.com/7905
