CouchDB及Append-only B+树

前言

今天晚上在写分布式系统上下层概念抽象-(2)的时候，遇到了一致性相关的内容，简单搜索了一些CAP的文章，就无意中看到了博文CouchDB Eventually Consistency。它是一个分布式的key-value数据库，感觉里面的设计还挺有意思的，很多ideas虽然知道，但是并没有和实际的系统挂钩，现在把它的一些设计思路写一写，主为备忘，权当一乐。

分布式系统

分布式系统需要处理的最典型情况就是网络分区故障，相比于很多系统将强一致性列为第一大需要，CouchDB采用了最终一致性的范畴，以可用性为第一准则。CouchDB提供了一种有效的方式来达到系统高可用。

CAP

1. Consistency：所有节点在任何时刻看到都是相同的数据
2. Availability：对于外部的请求，系统一定能够响应。
3. Partition Tolerance：网络分区故障或者节点系统依然可以对外提供服务

然而如上图所示，最多两个条件能得到同时满足。CouchDB在满足PA的情况下，达到最终一致性。

当在分布式系统增加新server的时候，我们必须考虑如何划分数据：所有的节点是存储一样的数据？每个节点只存储部分数据？单点写，多点读？CouchDB采用的是所有的节点存储一样的数据方案（完全的副本）。那新的问题来了，如何保证server之间的同步？如何能够确保写操作能够立刻反映到其他的节点上？毫无疑问，为了保证所有的节点都能看到一致的数据库状态，某一个节点必须等待其他节点达成一致性协议，写操作才能开始写入。在这种情况下，一致性比可用性重要。然而，也有一些情况可用性比一致性重要。

Each node in a system should be able to make decisions purely based on local state. If you need to do something under high load with failures occurring and you need to reach agreement, you’re lost. If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given.
—Werner Vogels, Amazon CTO and Vice President

如果可用性更重要，那么我们需要使得客户端不需要等待其他节点达成协议，就可将数据写入到server中。只要数据库自身能够协调解决冲突，那就达成了某种“最终一致性”，从而获得高可用性，这种服务保证在很多现实应用中都是一个很好的tradeoff。

Local Consistency