淘宝海量数据产品的技术架构（有删减）

标签：

缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。在数据魔方里，我们采用了一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存失效时的雪崩效应对底层系统的冲击非常可怕。遗憾的是，这个问题目前并没有很完美的解决方案。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。在数据魔方中，我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均匀地分布在时间轴上，一定程度上能够避免缓存同时失效带来的雪崩效应。

【1】海量数据领域涵盖分布式数据库、分布式存储、数据实时计算、分布式计算等多个技术方向。
对于海量数据处理，从数据库层面来讲无非就是两点：1、压力如何分摊，分摊的目的就是为了把集中式变为分布式。2、采用多种的存储方案，针对不同的业务数据，不同的数据特点，采用RDBMS或采用KV Store，选择不同数据库软件，使用集中式或分布式存储，或者是其他的一些存储方案。

【2】将数据库进行拆分，包括水平拆分和垂直拆分。
水平拆分主要解决两个问题：1、底层存储的无关性。2、通过线性的去增加机器，支持数据量以及访问请求包括TPS（Transaction Per Second）、QPS（Query Per Second）的压力增长。其方式如把一张大数据表按一定的方式拆分到不同的数据库服务器上。海量数据从集中式走向分布式，可能涉及跨多个IDC容灾备份特性。

【3】阿里巴巴的数据对不同地域数据的处理方法。由三个产品密切配合解决：是Erosa、Eromanga和Otter。Erosa做MySQL（或其他数据库库）的Bin-Log时时解析，解析后放到Eromanga。Eromanga是增量数据的发布订阅的产品。Erosa产生了时时变更的数据发布到Eromanga。然后各个业务端（搜索引擎、数据仓库或关联的业务方）通过订阅的方式，把时时变更的数据时时的通过Push或Pull的方式拉到其业务端，进行一些业务处理。而Otter就是跨IDC的数据同步，把数据能及时反映到不同的AA站。数据同步可能会有冲突，暂时是以那个站点数据为优先，比如说A机房的站点的数据是优先的，不管怎么样，它就覆盖到B的。

【4】对于缓存。
1、注意切分力度，根据业务选择切分力度。把缓存力度划分的越细，缓存命中率相对会越高。2、确认缓存的有效生命周期。

【5】拆分策略
1、按字段拆分（最细力度）。如把表的Company字段拆掉，就按COMPANY_ID来拆。
2、按表来拆，把一张表拆到MySQL，那张表拆到MySQL集群，更类似于垂直拆分。
3、按Schema拆分，Schema拆分跟应用相关的。如把某一模块服务的数据放到某一机群，另一模块服务的数据放到其他MySQL机群。但对外提供的整体服务是这些机群的整体组合，用Cobar来负责协调处理。

• 单一应用架构
  • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
  • 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
• 垂直应用架构
  • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
  • 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
• 分布式服务架构
  • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
  • 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
• 流动计算架构
• 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
• 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

几种通信协议比较：Socket (BIO/NIO/Netty/MINA) > RMI > HTTP Invoker >= Hessian > REST >> Burlap > EJB >> Web Service

1. 如果协议设计的比较好，Socket性能毫无疑问是最高，同时灵活性和复杂度也最高，如果采用高效的网络框架如:Mina、Netty等可以降低开发复杂度，一般在对性能有非常苛刻的条件下使用。
2. RMI 的性能相对略低，但是与Socket还在同1个数量级，同时只能在Java系统间通信，如果是基于互联网使用，还存在穿越防火墙的问题。采用Spring 封装的方式使用比原始RMI方式性能略高，主要原因是：Spring采用了代理和缓存机制，节省了对象重新获取的时间。
3. HTTPInvoker是Spring特有的，只能在客户端和服务器端都采用Spring框架下使用，与RMI本质相同，使用java的序列化技术传输对象，两者性能差别较小。
4. Hessian 在数据量较小时性能表现出众，甚至比RMI还高，在数据结构复杂的对象或者大量数据对象时，较RMI要慢20%左右；Hessian的优点是精简高效，同 时可以跨语言使用，目前支持Java,C++, .net, python, ruby等语言。另外Hessian可以充分利用web容器的成熟功能，在处理大量用户访问时很有优势，在资源分配、线程排队、异常处理等方面都可以由 web容器保证，而RMI本身不提供多线程的服务器。
5. REST架构也是一种比较简单、高效的Web服务架构，相对于Hessian性能略低，但还在同一个数量级，同时也是基于HTTP协议，目前也有比较多的成功案例。
6. Burlap 在数据量非常小时性能尚可，同时性能随着数据量的增加急剧降低，通常性能耗时是RMI的3倍左右，主要原因是：Hessian采用二进制传输数据，而 Burlap采用XML格式，而XML描述内容太多，同样的结构，其传输量要大很多，同时，XML的解析是比较耗资源的，尤其大数据量情况下更是如此。
7. EJB基于RMI协议，性能不高，同时只能在Java系统内使用，不能跨语言，目前使用越来越少，目前阿里巴巴内部已经完全放弃EJB。
8. 在 这些远程调用协议中，Web Service的性能是最低的，一般情况下，Web Service的性能相对于Hessian性能要慢10~20倍左右，同时，对于同样的访问请求，Web Service的传输数据量约为Hessian的6倍左右，对网络带宽消耗非常大，同时XML的解码器普遍性能不高，XML<->Java Bean的编码、解码非常耗费资源，对于并发和负载比较高的网站不是一个好的选择。同时，Web Service的使用也不太方便。

总结：Hessian和REST架构个人认为是比较优秀的高性能通信协议，如果对性能要求特别苛刻可以直接采用Socket方式，目前，阿里巴巴内部的远程调用主要采用Hessian和Dubbo(基于Mina/Netty框架)，经受了苛刻的高并发、高负载考验。

淘宝海量数据产品的技术架构（有删减）

标签：

原文地址：http://my.oschina.net/zhangjie830621/blog/509484