从NimbusDB网站：
我们的分布式非阻塞原子提交协议允许在任何可用节点上处理数据库事务。
他们声称，他们可以保证分布式环境中的acid事务，并提供所有的功能：一致性、高可用性和分区容限。据我从文中所知，他们克服cap定理局限性的“秘诀”是某种管理网络分区的“可预测且一致”的方法。
我想知道有没有人对背后有什么见解或更多的信息？
最佳答案
这篇文章发表已经有一段时间了，从那以后，nuodb在他们的网站上为他们的产品营销和技术资源增加了很多。
他们通过使用分布式数据缓存系统实现了数据持久性和acid遵从性。他们现在称之为“Emergent Architecture:”（第6-7页）
该体系结构打开了多种可能的未来方向，包括“时间旅行”，创建数据库副本的能力，该副本可在较早的时间重新创建其状态；“云爆炸”，跨由单独组管理的云系统移动数据库的能力；以及
“coteries”是一种解决cap定理的机制，它允许dba指定哪些系统在网络分区中生存，以提供连续可用性的一致性和分区阻力。
从How It Works页：
今天的数据库供应商已经在传统系统周围应用了三种常见的设计模式来将它们扩展到分布式扩展数据库系统中。这些方法（共享磁盘、不共享任何内容和同步提交）克服了单服务器部署的一些限制，但仍然很复杂，容易出错。
nuodb的技术创始人jim starkey从一开始就对数据库设计进行了反思，提出了一种全新的设计方法，称为持久分布式缓存（durable distributed cache，ddc）。net effect是一个在商品机和虚拟机上动态扩展的系统，它没有单点故障，并提供完整的acid事务语义。
nuoddb的newsql模型与更传统的rdms系统的主要架构差异在于，nuodb颠倒了内存和存储之间的传统关系，创建了一个与acid兼容的rdbms，其底层设计类似于分布式dram缓存。从nuodbDurable Distributed Cache页面：
迄今为止，所有通用关系数据库都是围绕以存储为中心的假设而构建的。不幸的是，这造成了一个与向外扩展相关的根本问题。实际上，这些数据库系统是一种奇特的文件系统，它们安排对基于磁盘的文件的并发读/写访问，这样用户就不会相互干扰。
nuodb-ddc体系结构颠覆了这一想法，将数据库想象成一组内存中的容器对象，这些对象可以在必要时溢出到磁盘，并可以保留在后备存储器中以实现持久性。
nuodb-ddc体系结构中的所有服务器都可以请求和提供对象（称为原子），从而充当彼此的对等点。某些服务器在任何给定时间都有一个子集对象，因此只能将数据库的一个子集提供给其他服务器。其他服务器拥有所有对象，可以提供其中任何一个，但提供不驻留在内存中的对象的速度会慢一些。
NUODB由两种类型的服务器组成：事务引擎（TE）保存对象的子集；存储管理器（SMS）是具有所有对象的完整副本的服务器。TE是纯内存服务器，不需要使用磁盘。它们是自主的，可以根据需要单方面从内存中加载和弹出对象。与tes不同的是，sms不能只在完成后将物品扔到地板上；相反，它们必须确保它们安全地放置在耐用的存储中。
对于那些熟悉缓存体系结构的人来说，您可能已经认识到这些te实际上是一个分布式dram缓存，而sms是确保持久性的专用te。因此命名为持久分布式缓存。
他们还深入研究了子系统组件，以及他们协同工作的方式，为符合acid的rdmbs提供nosql系统的大部分性能（注意：在他们的网站上注册以下载白皮书）。一般的要点是，它们提供了一个自动化的网络集群分区系统，当与它们的持久存储系统结合时，可以解决publish a technical white paper的问题。
在他们的CAP Theorem
关于database - NimbusDB-分布式，非阻塞，原子提交协议(protocol)？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6056306/