海量存储系列之五

http://rdc.taobao.com/team/jm/archives/1365 上一章

在上一章节，我们一起浏览了如何进行单机事务操作。下面我们来看一下分布式场景中我们碰到的问题吧。

需要说明的一点是，这里涉及到的权衡点非常的多。就我短短的工作经验里面，也只是能够简单的涉猎一部分，因为在事务这个领域，目前大家都在尝试提出各种各样的不同的方法，而在taobao，我们目前也没有完美的解决这个问题，更多的是在权衡，在金钱和开发成本之间，做出选择。

那么，我们就先从问题开始，来看一下原来的事务出了什么问题。

在事务中，有ACID四种属性。（见上篇文章）

在分布式场景中，我们看引入了什么因素，导致了什么样的新问题：

1. 延迟因素:光是我们所知最快的信息载体了，各位可能都会从潜意识里面认为光传输信息不就是一眨眼的事情而已。那我们做个简单的计算吧（感谢@淘宝叔度，第一次在分享中让我对这个问题有了个数值化的印象。）：

北京到杭州，往返距离2600km ，光在真空中的传输速度是30wkm/s。在玻璃中的速度是真空的2/3。算下来，最小的请求和响应，之间的延迟就有13ms。并且，因为光在管子里走的不是直线，又有信号干扰等问题，一般来说要乘以2~3倍的因子值。

所以一次最小的请求和响应，时间就差不多有30ms左右了。

再想想TCP的时间窗口的移动策略，相信大家都能意识到，实际上延迟是不可忽略的，尤其在传输较多数据的时候，延迟是个重要的因素，不能不加以考虑。

并且，延迟 不是 带宽，带宽可以随便增加，千兆网卡换成万兆，但延迟却很难降低。而我们最需要的，是带宽，更是延迟的降低。因为他直接决定了我们的可用性。

1. 灾备因素：单机的情况下，人们一般不会去追求说一个机器物理上被水冲走了的时候，我的数据要保证不丢（因为没办法的嘛。。）。但在分布式场景下，这种追求就成为了可能，而互联网行业，对这类需求更是非常看重，恨不能所有的机器都必须是冗余的，可随意替换的。这样才能保证7*24小时的正常服务。这无疑增加了复杂度的因素。

2. Scale out的问题： 单机总是有瓶颈的，于是，人们的追求就一定是：不管任何一种角色的机器，都应该可以通过简单的增加新机器的方式来提升整个集群中任何一个角色的性能，容量等指标。这也是互联网行业的不懈追求。

3. 性能：更快的响应速度，更低的延迟，就是更好的用户体验。（所以google用了个“可怜”到家的简单input框来提升用户体验，笑）。

说道这里，大概大家都应该对在分布式场景下的广大人民群众的目标有了一个粗略的认识了。

那么我们来看一下原有ACID的问题吧。

在上次的章节中，我们也提到了ACID中，A和D相对的，比较容易达到。但C和I都涉及到锁实现，也就和性能紧密的相关了。

然后，人们就开始了纠结，发掘这个C和I，似乎不是那么容易了。

上次，我们谈到，目前主流的实现一次更新大量数据的时候，不同人（或机器）修改数据相互之间不会打架的方法有以下几种：

1. 排他锁

2. 读写锁

3. Copy-on-write

4. 队列

5. 内存事务

排他锁和读写锁，本身都是锁的实现，单机的锁实现，相对而言是非常简单的事情，但如果涉及到分布式锁，那么消耗就很高了，原因是，锁要在两边都达到一致，需要多次机器之间的交互过程，这个交互的过程，再考虑到延迟的因素，基本上一次加锁请求就要100~200+毫秒的时间了，那么去锁又要这样的时间。而要知道，我们在单机做内存锁操作，最慢也不过10毫秒。。

于是，有一批人就说了，既然这么难，我们不做了！~来个理论证明他很难就行了~。于是就有了CAP和BASE.

所谓CAP，我个人的理解是描述了一种： 在数据存了多份的前提下，一致性和响应时间，读写可用性不可兼得的“现象”而已。

在我这里来看CAP的证明过程就是个扯淡的玩意儿，他只是描述了一种现象而已。原因还是网络延迟，因为延迟，所以如果要做到数据同时出现或消失，那么按照锁的方式原来可能只需要10ms以内完成的操作，现在要200~400ms才能完成，那自然不能接受了。所谓CAP就是这个现象的英文简称，笑。

BASE呢，这个理论似乎更老，其实也是个现象，就是基本可用，软状态，最终一致的简称，也没个证明，其实就是告诉咱：要权衡一下，原来的ACID不太容易实现啦，我们得适当放弃一些啦。但请各位注意，ACID实际上是能够指导我们在什么情况下做什么样的事情能够获取什么样的结果的。而BASE则不行，这也说明BASE不是个经典的理论。

好啦。废话了这么多，其实就是想说，分布式场景没有银弹啦，你们自己权衡去吧。我们大牛们救不了你们啦的意思。。

既然大牛救不了咱，咱就只能自救了。。。

http://rdc.taobao.com/team/jm/archives/1379 下一篇