如何缩放要求写入一致的数据库？

Question

假设我有一张能节省机票购买的桌子。我需要跟踪，我没有超卖，所以当用户购买一张票时，它需要存储在那个表中，而其他客户需要知道这一点。

现在，假设由于我正在运行的一些升级，这个表可能会被查询和写入太频繁。为了不使连接重载到DB并获得超时所导致的错误，我选择由某些提供程序(例如Azure elastic )将DB放在弹性SQL服务器中。

但是，如果一个用户连接到这个DB的一个实例并写入它，那么DB的其他(副本)如何知道它并防止任何其他客户违反我的约束在其中插入呢？有什么我应该使用的模式吗？复制件是否以某种方式相互交流？

如果这个设置实际上不能解决这个问题，那么可以使用什么模式来解决这样的问题呢？

谢谢

Answer 1

分布式系统的基本折衷是，如果增加需要更新的写入副本的数量，则可以提高可靠性，但增加延迟。另一方面，如果你想减少延迟，你应该减少写副本的数量，以达成共识。

分布式数据库可以通过多种不同的方式进行配置。最简单的方法可能是单主、多从配置。在一个主、多个从配置中，您没有真正的分布式写操作，所有的写入都会传递给主程序，后者是最终的仲裁者。这些从站，也称为读副本，只是周期性地同步它们的数据(周期性复制)，有时是实时的(流复制)。奴隶只作为只读副本工作，以分发只读查询的工作，因此通常允许它们稍微过时。因此，只要在最终提交事务中根据主数据库重新检查所有必需的条件，读/不提交操作就可以处理读副本。单主从-多个奴隶是非常常用的，因为他们是简单的工作，你可以处理它几乎就像非分布式数据库。

另一种常见的方式是多主配置。在多主配置中，写操作需要成功地通过提交事务的主程序数量的一定阈值，才能使整个分布式事务达成共识。在多主配置中，写副本的数量少于主服务器的数量，事务中的读取实际上也必须被分发，每个主服务器可能需要相互检查以确定另一个主服务器是否有较新的数据副本。在大多数情况下，多主安装通常会降低延迟。多主配置的主要优点是在数据/机器丢失的情况下提高可用性/可靠性，而不是性能或可伸缩性。当有多方希望合作但不完全信任对方以维护黄金副本时，也可以使用多主配置，因此每一方都可以持有自己的主副本，并且需要分布式协商一致才能进行交易。

分布式数据库的第三种技术称为切分。分片是一种拥有多个主数据库的技术，但您只需要写入单个数据库服务器就可以达到承诺。切分数据库不是试图达成分布式共识，而是通过查看操作的切分键属性来决定哪个数据库被视为当前操作的主数据库(例如，如果您使用航班号作为切分键，并且您有两个主机，则可以决定所有以as开头的写入将由服务器A决定，以N开头的航班号的所有写入将由服务器B决定)。分片系统的缺点是，您不可能有一个同时需要不同碎片中的数据承诺的操作(这需要协商一致)。

它也可以结合读取副本，多主，和切分。在某些情况下，也有可能有一个系统，可以选择一个奴隶成为一个新的主人，如果系统失去了主人。这种混合配置有各种考虑因素，因为它们结合了方案的优点和缺点，因此需要非常仔细地加以考虑。

在您的特定场景中使用哪一个取决于您想要扩展的确切原因。

Answer 2

您可以：

• 把你的库存分散到你的节点上--航空公司这样做，他们会在每架飞机上分配一些座位来编码共享伙伴或旅行社，这样他们就可以独立运作了。
• 使用补偿策略-如果航班被超卖，你可以补偿一些旅客，让他们晚些时候才能坐满飞机(航空公司有复杂的机型，可以告知他们能够承受的超卖程度，因为超卖成本，但空位成本也很高)。
• 将您的航班分割到不同的节点/数据库--不太可能所有的流量都对同一航班感兴趣:如果扩展的原因是处理所有正在预订的航班的总流量。
• 结合上面的一些

Answer 3

Cassandra(可能是其他分布式数据库)具有可配置的读写一致性级别，允许您选择可用性和数据准确性。背后的思想是CAP定理。

上限定理指出，分布式数据存储不可能同时提供以下三种保证中的两种以上；

• 一致性:每次读取都会收到最新的写入或错误。
• 可用性:每个请求都接收一个(无错误)响应，而不保证它包含最近的写入。
• 分区容忍度:尽管网络在节点之间丢弃(或延迟)任意数量的消息，系统仍继续运行。

我们不能放弃CAP定理下的划分容限

您可能需要设计数据模型以防止最终的一致性。假设您可以在单个实例Redis(支持不同的数据结构，如sets)中提供票证，并在更加分布式的数据库技术中跟踪票证历史。

请查看有关CAP定理的链接

卡桑德拉仲裁文件