我正在开发一种去中心化的日历系统。它应该将数据保存在每台设备上，并在它们都具有互联网连接时进行同步。我的第一个想法是，仅使用关系数据库并尝试在连接后同步数据。但是理论上说的还有别的。 The Brewers CAP-Theorem描述了其背后的理论，但我不确定该定理是否过时。如果我使用该定理，则将拥有“ AP [可用性/分区容差]系统”。 “ A”是因为我在任何给定时间都需要我的日历数据，而“ P”是因为它可能发生，因此设备之间没有连接，并且数据无法同步。示例数据库为CouchDB，RIAK或Cassandra。我只使用关系数据库，现在不知道如何进行。在我的项目中使用关系数据库是否很糟糕？
这是为了我的学士论文。我只是想开始使用Postgres，但后来我发现了这个定理... 整个项目基于Java。
答案 0 :(得分：0)
我认为CAP定理实际上对您的情况没有帮助。处理分区的分布式系统需要决定当一个部分想要对数据进行修改时要做什么，而不能到达另一部分。一种解决方案是使写入等待-这是由于“分区”而放弃了“可用性”，这是CAP定理提出的选项之一。但是还有更多有用的选项。最有用（高度可用）的选项是允许两个部分都独立编写，并且在重新连接时调和。问题是如何做到这一点，并且不同的分布式系统选择不同的方法。
某些系统，例如Cassandra或Amazon的DynamoDB，使用“最后写入者获胜”-当我们看到两次冲突的写入之间存在冲突时，最后一次（根据某个同步时钟）获胜。为了使这种方法有意义，您需要非常谨慎地建模数据（例如，注意冲突解决导致两种状态无效混合的情况）。
在其他系统中（以及在Cassandra和DynamoDB中，在其“集合”类型中），写操作仍然可以独立地发生在不同的节点上，但是解决冲突的方法更为复杂。一个很好的例子是Cassandra的“列表”：一个可以发送更新，说“将项目X添加到列表”，而另一个更新则说“将项目Y添加到列表”。如果这些更新发生在不同的分区上，则稍后可以通过在列表中添加X和Y来解决冲突。诸如此列表之类的数据结构-允许以某种方式在两个节点上独立地修改内容，然后以明智的方式自动对其进行调节，因此称为Conflict-free Replicated Data Type（CRDT）。
最后，在亚马逊的Dynamo论文中使用了另一种方法（不要被其当前的DynamoDB服务所迷惑！），称为“矢量时钟”：当您要写入对象（例如购物车）时，首先读取对象的当前状态，并附带一个“矢量时钟”，您可以将其视为所获取数据的“版本”。然后，您进行修改（例如，向购物车中添加商品），并写回新版本，同时说出您最初使用的是旧版本。如果其中两个修改在不同分区上并行发生，则我们以后需要协调两个更新。矢量时钟使系统可以确定一个修改是否比另一个修改“新”（在这种情况下，没有冲突），或者它们确实确实存在冲突。并且当它们这样做时，将使用特定于应用程序的逻辑来解决冲突。在购物车示例中，如果我们看到冲突是，在一个分区中将项目A添加到购物车中，而在另一个分区中，将项目B添加到购物车中，最直接的解决方案是将时间A和B到购物车。
您可能应该选择其中一种方法。只说“ CAP定理不允许我这样做” ；-)实际上，在某些方面，您面临的问题与我所遇到的某些系统不同提到。在那些系统中，常见的情况是每个节点始终保持连接（无分区），并且延迟非常短，因此他们希望这种常见的情况能够更快。在您的情况下，您可能会得出相反的结论：两个部分通常不连接，或者如果连接，则等待时间较长，因此解决冲突是因为是规范而非例外。因此，您需要决定如何解决此冲突-如果在一个设备上添加一个会议而在另一台设备上添加另一个会议（很可能将两个会议都保存为两次...）会发生什么，您怎么知道一个设备修改了一个预先存在的会议，并且没有添加第二个会议（向量时钟？唯一的会议ID？等等），因此冲突解决最终解决了现有会议的问题，而不是添加第二个会议？等等。完成此操作后，将数据存储在两个分区上（客户端和服务器中的数据库实现可能完全不同），并且将更新发送给哪个协议将成为实现详细信息。
还有另一个问题需要考虑。我们何时进行对帐？在上面我列出的许多系统中，对帐是在读取时进行的：如果客户端要读取数据，并且我们突然在两个可到达的节点上看到两个冲突的版本，我们就会进行对帐。在日历应用程序中，您需要一种稍微不同的方法：客户端可能仅在未连接时尝试读取（使用）日历。当他与他人保持联系以调和所有差异时，您需要利用难得的机会。此外，您可能需要“推送”更改-例如，如果服务器上的数据已更改，则可能需要告知客户端“嘿，我有一些更改的数据，请调和”，因此最终用户将立即例如，您可以看到有关新会议的公告，该公告是远程添加的（例如，可能由共享同一日历的其他用户）。您将需要弄清楚如何进行此操作。再次，没有像“使用Cassandra”这样神奇的解决方案。