SeanLoiselle,JessicaEdwards翻译|崔英峰策展|云照电脑可以昼夜运行，但早期的网站不能24*7小时运行。现在看来，我们都是不可思议的。但是，在Internet出现之前，并不存在24*7高可用性这一术语。那时我们期待可用性，但我们从没想过这是我们有权要求的东西。我们只在需要时才使用电脑；通常情况下，我们并没有真正有机会使用它们，自然我们也很少让它们开着以便它们可以随时响应我们。随着Internet的发展，以前在当地时间凌晨3点不常见的请求成为世界各地的主要工作时间，因此确保计算机能够处理这些请求变得非常重要。然而，许多系统只依赖一台计算机来处理这些请求——单点故障——我们都知道这是一个糟糕的事实。为了保持正常运行，我们需要在多台能够满足我们需求的计算机之间分配负载。然而，分布式计算有非常明显的优势：特别是同步和对系统内部部分故障的容忍度（容错）。每一代工程师都在迭代这些解决方案以满足时代的需求。很多人不知道数据库领域是如何引入分布式的前因后果，因为这本身就是一个比其他领域发展慢很多的难题。当然，软件会在本地数据库中记录一些分布式计算结果，但是数据库本身的状态只能保存在单机上。为什么？因为跨机器的状态复制是非常困难的。在这篇文章中，我们将了解分布式数据库在历史上是如何处理容错的，以及高可用性是什么样的。此外，我们还将介绍几种不同类型的高可用性系统。高可用数据库有哪些类型？高可用性数据库通常可以分为两类。目前出现了第三类并且越来越普遍：主从数据库：数据库有一个主节点来处理请求，另一个是热备节点（即从节点），一旦主节点出现故障，它将投入使用。Master-masterdatabase：数据库有多个master节点，分别拆分数据写入数据库。多主数据库：数据库至少有3个主节点，它们都可以无冲突地读写集群中的任意数据。什么是主从可用性？主从可用性是指数据库有一个主节点来处理请求，另一个是热备节点（即从节点），一旦主节点出现故障就会投入使用。主从可用性模型基于双节点概念，其中一个节点在将数据复制到其跟随者之前接收所有请求。过去，数据库在一台机器上运行。它只有一个节点并处理所有读写操作。没有“部分失败”这样的事情；数据库要么成功启动，要么失败。单节点数据库的完全不可用对互联网来说是一个双重问题；首先，计算机是24/7全天候访问的，因此停机更有可能直接影响用户；其次，通过让计算机接受不断的访问请求，它们更有可能出现故障。很显然，解决这个问题的办法就是使用多台计算机共同处理请求，这也是分布式数据库起步的契机。生活在单节点世界中，最自然的解决方案是继续让单个节点服务于读写，并将其状态简单地同步到辅助备份机——因此，主从复制诞生了。主从模型是通过即时备份实现高可用性的早期步骤。如果主节点发生故障，您可以简单地将流量引导至从节点，从而将其提升为主节点。只要有可能，您就用一台新的备份机器替换一台宕机的服务器（并希望主节点在此期间不会出现故障）。首先，从主节点到从节点的复制是一个同步过程，即只有从节点确认后才会提交数据转换。但是，不清楚如果从节点发生故障该怎么办。如果备份系统不可用，整个系统宕机当然没有意义——但只要使用同步复制，这种情况就会发生。为了进一步提高可用性，可以改为异步复制数据。虽然它的架构看起来是一样的，但是它能够在不影响数据库可用性的情况下处理主节点或从节点的故障。虽然异步主从模型又向前迈进了一步，但仍然存在一个明显的缺点：当主节点宕机时，任何尚未复制到从节点的数据都可能丢失——即使客户端已经确认数据完全投入。依赖单机处理流量，仍然受限于单机最大可用资源。.对五个九的高可用性的追求扩展到多台机器随着Internet变得无处不在，业务需求的规模和复杂性都在增长。对于数据库，这意味着它们需要能够处理比任何单个节点更多的流量，并且提供“始终在线”的高可用性成为一项任务。鉴于现在大量的工程师都有其他分布式技术的经验，显然数据库可以超越单节点的主从模式，将数据库分布在多台机器上。Sharding同样的，我们可以从调整现有的系统开始，我们的工程师通过开发sharding，将activereplication调整为更具扩展性的架构。在这种情况下，您将集群的数据按某个值拆分，例如行数或主键中的唯一值，并将这些段分布在多个实例中，每个实例都有一组主节点和从节点。然后你在这些实例的集群前面添加一些路由技术，将客户端请求定向到正确的实例进行处理。分片允许您将工作负载分布在多台机器上，通过容忍更多的部分故障和消除单点故障来提高吞吐量和创建更大的弹性。尽管有这些好处，但对系统进行分片很复杂，并且会给团队带来沉重的运营负担。故意对分片进行计数可能会变得非常麻烦，以至于路由最终会渗透到应用程序的业务逻辑中。更糟糕的是，如果您需要修改系统的切片方式（例如架构更改），通常需要大量（甚至是巨大的）工程工作才能实现。单节点主从系统还提供事务支持（即使不是强一致性）。然而，跨分片协调事务的难度是如此微不足道和复杂，以至于许多分片系统决定完全放弃它们。什么是主要可用性？主-主可用性是指数据库至少有两个主节点，它们对数据进行分片并执行对数据库的写入。Master-master可用性代表了从master-slave的演变，通过让集群中的节点提供读写服务，使数据库能够扩展到单台机器之外。考虑到分片数据库难以管理且不完整，工程师着手开发能够至少解决其中一个问题的系统。出现的是一个仍然不支持事务但非常易于管理的系统。随着对应用程序正常运行时间的要求越来越高，帮助团队满足其SLA的决定是明智的。这些系统背后的动机是每个实例节点都可以包含部分（或全部）集群数据并为其提供读写服务。每当一个节点收到写请求时，它会将更改传播到需要它的副本的所有其他节点。为了处理两个节点正在写入同一个密钥的情况，任一节点的转换在被提交之前被馈送到冲突解决算法中。由于每个站点都是“活动的”，因此称为主站点。因为每个服务器都可以读取和写入其所有数据，所以分片更容易通过算法实现，并使部署更易于管理。在可用性方面，大师非常好。如果一个节点发生故障，客户端只需重定向到另一个确实包含数据的节点。只要数据的单个副本处于活动状态，就可以为其提供读取和写入服务。虽然此方案非常适合高可用性，但其设计在一致性和数据正确性方面存在根本问题。因为每个实例节点都可以处理键值写入（也是在故障转移场景中），所以在处理数据时很难保持数据完全同步。该方案通常通过冲突解决算法调解实例之间的冲突，该算法对如何“消除”不一致做出粗粒度的决定。由于解决方案是在事后完成的，在客户端已经收到关于程序的响应之后——理论上已经根据该响应执行了其他业务逻辑——master-master复制很容易在数据中产生异常。然而，考虑到正常运行时间的溢价，停机成本被认为大于潜在异常的成本，因此master-master成为主要的复制类型。大规模正确性共识和多主可用性master-master似乎解决了基础设施面临的主要问题——提供高可用性。但它只是通过丢弃事务来实现，这使得系统在满足强一致性要求方面不太值得信赖。例如，谷歌在其广告业务中使用了一个庞大而复杂的MySQL分片系统，该系统严重依赖于SQL的表达能力来任意查询数据库。因为这些查询通常依赖于二级索引来提高性能，所以它们必须与它们所派生的数据完全一致。最终，系统变得足够大，开始导致MySQL分片出现问题，工程师开始设想如何通过拥有大规模可扩展系统来解决问题，同时提供业务所需的强一致性。master缺乏事务支持意味着它不应该是一个选项，所以他们必须设计一些新的东西。最终，他们用这样一个系统解决了这个问题，一个基于共识复制的系统，可以保证一致性和高可用性。使用共识复制，将写入提议到一个节点，然后复制到其他一些节点。一旦大多数节点确认写入，就可以提交。共识和高可用性这里的关键概念是共识复制是一种介于同步复制和异步复制之间的机制：您可以指定任意数量的节点进行同步，但它们是哪些节点并不重要。这意味着集群可以容忍少量节点宕机而不影响系统的可用性。（关于处理关闭服务器流量等的注意事项）然而，达成共识的代价是它要求节点与其他节点通信以执行写入。虽然您可以采取一些措施来减少节点之间产生的延迟，例如将它们放在同一可用区中，但这是与高可用性的权衡。例如，如果所有节点都在同一个数据中心，它们之间的通信很快，但是如果整个数据中心都离线了，你的服务就不会孤单。将你的节点分布在多个数据中心可能会增加写入所需的延迟，但它可以提高你的可用性，即使整个数据中心都离线，你的应用程序仍然在线。什么是多主机可用性？多主可用性要求数据库至少有三个活动节点，每个节点都可以无冲突地读写集群中的任何数据。CockroachDB实现了GoogleSpanner论文中的大部分内容（值得注意的是，它不需要原子钟），包括共识复制之外的功能，这些功能使可用性更简单。为了描述它的工作原理并将其与master-master区分开来，我们创造了术语multi-masteravailability。Master-Mastervs.Multi-MasterMaster-Master通过允许集群中的任何节点为其键值提供读取和写入服务来实现可用性，但仅在提交写入后才将其接受的更改传播到其他节点。另一方面，多主可用性允许任何节点提供读取和写入服务，但确保大多数副本在写入时保持同步，并且仅提供来自最新版本副本的读取。在高可用方面，master-master只需要一个replica同时用于读写，而multi-master则需要大部分replica在线才能达成共识（这仍然允许系统内部出现部分故障).显然，这些数据库在可用性方面的不同性能源于系统处理一致性的方式不同。mastermaster大部分时间都在努力写数据，但不能保证clients现在或将来都能读取到该数据。另一方面，多主数据库仅在可以保证以后可以以一致的方式读取数据时才接受写入。回顾过去和展望未来数据库复制和可用性在过去30年里取得了长足的进步，现在支持全球部署，感觉它们永远不会不受欢迎。这方面的最初尝试为主从复制奠定了重要基础，但最终，我们需要更好的可用性和更大的规模。在这方面，业界开发了两种主要类型的数据库：master-slave用于专注于快速写入的应用程序，以及multi-master用于需要一致性的应用程序。我们都期待着有一天我们可以利用量子纠缠并转向下一代数据库类型：可管理的分布式数据库。译者介绍崔映峰，51CTO社区编辑，70后程序员，10多年工作经验，长期从事Java开发、架构设计、容器化等相关工作。精通Java，熟练使用Maven、Jenkins等DevOps相关工具链，擅长容器化方案规划、设计和实施。原文链接：https://www.cockroachlabs.com/blog/brief-history-high-availability/
