相关阅读：【小目标，一个“译”】+ 双活应用架构与MongoDB的实现（1）分区（分片）数据库分区数据库将数据库分成不同的分区，或称为分片。每个分片由一组服务器来实现，而每个服务器都包含一份分区数据的完整副本。这里关键在于每个分片都保持着对数据分区的独有控制权。对于任何给定时间内的每个分片来说，由一台服务器充当主服务器，而其他服务器则充当其副本。数据的读取和写入被发布到主数据库上。如果主服务器出于任何原因的（例如：硬件或网络故障）失败，则某一台备用服务器会自动接任为主服务器的角色。数据库中的每条记录都属于某个特定的分区，并由一个分片来进行管理，以确保它只会被主分片进行写入。分片内的记录映射到每个分片的一个主分片，以确保一致性。由于集群内包含多个分片，因此会有多个主分片（多个主分区），因此这些主分片可以被分配到不同的数据中心，以确保都在每个数据中心的本地都能发生写入操作。分片数据库可用于实现双活的应用架构，其方法是：至少部署与数据中心一样多的分片，并为分片分配主分片，以便每个数据中心至少有一个主分片。另外，通过配置分片能保证每个分片在各种数据中心里至少有一个副本（数据的副本）。例如，有跨三个数据中心的分布式数据库架构：纽约（NYC），伦敦（LON）和悉尼（SYD）。群集有三个分片，每个分片有三个副本。· NYC分片在纽约有一个主分片，在伦敦和悉尼有副本
· LON分片在伦敦有一个主分片，在纽约和悉尼有副本
· SYD分片在悉尼有一个主分片，在伦敦和纽约有副本
通过这种方式，每个数据中心都有来自所有分片的副本，因此本地应用服务器可以读取整个数据集和一个分片的主分片，以便在其本地进行写入操作。分片数据库能满足大多数使用场景的一致性和性能要求。由于读取和写入发生在本地服务器上，因此性能会非常好。从主分片中读取时，由于每条记录只能分配给一个主分片，因此保证了一致性。例如：我们在美国的新泽西州和俄勒冈州有两个数据中心，那么我们可以根据地理区域（东部和西部）来分割数据集，并将东海岸用户的流量路由到新泽西州的数据中心，因为该数据中心包含的是主要用于东部的分片；并将西海岸用户的流量路由到俄勒冈州数据中心，因为该数据中心包含的是主要用于西部的分片。我们可以看到分片的数据库为我们提供了多个主数据库的所有好处，而且避免了数据不一致所导致的复杂性。应用服务器可以从本地主服务器上进行读取和写入，由于每个主服务器拥有各自的记录，因此不会出现任何的不一致。相反，多主数据库的解决方案则可能会造成数据丢失和读取的不一致。数据库架构比较每一种数据库架构在满足双活应用需求时所存在的优缺点。在选择多主数据库和分区数据库时，其决定因素在于应用是否可以容忍可能出现的读取不一致和数据的丢失问题。如果答案是肯定的，那么多主数据库可能会稍微容易部署些。而如果答案是否定的，那么分片数据库则是最好的选择。由于不一致性和数据丢失对于大多数应用来说都是不可接受的，因此分片数据库通常是最佳的选择。
数据库架构
| 读取与写入
| 副本
| 性能
| 一致性
|
分布式事务
| 本地进行读取
全局写入
| 不需要。
读取发生在分布式事务中
| 慢
需要进行跨数据中心的两步式提交
| 满足一致性
|
多主数据库
| 本地进行读取与写入
| 最终保持一致性
| 快
| 可能出现数据丢失、读取不一致，但最终能保持一致性
|
分片
| 本地进行读取与写入
负责写入的数据流被路由到具有管理角色的数据中心
| 最终保持一致性
| 快
| 对本片区的写入能保持一致性
通过读取来自其他数据中心的数据，能最终保持一致性
|
MongoDB双活应用MongoDB是一个分片数据库架构的范例。在MongoDB中，主服务器和次服务器集的构造被称为副本集。副本集为每个分片提供了高可用性。一种被称为区域分片（Zone Sharding）的机制被配置为：由每个分片去管理的数据集。如前面说提到的，ZoneSharding可以实现地域分区。白皮书《MongoDB多数据中心部署》（https://www.mongodb.com/collater ... ation&jmp=dzone-ref）和Zone Sharding相关文档（https://docs.mongodb.com/manual/ ... g-data-by-location/）的“分区（分片）数据库”部分描述了MongoDB具体实现和运作的细节。其实许多组织，包括：Ebay、YouGov、Ogilvyand Maher都正在使用MongoDB来实现双活的应用架构。除了标准的分片数据库功能之外，MongoDB还提供对写入耐久性和读取一致性的细粒度控制，并使其成为多数据中心部署的理想选择。对于写入，我们可以指定写入关注（write concern）来控制写入的持久性。Write concern使得应用在MongoDB确认写入之前，就能指定写入的副本数量，从而在一个或多个远程数据中心内的服务器上完成写入操作。籍此，它保证了在节点或数据中心发生故障时，数据库的变更不会被丢失。另外，MongoDB也补足了分片数据库的一个潜在缺点：写入可用性无法达到100％。由于每条记录只有一个主节点，因此如果该主节点发生故障，则会有一段时间不能对该分区进行写入。MongoDB通过多次尝试写入，大幅缩短了故障切换的时间。通过多次尝试的写入操作，MongoDB能够自动应对由于网络故障等暂时性系统错误而导致写入失败，因此也大幅简化了应用的代码量。MongoDB的另一个适合于多数据中心部署的显着特征是：MongoDB自动故障切换的速度。当节点或数据中心出现故障或发生网络中断时，MongoDB能够在2-5秒内（当然也取决于对它的配置和网络本身的可靠性）进行故障切换。发生故障后，剩余的副本集将根据配置去选择一个新的主切片和MongoDB驱动程序，从而自动识别出新的主切片。一旦故障切换完成，其恢复进程将自动履行后续的写入操作。对于读取，MongoDB提供了两种功能来指定所需的一致性级别。首先，从次数据进行读取时，应用可以指定最大时效值（maxStalenessSeconds）。这可以确保次节点从主节点复制的滞后时间不能超过指定的时效值，从而次节点所返回的数据具有其时效性。另外，读取也可以与读取关注（ReadConcern）相关联，来控制查询到的返回数据的一致性。例如，ReadConcern能通过一些返回值来告知MongoDB，那些被复制到副本集中的多数节点上的数据。这样可以确保查询只读取那些没有因为节点或数据中心故障而丢失的数据，并且还能为应用提供一段时间内数据的一致性视图。MongoDB 3.6还引入了“因果一致性（causal consistency）”的概念，以保证客户端会话中的每个读取操作，都始终只“关注”之前的写入操作是否已完成，而不管具体是哪个副本正在为请求提供服务。通过在会话中对操作进行严格的因果排序，这种因果一致性可以确保每次读取都始终遵循逻辑上的一致，从而实现分布式系统的单调式读取（monotonic read）。而这正是各种多节点数据库所无法满足的。因果一致性不但使开发人员，能够保留过去传统的单节点式关系型数据库，在实施过程中具备的数据严格一致性的优势；又能将时下流行架构充分利用到可扩展和具有高可用性的分布式数据平台之上。【原标题】Active-ActiveApplication Architectures With MongoDB (作者: Jay Runkel
)原文链接： https://dzone.com/articles/active-active-application-architectures-with-mongohttps://dzone.com/articles/active-active-application-architectures-with-mongo-1
