海量存储系列之五

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文来源于"阿里中间件团队播客",原文发表时间" 2011-12-15"

「数据密集型系统搭建」原理篇｜用什么方式存储数据最合适 本篇来聊聊数据存储的内容，看看程序世界里数据是以什么形式存在的？为了描述数据并把它们和这个现实世界关联起来我们一般都是如何去进行表达的？最后通过我们习惯的表达方式再结合数据结构是如何存储下来的？   
《如何使用Tair增强数据结构构建丰富在线实时场景》电子版地址 阿里云内存数据库Tair在完全兼容Redis的基础上，推出了 Tair 增强数据结构。Tair的增强数据结构有什么独特的优势？如何使用 TairRoaring 构建企业级实时人群服务？如何使用TairSearch 构建在线交互搜索？我们一一揭晓。
如何使用 Tair 增强数据结构构建丰富在线实时场景 Redis 数据结构模块是 Redis 提供的一种扩展数据结构功能的方式。Redis 提供了很多内置的数据结构，但是如何通过自己想要的方式来扩展自定义数据结构？ Redis 在 4.0 引入 Redis Modules， 用户可以通过调用 Redis Modules API 来实现自定义的数据结构。
图文存储常识：单机、集中、分布式、云、云原生存储 本文主要对杨传辉（日照）《大规模分布式存储系统原理解析与架构实战》、大话存储、网络资源(具体参考文末链接)及个人理解进行整理，意在构建出存储发展基本轨迹和一些基本常识，让更多像我一样的初入者有个宏观上的认知。 存储发展史 从单机到互联网，存储作为的基础设施，主要发展都是围绕构建 低成本、高性能、可扩展、易用的目标进行演进，时至今日，在形态上存储分为单机存储、集中存储、分
云原生必备知识： 应用储存 由于容器本身是非持久化的，因此需要解决在容器中运行应用程序遇到的一些问题。首先，当容器崩溃时，kubelet将重新启动容器，但是写入容器的文件将会丢失，容器将会以镜像的初始状态重新开始；第二，在通过一个Pod中一起运行的容器，通常需要共享容器之间一些文件。Kubernetes通过存储卷解决上述的两个问题。 在Docker有存储卷的概念卷，但Docker中存储卷只是磁盘的或另一个容器中的目录，并没有对其生命周期进行管理。Kubernetes的存储卷有自己的生命周期，它的生命周期与使用的它Pod生命周期一致。因此，相比于在Pod中运行的容器来说，存储卷的存在时间会比的其中的任何容器都长，并且在容器