Erlang 容错应用：CAP 的 PA 还是 CA？

Posted 2023-03-15

【中文标题】Erlang 容错应用：CAP 的 PA 还是 CA？

【英文标题】：Erlang fault-tolerant application: PA or CA of CAP?

【发布时间】：2012-08-17 04:33:12

【问题描述】：

我已经向question 询问了一个用于披萨外卖店的简单容错软实时 Web 应用程序。

我在那里得到了非常好的 cmets 和答案，但我不同意它是一个真正的 Web 服务。它不是一个网络服务，它更像是一个实时系统，用于接受客户的订单，控制这些订单的调度，并控制实时交付这些订单的车辆。

此外，与“真正的”网络服务不同，该系统并不打算拥有很多用户 - 它只是几个调度员（电话接线员）和几个送货司机将使用它（目前我没有要求为实际客户提供对服务的直接访问；只有调度员和送货司机才能直接访问）。

因此这个问题比较笼统。

我发现，为了为此应用程序的 NoSQL 数据存储选项做出正确选择，我必须做的第一件事是根据CAP theorem.

现在，Building Web Applications with Erlang 的书说“虽然它 [Mnesia] 不是 SQL 数据库，但它是一个类似于 SQL 数据库的 CA 数据库。它不会处理网络分区”。同一本书说 CouchDB 数据库是PA 数据库。

考虑到这一点，我认为我需要对我的应用程序做的第一件事是确定“容错”一词对于 CAP 的含义。

我的简单要求是让应用程序 24/7(R1) 可用。另一个是不需要扩展，应用程序的用户数量非常有限（可能不可能有数千个调度程序）（R2）。

现在，R1 是否要求应​​用程序提供一致性、可用性和分区容错性以及哪些优先级？

哪种类型的数据存储选项会更好地处理以下问题：

为调度员（接听客户电话并使用 CRM 的人员）提供 24/7 全天候服务，以查找客户记录并将订单输入系统； 实时查看当前正在进行的服务订单及其状态（下达、烘焙、派送、交付、交付）； 实时跟踪所有工作车辆的位置及其有效载荷； 在系统崩溃或网络崩溃后恢复系统的任何部分以继续提供 1,2 和 3；

总结一下：哪种数据存储（CA、PA 或 CP）更适合上述系统？什么样的数据存储能更好地满足 R1 的要求？

【参考方案1】：

首先，不要将 CAP“可用性”与“高可用性”混淆。他们彼此没有任何关系。 CAP 中的 A 仅表示“所有数据库节点都可以回答查询”。要获得高可用性，您必须在多个数据中心中，您必须拥有用于维护、扩展等的可靠记录程序。这些都不取决于您的 CAP 选择。

其次，对您的要求要实事求是。股票交易应用程序可能需要 100% 的正常运行时间，因为每一秒的停机时间都可能损失数百万美元。另一方面，我猜你的比萨店每倒下一分钟就会损失几十美元。因此，花费数百万美元来维持它是没有意义的。尝试计算您的实际成本。

第三，始终评估您的选择与主流。当问题发生时，您可以只使用 CA (mysql) 并快速故障转移到从属服务器。对建立新技术的成本（和风险）持现实态度。如果您真的希望您的系统可以运行 5 年而不会停机，请要求提供其他人已经运行该数据库 5 年而不会停机的证据。

如果您使用“AP”并且有远程人员（司机等），那么您需要编写一个应用程序，将他们的数据存储在他们的手机上并在后台发送（重试）。当然，无论您的数据库是 CA 还是 AP，您都可以这样做。

如果您想要更长的正常运行时间，您可以：

增加 MTBF（平均故障间隔时间） - 购买冗余电源、购买双以太网卡等。

减少 MTTR（平均恢复时间）- 只要确保发生故障时您可以快速恢复。 （故障转移到从站）

我见过有人在 MTBF 上花费数万美元，但在恢复备份时却停机了 8 小时。在攻击 MTBF 之前确保 MTTR 较低会更有意义。

【参考方案2】：

对于您的 24/ 要求，您正在搜索具有（高）可用性的数据库，因为您希望您的请求每次都成功（即使它们只是错误结果）。 当您没有分区容错时，netsplit 会使您的整个系统崩溃 一致性很好，但您只能拥有 3 个中的 2 个。

您最好的选择是 PA 解决方案。我强烈推荐一个受 Amazon Dynamo 启发的解决方案。最著名的 dynamo 实现是 riak 和 couchdb。 Riak 甚至允许您通过调整读写副本将 PA 更改为其他形式。

【讨论】：

或者您也可以自己使用 Dynamo db，它已于 2012 年 1 月在 AWS 上提供。