分布式系统理论
一、 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） 可以保证强一致性。可以用于分布式事务。需要两类进程
需要协调者(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.178linux.com/7905
