在讨论 eBay 的Scalability最佳实践 的时候，结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然，我不是说 ACID 就不重要了)
BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：
- Basically Available --基本可用
- Soft-state --软状态/柔性事务
- Eventual Consistency --最终一致性
"Soft state" (SS) 是与 "Hard state"(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的，这样就清晰多了。
最终一致性， 也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。
对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。
相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。
BTW: "ACID" 英文里面有"酸"的意思，而 "BASE" 有"碱"的意思. 酸碱在一起才能中和啊，哈
--EOF--
鄙人已经把 "技术散文：BASE: An ACID Alternative" 巡回演讲两次了.
还有自己设计的一套Live demo,在笔记本上现场演示.
这篇博客的内容和启发都非常重要. 却没被发掘, 好比沙里藏金.
支付宝在一致性和可用性上，妥协了一致性，获得了可用性。但是还是要确保最终一致性。
支付宝妥协一致性？这个我觉得 客户是不是 不太满意啊
作为一个支付接口 一致性难道比可用性弱吗
话说回来 目前很多支付接口 似乎都有延迟问题
当然还得看这个“最终” 的时间跨度
假如说 30分钟内 那还是非常可以接受的 要是超过几小时甚至几天 就绝对不行了吧
好像我没说妥协一致性吧。BASE 是通用的... 每家公司要根据自己的业务作选择。
"Basically Availble --基本可用"中 Availble 应该是 Available