mongos
查询与写入操作利用MongoDB的mongos实例在集群中进行路由。从应用程序的角度来看，mongos提供了访问集群的唯一接口。应用程序从不直接跟碎片连接或交互。
mongos从config servers缓存元数据从而追踪哪个数据在哪个碎片上。mongos利用元数据将应用程序和客户端的操作路由到mongod实例上。mongos没有持续的状态并且不怎么消耗系统资源。
练习过程中推荐将mongos实例跟你的应用程序服务器部署在同一个系统上，但你也可以在碎片或其他专用资源上维护mongos实例。
Routing And Results Process
mongos实例通过以下两点在集群里路由查询操作：
- 确定必须回应查询的碎片条目。
- 在所有目标碎片上建立游标。
然后mongos会把每一个目标碎片的数据合并，且返回结果文档。某些查询修饰符(如sorting),会在mongos检索结果之前的上一个碎片上进行以上操作（跟primary shard一样）。
MongoDB3.6以后对于在多碎片上进行的聚合操作，如果不用在数据库的primary shard进行操作，这些操作会被返回到monogs进行合并。
以下两种管道无法运行 mongos：
第一种情况是管道的拆分合并部分包含必须运行在主碎片上运行的阶段时。例如，$lookup操作在一个未碎片化的集合上发出请求，而该集合和一个正在聚合的碎片化集合在同一个数据库，那么该阶段就应该运行在primary shard上。
第二种情况是管道的拆分合并部分包含有可能将临时数据写入磁盘时，例如$group操作符,并且客户端指定了allowDiskUse:true，这种情况下，即使假设没有其他需要在primary shard运行的管道合并阶段，但合并操作会在聚合操作的目标碎片上随机找一个进行。
要获得更多集群聚合查询是如何分割组件的信息，将explain:true作为参数传递给 aggregation() 方法。结果会包含三个json对象。
- mergeType字段表示合并操作在哪个阶段进行(“primaryShard”, “anyShard”, or “mongos”).
- splitPipeline字段表示管道内的哪个操作必须运行在私有碎片上。
- shards字段表示每个碎片已经完成的工作。
在某些情况下，当shard key或者shard key的前缀是查询的一部分，mongs会执行 targeted operation，将查询路由到集群的碎片的子集上。
mongos将不包含shard key的查询操作以广播形式发送，路由到集群里的所有碎片上。取决集群内数据的分布和查询的选择，一些不包含shard key的查询或许依然会对广播进行回应。
mongos如何处理查询操作符
Sorting
如果查询的结果没有排序，mongos实例返回从所有的碎片游标上打开"一系列"的结果游标。
如果使用了游标方法 sort()对查询结果进行了排序，mongos实例将 $orderby选项传递给碎片。数据库的primary shard在通过mongos将数据返回给客户端之前会对结果进行接受和执行合并排序。
Limits
如果使用了游标方法 limit()对结果的大小进行了limits。那mongos实例在将数据返回给客户端前该limit操作传送给碎片然后再将该limit操作重新应用在结果上。
Skips
如果使用了游标方法 skip()跳过了一系列记录，mongos不会将skip操作传递给碎片，而是检索碎片内没有被跳过的记录且当收集结果的时候跳过文档内适当的条目。
当使用 与 limit()方法同时使用时，mongos会将limit()加上skip()的结果传递给碎片以此来提升这些操作的效率。
确保mongos实例连接成功
要确保你的MongoDB实例已经连接上mongos，使用isMaster命令。当客户端连接到 mongos，isMaster会返回一个带有isdbgrid字符串的msg字段。例如:
{
"ismaster" : true,
"msg" : "isdbgrid",
"maxBsonObjectSize" : 16777216,
"ok" : 1,
...
}
相反如果你的应用是连接到mongod，那么返回的文档不会有isdbgrid字符串。
Query Isolation
通常，在碎片化环境下。通过shard key和来自config server的集群元数据，mongos将查询路由到单碎片的查询效率是最高的。 targeted operations使用shard key的值来定位复合查询条件的碎片或者碎片的子集。
对于那些不包含shard key的查询，mongos必须对所有碎片进行查询，然后等待碎片的回应再把结果返回给应用程序。这种"收/发"查询或许需要更长时间才能运行完毕。
Broadcast Operations
除非mongos可以直接确定哪个碎片或者碎片的子集持有查询的数据，否则mongos实例将直接将查询操作广播到所有碎片上。
[图片上传失败...(image-e37c94-1520269344158)]
当mongos收到所有碎片的回应后，会将数据合并并且返回结果文档。集群内的负载决定了广播的效率，例如网络延迟，单个碎片的负载，和每个碎片要返回的文档数量，都能影响广播的性能。
更新多个文档的指令都只进行广播。
updateMany()和 deleteMany()都只能进行广播操作，除非查询条件全额指定为shard key。
Targeted Operations
mongos可以将带有shard key或者shard key作为聚合前缀的查询路由到碎片或者碎片集上。mongs利用shard key值来定位到包含shard key的范围的chunk上并且直接将该查询执行在该chunk的碎片中。
[图片上传失败...(image-38535d-1520269344158)]
例如，如果shard key是:
{ a: 1, b: 1, c: 1 }
mongos可以将包含全部shard key值或者shard key前缀的查询路由到指定碎片或者包含数据的多个碎片上：
{ a: 1 }
{ a: 1, b: 1 }
任何 insertOne()操作都只命中一个碎片。insertMany()里的每个文档都只命中单个碎片，但不保证所有文档都被插入到同一个碎片上。
所有 updateOne(), replaceOne() and deleteOne()操作都必须包含shard key或者_id作为查询条件。否则MongoDB会直接报错。
根据集群里数据的分布和查询的选择，mongos可能依然会对查询进行广播。
Index Use
如果查询条件文档不包含shard key，mongos必然会将该查询以广播形式发送到集群里的所有碎片上。反过来，使用shard key索引或者其他更高效的索引来进行查询。
如果查询包含多个引用了shard key和辅助索引字段的子表达式，mongos会把该查询路由到指定的碎片上并且该索引会令碎片更高效的完成工作。
Sharded Cluster Security
使用 Internal Authentication来确保集群的内部安全和避免未授权用户访问集群。为确保集群内部安全，你必须为每一个mongos和mongod实例配置适当的安全性设置。
集群用户
分片集群支持使用 Role-Based Access Control (RBAC)来限制未授权用户访问和操作集群内的数据。要开启(RBAC)，你必须在启动mongod实例时指定--auth选项（包括config servers在内）。另外，为集群内部开启了 Internal Authentication，MongoDB会自动为你打开RBAC。
如果指定了RBAC，客户端在连接mongos来操作集群的时候，要指定--username,--password和--authenticationDatabase选项。
每个集群的用户是相互独立的，并且这些用户都不能访问集群内的单个碎片。
