分布式 Erlang 和 CAP 定理
根据 CAP 定理，CAP 定理是不可能的。 erlang.org/doc/reference_manual/distributed.html" rel="nofollow">分布式 Erlang 系统同时提供以下所有三个保证：
- 一致性（所有 Erlang 运行时或节点在可用性
- （节点故障不会阻止幸存者继续运行）
- 分区容错性（尽管任意消息丢失，系统仍继续运行）
分布式 Erlang 系统可以支持零、一 或两个 保证。
使用Erlang和OTP，每个保证如何实现？大多数分布式 Erlang 应用程序都会选择更高级别的 A 和 P，并满足于“最终一致性”。看来Erlang本身就是为了支持分布式（P）、容错（A）、软实时、不间断的应用程序而设计的。
编程语言（Erlang）、运行时系统（ERTS）和库集（OTP）旨在构建分布式容错应用程序；我该如何做定义分布式容错应用程序的三件事？
By the CAP theorem, it is impossible for a distributed Erlang system to simultaneously provide all three of the following guarantees:
- Consistency (all Erlang runtimes, or nodes, see the same data at the same time)
- Availability (node failures do not prevent survivors from continuing to operate)
- Partition Tolerance (the system continues to operate despite arbitrary message loss)
A distributed Erlang system can support zero, one, or two of the guarantees.
Using Erlang and OTP, how can each guarantee be implemented? Most distributed Erlang applications make the practical choice for higher levels of A and P, and settle for "eventual consistency". It seems Erlang itself was designed to support distributed (P), fault-tolerant (A), soft-real-time, non-stop applications.
The programming language (Erlang), run-time system (ERTS), and set of libraries (OTP) are designed for building distributed fault-tolerant applications; how do I do the three things that define distributed fault-tolerant applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为清楚起见已编辑
这取决于您的应用程序的设计，而不是您实现它的平台。您可以使用几乎任何语言或平台组合来实现其中任何两个保证。
EDITED for clarity
It depends on the design of your application and not the platform in which you implement it. You could implement any 2 of the guarantees, with just about any language or platform combination.
我发现的一个很好的例子是 Riak，一个基于 Amazon Dynamo 的分布式键值存储并使用 Erlang 和 OTP 构建。 可调 CAP 控件让您动态“选择”您的一致性和可用性水平；它选择关注CAP的A和P，这使得它最终保持一致。 Riak 是开源的，网上有很多关于其实现的好文章。
另一个很好的例子是 Dynomite，PowerSet 的 Dynamo-clone-in-Erlang。尽管该项目已经停止了一段时间，但它可以作为关于如何构建 Dynamo 克隆的有用的功能设计文档。
这两个项目本身基于 Amazon 的 Dynamo，这是一种可增量扩展、高度可用的键值存储系统。该技术旨在让用户能够在成本、一致性、耐用性和性能之间进行权衡，同时保持高可用性。这篇论文值得一读。
A really good example I found is Riak, a distributed key-value store based on Amazon's Dynamo and built using Erlang and OTP. The tunable CAP controls let you dynamically "choose" your levels of consistency and availability; it chooses to focus on the A and P of CAP, which makes it eventually consistent. Riak is open-source, and there are a number of good articles online regarding its implementation.
Another good example is Dynomite, PowerSet's Dynamo-clone-in-Erlang. Although the project has been dead for a while, it serves as a useful functional design document on how to build a Dynamo clone.
These two projects are themselves based on Amazon's Dynamo, an incrementally scalable, highly-available key-value storage system. The technology is designed to give its users the ability to trade-off cost, consistency, durability and performance, while maintaining high-availability. The paper is a good read.
Erlang 的优势应该是选择 A&P，但与任何系统一样，可以选择任何两个或更少。这部分是由于 erlangs 编程模型通过消息传递进行所有通信。如果你使用良好的 Erlang 风格，你就不会使用共享内存在进程之间进行通信。
Erlangs strength should be with chosing A&P, but as with any system it is possible to chose any two or less. This is partly due to erlangs programming model with all communication through message passing. If you use good Erlang style you don't use shared memory to communicate between processes.
我认为这个定理应该只在一层考虑。什么是图层？它类似于 OSI-ISO 层，但针对数据库：应用程序/数据库、操作系统、磁盘/硬件。一层无法满足所有 CAP 条件。 Erlang/OTP 在应用层运行，因此用 Erlang 覆盖其中的 2 个（您可以选择，因为 Erlang 的灵活性），最后一个用操作系统（即文件系统）或硬件层（raid）覆盖。
I think this theorem should be considered in only one layer. What is a layer? It is something like OSI-ISO layers but for databases: application/db, OS, disk/hardware. All of the CAP conditions cannot be satisfied in one layer. Erlang/OTP operates in application layer so cover 2 of them with Erlang (you can choose, because of flexibility of Erlang) and the last one cover with OS (i.e. file system) or hardware layer (raid).