从小白到架构师 | 六张图弄清楚数据库复制的各种架构 ...

在已往的二十年里，由于分布式数据库的使用越来越广泛，数据库复制的概念也得到了发展。然而，其核心原则大要上没有太大变革。
在本文中，我们将讨论数据库复制的相关事项。
什么是数据库复制？

数据库复制是指将相同数据的多个副本保存在不同的数据库服务器（也叫副本或实例）中的过程。这样，如果某个数据库服务器出现问题，其他服务器仍然可以继承为用户提供数据服务。这种方式能够进步体系的性能、可用性和可靠性。
想象一下，一个公司把紧张的文件复印了好几份并放在不同的地方，这样纵然其中一份丢失了，其他地方还有备份，工作也不会受到影响。数据库复制就像这种“复印”的过程，只不过过程复杂很多。

假设有一家在线市肆，它只有一个数据库服务器，存储了所有与产物、订单和客户相关的数据。如果由于某些原因（硬件问题、软件问题等），这台数据库服务器发生故障，整个网站将不可用，这对于用户来说是绝对不可担当的。
为了办理这个问题，我们可以使用数据库复制。网站所有者可以设置多个数据库服务器，从主数据库服务器复制数据。如果主服务器宕机，其他从服务器可以接管并继承处理哀求。
如果我们的数据不会随时间变革，那么数据库复制过程非常简单：我们只需将数据复制到每个节点一次即可。数据库复制的所有难点都在于如何处理复制数据的变革。
基于不同架构的数据库复制技术

确保对一个节点上的数据所做的任何更新都能反映到所有其他节点上黑白常紧张的。因此，我们需要一些技术手段来确保所有节点拥有最新的数据。
有三种类型的数据库复制技术：单主复制、多主复制和无主复制。每种类型的复制技术都有其优缺点。
单主复制架构

这种架构也被称为主从复制或主动-被动复制。在单主复制中，只有一个主节点（向导者/master），可以有多个从节点（跟随者/slave）。所有写哀求由主节点处理，所有读哀求由主节点或从节点处理。最好的做法是只使用主节点处理写哀求，将读哀求分配给从节点，以减轻主节点的负担。

对于写哀求，主节点在处理完写哀求后，会将数据更改的操纵以某种情势（如MySQL中以binlog日志）发送给从节点，以更新从节点对应的数据。
这种方法比较简单，但由于主节点只有一个，如果主节点故障，体系可能在选出新主节点之前变得不可用。
在复制过程中，我们需要处理一个关键问题：复制过程可能存在延迟（复制延迟），如何尽量减少这种延迟？
这种架构在读写比非常高的情况下是一个不错的选择。
多主复制架构

前面提到了数据库单主复制架构存在的一个大问题：如果主节点由于某种原因不可用，我们无法在升级另一个从节点副本为主节点之前执行写操纵。
办理该问题的常见方法是使用多主复制。这也被称为主-主复制或主动-主动复制。
在这种架构下，存在多个主节点，客户端可以将写哀求发送给任一主节点，每个主节点同时也是其他主节点的从节点。因此，每当主节点执行写操纵时，它同时会将数据更改流转发给所有其他主节点。

多主复制架构提供了冗余，纵然体系中一个主节点发生故障，体系仍然可用，由于还有其它的主节点可以处理写哀求。
但多主复制架构也带来了一些复杂性。例如，当两个或多个主节点同时收到辩说的写哀求时，可能会出现辩说。因此，必须有辩说办理机制来确保数据同等性。
无主复制架构

这也被称为无向导复制。在这种架构中，客户端将写哀求发送给多个节点，并行地从多个节点读取。在这种方法中没有向导者的概念，这答应任何副本直接担当客户端的写操纵。
无向导复制可以提供高可用性和容错性。由于没有单点故障，纵然某些节点发生故障，体系也可以继承运行。它还可以提供高读写吞吐量，由于读写哀求都可以分摊到多个节点上处理。
然而，这种方法在同步方面存在挑战，由于很难确保所有节点始终拥有相同的数据视图。此外，处理并发写入引发的辩说也非常复杂，需要精心计划以确保数据同等性。
下面举个栗子来资助我们明白这种架构。
假设你和几个朋友一起在线合作编写一本书，每个人都有这本书的副本，都可以在本身的副本中添加内容或修改现有的文本。
在这个项目中，任何人都可以随时对书的内容进行修改，并且这些修改会被同步到其他人那里。比如你在家里写了一段新的内容，你的朋友在他的电脑上也会主动收到这段内容的更新。
如今，如果你的电脑突然坏了，或者你临时失去了网络连接，其他朋友的工作不会受到影响，他们依然可以继承编辑书的其他部分。这是由于大家都有各自的副本，没有单一的中央点或“向导”节点。如果某个节点（某个人）出问题，体系仍然可以继承正常运行。
由于每个人都可以独立地进行编辑，整个团队可以并行工作，效率很高。你在修改第3章的内容时，你的朋友可以同时在第7章添加新的段落，互不干扰。
前面提到的数据同步带来的挑战是：如何确保所有人手里的书都是最新版本？如果你和你的朋友同时修改了同一个章节，那么当你们的修改内容同步时，体系必须决定哪一方的修改会被保存。比如，你写的内容是“在这个故事中，主角是一个勇敢的骑士。”而你的朋友同时写的是“在这个故事中，主角是一个聪明的魔法师。” 当这两段内容同步时，体系就需要做出决定：是选择保存“骑士”还是“魔法师”？
同步复制和异步复制

同步复制

在同步复制中，一旦主节点更新了其自身的数据，它会将数据更新操纵同步给从节点：从节点接收数据更新操纵并执行更新，然后将确认发送给主节点。一旦主节点收到所有从节点简直认，它才会相应客户端，整个数据更新过程才算成功。

同步复制确保从节点始终与主节点保持数据同步和同等，从而具有容错性。纵然主节点崩溃，由于从节点包罗全部的数据。体系可以轻松地将任何一个从节点提升为新的主节点，并继承正常运行。
想象一下，你在网上购买商品时，体系需要在库存数据库中减少一件商品。在同步复制的情况下，体系会确保所有副本数据库都更新了库存数目后，才会告诉你购买成功。这确保了无论哪个数据库在查询，库存数目都是同等的。
但是这种方式由于主数据库需要等候从数据库简直认，这可能会导致体系相应时间变慢，尤其是在网络延迟较高的情况下。
异步复制

在这种计谋中，主节点在更新完其自身的数据后就立即相应客户端，而无需等候更新操纵传播到从节点。这种方式效率高，但存在数据丢失的风险，由于对客户端的相应是在复制过程之前已经发出。复制过程是在背景进行的，主节点异步地将更改传播给从节点。如果主节点节点崩溃，未传播的数据更改将永久丢失。而且这种数据丢失客户端并不知情，只有线上出了bug才可能知道。
还是以上面购物的场景作为例子。在异步复制的情况下，体系在你下单后立即减少主数据库中的库存数目，然后就确认购买成功，但其它副本的数据可能稍后才更新。如果在这个过程中你恰恰从副本数据库中查询库存，可能会看到旧的数据（比如显示库存还有，但现实上已经没有了）。

尽管存在这一缺点，但异步复制是大多数数据存储的默认的复制计谋，由于它的效率高。
如何选择

同步复制实用于对数据同等性要求非常高的场景，比如金融体系或订单管理体系，虽然性能会有所牺牲。
异步复制实用于对性能要求高但对数据同等性要求稍低的场景，比如社交媒体应用或内容分发网络，这种方式可以提供更快的相应速度。
数据库复制的特点

数据库复制的优点

• 数据库复制资助我们扩展能够提供读写查询的机器数目，从而增加吞吐量，并答应并行处理更多的查询哀求。
  
• 它可以资助我们将数据保存在地理上接近用户的位置，从而减少延迟。最好的例子是CDN。
  
• 如果某个数据库服务器被自然灾害摧毁，数据仍然得以保存。我们不需要担心数据丢失，由于数据在多个位置复制。
  
• 通过在不同的数据库服务器之间复制数据，纵然数据库服务器因维护或其他原因宕机，网站仍然可以正常运行。
  

数据库复制的缺点

• 在多个服务器之间复制数据会增加数据库体系的复杂性。
  
• 维护复制体系可能会很昂贵，由于它需要额外的硬件、软件和IT资源。
  
• 当对主数据库进行的更改未立即传播到从数据库时，这可能导致不同实例之间的数据不同等。
  
• 当在不同的数据库实例中对相同数据进行更改时，可能会发生数据辩说。如果未正确办理辩说，可能会导致数据不同等乃至数据丢失。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。