在这一系列博客文章中，我将介绍一些跨地理位置分散的高可用性参考架构解决方案。 ###问题 如今，当企业计划新的服务或应用程序时，他们担心确保高可用性是非常普遍的。 如果我们谈论网上商店，网上银行或大型组织的内部服务并不重要。我们知道用户将期望24x7x365全天候访问服务。他们还希望能够一致且即时地访问数据。如果我们未能满足他们的期望，那么他们会转移到另一家提供商，我们就会亏钱。就那么简单。 提供在线服务和应用程序的另一个重要方面是，每天生成，分析和存储的数据量都在增长。我们今天从昨天的几千兆字节转移到太字节。谁知道我们明天需要多少PB？ 曾经被单个LAMP堆叠覆盖的东西，今天可能需要几十个L，A，与字母P（如J，R，Py，G）和M不同. 我们心爱的MySQL曾经“足够”覆盖我们的12年前的需求，但并不适合许多现代应用的所有需求。 在不同级别和活动的不同方面使用不同类型的“存储”的应用程序是很常见的。我们可以使用键值存储来缓存操作，并使用完整的ACID数据库来获取“有价值的”核心数据（必须一致且持久的数据类型）。大数据存储在最终一致的列存储机制中，而长期数据存储在某些“大数据”方法中。 最重要的是报告机制，它收集每个数据存储的元素，以提供所需的全面数据图像。 情况非常多样化和复杂，可能的变量数量很多。我们将它们结合起来的方式是如此巨大，以至于现在开发人员没有限制，并且经常提出创造性的解决方案。 这是我们作为架构师可以提供帮助的地方：我们可以阐明每个工具如何用于正确的JOB。 我们Percona坚信，我们必须在复杂性上寻求简单性，并采用 方拥抱亲吻的方式。这是从对工作的正确工具的最初识别开始的。 **让我们从以下示例中的以下良好实践开始：** 如果您需要定义实体之间的关系以及它们之间的规则，那么使用键值存储并不是一个好主意。 当您必须保存有关客户付款的货币信息时，请避免使用最终一致的存储。 使用关系数据库实时存储HTML缓存，页面跟踪信息或游戏信息不是最佳做法。 使用正确的工具来完成正确的工作。有些工具可以更好地扩展写入并保持最终一致的方法。其他一些旨在存储难以置信的数据量，但无法处理关系。因此，处理典型的OLTP请求时可能需要很长时间 - 如果它们可以的话。 每个工具都有不同的设计和目标，每个工具都有不同的扩展方式，每个工具都有自己的处理方式和可用性。 这是项目架构阶段的一个关键部分，不要混淆卡片。保持整洁，为每个组件建立正确的体系结构。然后将它们以最终结果和谐的方式结合起来。我们应该用简单的答案来解决复杂问题。 我们离老LAMP架构有多远？很久很久。这就像转过头来看着我们的祖先建造第一个帐篷。如果你想露营，帐篷仍然是一个有效的解决方案。但这只是为了娱乐，而不是为了日常生活。 关于关系数据库应该做什么以及它应该如何做，往往会产生混淆。关系数据库不应该取代宽体系结构的每个其他组件，反之亦然。他们必须共存并与其他选择一起工作。每个人都应该最大化其特征并尽量减少其局限性。 在本系列中，我们将重点介绍RDBMS，并为关系数据库层提供一些可能的参考体系结构。我将说明提高服务可用性的解决方案，重点关注工具的设计和关于ACID范例的关系数据方法。 **这意味着采用以下简单规则：** 原子性 - >所有操作，同一事务的一部分，要不全部成功或全部不成功。 一致性 - >所写的任何数据必须根据定义的规则及其组合进行有效/验证。 隔离性 ->保证所有事务都将单独发生。没有事务影响任何其他事务。 耐久性 ->耐久性意味着，一旦一个事务被提交，即使系统紧接着发生系统崩溃，它也将保留在系统中。事务更改必须永久存储。 我们将讨论涉及最常见的开源RDBMS的解决方案，包括内部部署和云端： MySQL PostgreSQL MongoDB 该方案对所有解决方案都是通用的，但我们实施解决方案的方式将满足不同的需求。（下一篇）第一个是MySQL的高可用性：基于地理分布的场景。 翻译原文：https://www.percona.com/blog/2018/11/15/reference-architectures-for-high-availability-solutions-in-geographic-distributed-scenarios-why-should-i-care/