6

我已经问过一个关于披萨外卖店的简单容错软实时 Web 应用程序的问题。

在此处输入图像描述

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

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

因此，这个问题更笼统。

我发现，为了为此应用程序的 NoSQL 数据存储选项做出正确的选择，我要做的第一件事就是根据CAP 定理在和CA之间做出选择。PACP

现在，《用 Erlang 构建 Web 应用程序》一书说“虽然它 [Mnesia] 不是 SQL 数据库，但它是一个类似于 SQL 数据库的 CA 数据库。它不会处理网络分区”。同一本书说 CouchDB 数据库是一个PA数据库。

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

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

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

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

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

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

4

2 回答 2

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

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

于 2012-08-21T20:59:06.447 回答
0

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

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

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

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

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

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

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

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

于 2013-01-26T15:46:16.357 回答