淘宝应对"双11"的技术架构分析

　　双“11”最热门的话题是TB ，最近正好和阿里的一个朋侪聊淘宝的手艺架构，发现许多有意思的地方，分享一下他们的剖析资料：

　　淘宝海量数据产物手艺架构

　　数据产物的一个最大特点是数据的非实时写入，正由于云云，我们可以以为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠基了很是主要的基础。

图1 淘宝海量数据产物手艺架构

　　根据数据的流向来划分，我们把淘宝数据产物的手艺架构分为五层（如图1所示），划分是数据源、盘算层、存储层、查询层和产物层。位于架构顶端的是我们的数据泉源层，这里有淘宝主站的用户、店肆、商品和生意业务等数据库，另有用户的浏览、搜索等行为日志等。这一系列的数据是数据产物最原始的生命力所在。

　　在数据源层实时发生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是盘算层的主要组成部门。在“云梯”上，我们天天有约莫40000个作业对1.5PB的原始数据根据产物需求举行差别的MapReduce盘算。这一盘算历程通常都能在破晓两点之前完成。相对于前端产物看到的数据，这里的盘算效果很可能是一个处于中心状态的效果，这往往是在数据冗余与前端盘算之间做了适当平衡的效果。

　　不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产物前端。这种需求再接纳“云梯”来盘算效率将是比力低的，为此我们做了流式数据的实时盘算平台，称之为“银河”。“银河”也是一个漫衍式系统，它吸收来自TimeTunnel的实时新闻，在内存中做实时盘算，并把盘算效果在尽可能短的时间内刷新到NoSQL存储装备中，供前端产物挪用。

　　容易明白，“云梯”或者“银河”并不适合直接向产物提供实时的数据查询服务。这是由于，对于“云梯”来说，它的定位只是做离线盘算的，无法支持较高的性能和并发需求；而对于“银河”而言，只管所有的代码都掌握在我们手中，但要完整地将数据吸收、实时盘算、存储和查询等功效集成在一个漫衍式系统中，制止不了分层，最终仍然落到了现在的架构上。

　　为此，我们针对前端产物设计了专门的存储层。在这一层，我们有基于MySQL的漫衍式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点先容这两个集群的实现原理。除此之外，其他第三方的模块也被我们纳入存储层的领域。

　　存储层异构模块的增多，对前端产物的使用带来了挑战。为此，我们设计了通用的数据中心层——glider——来屏障这个影响。glider以HTTP协议对外提供restful方式的接口。数据产物可以通过一个唯一的URL获取到它想要的数据。

　　以上是淘宝海量数据产物在手艺架构方面的一个归纳综合性的先容，接下来我将重点从四个方面论述数据魔方设计上的特点。

　　关系型数据库仍然是王道

　　关系型数据库（RDBMS）自20世纪70年月提出以来，在工业生产中获得了普遍的使用。经由三十多年的长足生长，降生了一批优异的数据库软件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

图2 MyFOX中的数据增加曲线

　　只管相对于非关系型数据库而言，关系型数据库在分区容忍性（Tolerance to Network Partitions）方面存在劣势，但由于它强盛的语义表达能力以及数据之间的关系表达能力，在数据产物中仍然占有着不行替换的作用。

　　淘宝数据产物选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，我们设计了漫衍式MySQL集群的查询署理层——MyFOX，使得分区对前端应用透明。

 1/4    1 2 3 4 下一页 尾页