MongoDB架构概览
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB等同于分布式的MySQL。它把一个Table，按row，分割成多个Shards，分别存放在不同的Servers上。这种说法是否正确？
不深入了解MongoDB的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
图1-1 MongoDB架构图
MongoDB通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称mongos）。
Shards
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个collection数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
Sharding的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
Shard keys
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
如前所述，在MongoDB数据库中，一个表collection由多个行documents组成，而每个document，有多个属性fields。同一个collection中的不同的documents，可能会有不同的fields。例如，有个collection叫Media，包含两条documents，
{
}
{
}
假如，在同一个collection中的所有document，都包含某个共同的field，例如前例中的“ISBN”，那么我们就可以按照这个field的值，来分割collection。这个field的值，又称为shard key。
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key的选择，与使用场景密切相关。
很多情况下，无论选择哪一个单一的field作为shard key，都无法均匀分割collection。在这种情况下，我们可以考虑，用多个fields，构成一个复合的shard key。
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用author作为shard key，显然无法均匀切割collection。这时我们可以加上release-date，组成name-date的复合shard key，例如“王二2011”。
Chunks
MongoDB按shard key，把collection切割成若干chunks。每个chunk的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2所示。
图1-2 chunk的三元组
其中，collection是数据库中某一个表的名称，而minKey和maxKey是shard key的范围。每一个document的shard key的值，决定了这条document应该存放在哪个chunk中。
如果两条documents的shard keys的值很接近，这两条documents很可能被存放在同一个chunk中。
Shard key的值的顺序，决定了document存放的chunk。在MongoDB的文献中，这种切割collection的方式，称为order-preserving。
一个chunk最多能够存储64MB的数据。 当某个chunk存储的documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它shard中。
这里有个问题，假如某一条document包含的数据量很大，超过64MB，一个chunk存放不下，怎么办？在后续章节介绍GridFS时，我们会详细讨论。
Replica set
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes)请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
Config Server
Config servers用于存储MongoDB集群的元数据metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些collections的哪些documents。
每一个config server都包括了MongoDB中所有chunk的信息。
Config server也需要replication。但是有趣的是，config server采用了自己独特的replication模式，而没有沿用replica set。
如果任何一台config server挂了，整个config server集群中，其它config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的config servers中，出现元数据不一致的情况。
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
Mongos
用户使用MongoDB时，用户的操作请求，全部由mongos来转发。
当mongos接收到用户请求时，它先查询config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些shard servers。当这些shard servers完成操作后，它们把结果分别返回给mongos。而当mongos汇总了所有的结果后，它把结果返回给用户。
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当config server中的元数据有改动，它都会通知所有的mongos。
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
Reference，
[0] Architectural Overview
http://www.mongodb.org/display/DOCS/Sharding+Introduction
MongoDB架构概览
