进一步看[分区]之后

用一下这张图[引用自 link 2]，在状态S的时候是非分区状态，而分区模式则演化出来了S1，S2，那么问题来了，分区恢复之后，状态究竟是多少呢？有几种解决方案。

分区恢复策略：可交换多副本数据类型 

注意，能支持此类处理的场景是有限的。

riak_dt 就是这样一种保障最终一致性实现的数据结构，它分为Operation-based CRDTs、State-based CRDTs 2种形态。

riak_dt   link参见 link [3]。

State-based CRDTs

State-based CRDTs are called convergent replicated data types, or CvRDTs. In contrast to CmRDTs, CvRDTs send their full local state to other replicas. CvRDTs have the following local interface:

• query - reads the state of the replica, with no side effects
  
• update - writes to the replica state in accordance with certain restrictions
  
• merge - merges local state with the state of some remote replica
  

The merge function must be commutative, associative, and idempotent. It provides a join for any pair of replica states, so the set of all states forms asemilattice. The update function must monotonically increase the internal state, according to the same partial order rules as the semilattice.

from：https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

分区恢复策略：回放合并

在分区恢复过程中，设计师必须解决两个问题：

• 分区两侧的状态最终必须保持一致，
  
• 并且必须补偿分区期间产生的错误。
  

如上图所示，对于分区恢复的状态S*可以通过未分区时的状态S为起点，然后按顺序[回放]相应的变化事件[以特定方式推进分区两侧的一系列操作，并在过程中一直保持一致的状态。]。Bayou[link 4]就是这个实现机制，它会回滚数据库到正确的时刻并按无歧义的、确定性的顺序重新执行所有的操作，最终使所有的节点达到相同的状态。

对于有冲突的情况，比如版本管理软件cvs，存在人工介入、消除冲突的处理策略。

 有限制处理

有限制处理：[link 2]提的自动柜员机补偿问题，比较形象说明了这个问题。此问题本质上是可用性和一致性的折衷处理。

以自动柜员机（ATM）的设计来说，强一致性看似符合逻辑的选择，但现实情况是可用性远比一致性重要。理由很简单：高可用性意味着高收入。不管怎么样，讨论如何补偿分区期间被破坏的不变性约束，ATM的设计很适合作为例子。

ATM的基本操作是存款、取款、查看余额。关键的不变性约束是余额应大于或等于零。因为只有取款操作会触犯这项不变性约束，也就只有取款操作将受到特别对待，其他两种操作随时都可以执行。

ATM系统设计师可以选择在分区期间禁止取款操作，因为在那段时间里没办法知道真实的余额，当然这样会损害可用性。现代ATM的做法正相反，在stand-in模式下（即分区模式），ATM限制净取款额不得高于k，比如k为$200。低于限额的时候，取款完全正常；当超过限额的时候，系统拒绝取款操作。这样，ATM成功将可用性限制在一个合理的水平上，既允许取款操作，又限制了风险。

分区结束的时候，必须有一些措施来恢复一致性和补偿分区期间系统所造成的错误。状态的恢复比较简单，因为操作都是符合交换率的，补偿就要分几种情况去考虑。最后的余额低于零违反了不变性约束。由于ATM已经把钱吐出去了，错误成了外部实在。银行的补偿办法是收取透支费并指望顾客偿还。因为风险已经受到限制，问题并不严重。还有一种情况是分区期间的某一刻余额已经小于零（但ATM不知道），此时一笔存款重新将余额变为正的。银行可以追溯产生透支费，也可以因为顾客已经缴付而忽略该违反情况。

总而言之，因为通信延迟的存在，银行系统不依靠一致性来保证正确性，而更多地依靠审计和补偿。“空头支票诈骗”也是类似的例子，顾客赶在多家分行对账之前分别取出钱来然后逃跑。透支的错误过后才会被发现，对错误的补偿也许体现为法律行动的形式。

此前，中行IBM大型机宕机，系统没有第一时间切换到热备或者异地容灾上，直接影响中行的信用卡支付相关业务，直到4小时之后才恢复服务。有对应的的原因包括日常演练等问题，等更重要的是在[可用性和一致性]之间选择了一致性，4H之后提供服务，备库仍然主要起数据备份的作用。

有限制处理方案是需要冒险滴，为了保障可用性，无法保障数据100%精确，可以折衷提供部分有损服务。比如取款根据信用是不是能限制一定金额，而存款是Ok的等等。大额对公业务也可以采取具体办法，当然这将在精细化管理服务能力及配套能力上付出更多的IT成本。

有关中行IBM大型机宕机的报道link：

http://digi.tech.qq.com/zt2013/syibm/

http://www.infoq.com/cn/news/2013/04/BOC-Downtime/

超越CAP？

Nathan Marz：How to beat the CAP theorem

2011年11月Twitter的首席工程师Nathan Marz写了一篇文章，描述了他是如何试图打败CAP定理的： How to beat the CAP theorem

作者表示不是要“击败”CAP，而是尝试对数据存储系统进行重新设计，以可控的复杂度来实现CAP。Marz认为一个分布式系统面临CAP难题的两大问题就是：在数据库中如何使用不断变化的数据，如何使用算法来更新数据库中的数据。

Marz提出了2个基本思路：

1) 数据不存在update，只存在append操作。这样就把对数据的处理由CRUD变为CR；同样的，delete操作也可以处理为add一条新记录：比如 友强取消了对山丘的关注，传统关系型数据库是在关系表删除一条记录，而Marz也可以新增一条关系为[取消]的记录。

2) 所有的数据的操作就只剩下Create和Read。把Read作为一个Query来处理，而一个Query就是一个对整个数据集执行一个函数操作。

总结，在有一定时序性，且对实时一致性要求不高的场景下可以选择使用，毕竟在问题解决域多了一把锤子。Query过程中的跨分区函数仍然是一种合并的变种（Merge）！

OceanBase的另类之路

既然更新数据涉及到分区问题，那么能不能把更新放到一个服务器呢[脑洞大开]？然后通过强大的软件+硬件能力一起去保障它！同时已经不修改的数据天然具备可扩展性！这是我粗暴理解OceanBase的基本设计思想。

link[5] 写道：作为电子商务企业，淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性，数据特征是数据总量庞大且逐步增加，单位时间内的数据更新量并不大，但实时性要求很高。这就要求我们提供一套更加偏重于支持CA特性的系统，同时兼顾可分区性，并且在实时性、成本、性能等方面表现良好。

OceanBase的逻辑架构简图

关于UpdateServer的性能问题

其实大部分数据库每天的修改次数相当有限，只有少数修改比较频繁的数据库才有每天几亿次的修改次数。另外，数据库平均每次修改涉及的数据量很少，很多时候只有几十个字节到几百个字节。假设数据库每天更新1亿次，平均每次需要消耗100字节，每天插入1000万次，平均每次需要消耗1000字节，那么，一天的修改量为：1亿 * 100 + 1000万 * 1000 = 20GB，如果内存数据结构膨胀2倍，占用内存只有40GB。而当前主流的服务器都可以配置96GB内存，一些高档的服务器甚至可以配置192GB、384GB乃至更多内存。

TiDB 

TiDB 是国内 PingCAP 团队开发的一个分布式 SQL 数据库。其灵感来自于 Google 的 F1, TiDB 支持包括传统 RDBMS 和 NoSQL 的特性。从下面这篇访谈来看，分布式事务早期版本中，他们参考的是 Google 的 Percolator 的模型。由于该项目还未在线上产品使用，就不具体展开了，有兴趣的朋友参考下面的link[6]。

[1] link：http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

[2] link：http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed/

[3] link：https://github.com/basho/riak_dt 

[4] link：http://www.cs.berkeley.edu/~brewer/cs262b/update-conflicts.pdf

[5] link：http://code.taobao.org/p/OceanBase/wiki/intro/

[6] link：http://mt.sohu.com/20160122/n435472384.shtml

总结：CAP是分布式领域的重要理论，但不代表完全不能有延展的解读和思考。另外[三选二]本身也是有条件成立的，不能简单误读，一切取决于应用场景。如果不加选择按照理论形式无异于刻舟求剑。