基于mongodb的分布式数据库项目（Sharding）系统的高可用是基于什么架构，数据保证和一致性如何？

1. Shard Cluster的架构

Shard cluster由Shard、Mongos和Config server 3个组件构成。

• Mongos是Shard cluster的访问入口，所有的客户端应该都通过Mongos来访问数据库。
• Config Server保存的是整个集群的元数据和配置信息，必须部署成复制集模式。
• Shard是保存实际数据的地方，集合内的数据通过片键均衡到多个shard上，每个shard建议部署成复制集的模式。

Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。

2. Shard Cluster的高可用

• Config server和Shard都是通过MongoDB的复制集（replica set）保证架构的高可用。
• Mongos本身是轻量级的进程，可以部署多个，前置负载均衡，通过负载均衡策略将应用连接分配到合适的mongos上。

Replica set的架构如下：

MongoDB复制集由一组Mongod实例组成，包含一个Primary节点和多个Secondary节点，MongoDB Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持复制集内所有成员存储相同的数据集，提供数据的高可用，Secondary可以对外提供只读操作。

当Primary发生故障后，复制集会选举出新的Primary，客户端Driver自动识别并连接新的Primary节点，保证应用连续性。

3. Shard Cluster的数据一致性

涉及到read preference和write concern两个参数：

• Read Preference

  默认情况下，复制集的所有读请求都发到Primary，Driver可通过设置Read Preference来将读请求路由到其他的节点。

  primary： 默认规则，所有读请求发到Primary
  primaryPreferred： Primary优先，如果Primary不可达，请求Secondary
  secondary： 所有的读请求都发到secondary
  secondaryPreferred：Secondary优先，当所有Secondary不可达时，请求Primary
  nearest：读请求发送到最近的可达节点上（通过ping探测得出最近的节点）

• Write Concern

  默认情况下，Primary完成写操作即返回给客户端确认。

  {w: 0} 对客户端的写入不需要发送任何确认，适用于性能要求高，但不关注正确性的场景
  {w: 1} 默认的writeConcern，数据写入到Primary就向客户端发送确认
  {w: “majority”} 数据写入到副本集大多数成员后向客户端发送确认，适用于对数据安全性要求比较高的场景，该选项会降低写入性能

所以对数据安全一致性要求较高的场景，建议设置w: majority。

在分布式架构中，按照CAP理论
Consistency: 所有读都访问到最新的数据或返回错误
Availability: 每次请求都能获取到非错的响应——但不保证数据是最新
Partition Tolerance: 网络原因造成信息丢失（或延迟）时系统仍能运转

以上三者只能得其二，因此需要根据不同的应用场景，在性能和一致性之间做平衡。