作者：刘旭晖 Raymond 转载请注明出处

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多论文阅读笔记?http://blog.csdn.net/column/details/cloudpaper.html

?

== 目标问题 ==

?

TAO的目标问题是构建一个在Facebook这样大规模的社交类分布式应用服务中，能够从海量相关联的数据中高效的生成精确定制化内容的数据仓库。其应用场合具有全球性，海量动态变化数据，高并发查询等特性。

?

== 核心思想 ==

?

Facebook的社交网络服务的数据模型是基于对象和对象之间的关联来构建的。数据主要表现为对象和关联两类，对象如用户，图片，帖子，评论，一次checkin等等，关联就是各种对象之间的关系，朋友阿，谁的帖子阿，针对哪个帖子的评论啦等等。所有对象和关联都有一个ID字段作为唯一标识。

?

?

在这种应用模型下，各种离散的数据之间都有众多的关联关系，难以简单的分类处理，最终的应用展现也千变万化，因此众多的工作不是在更新数据时完成，而只能在查询时再进行处理，所以是一个read dominate的过程。

?

Facebook原有的框架靠应用程序分别与MySQL和Memcached服务器交互来管理和缓存数据。问题在于memcached不能有效的利用上这种对象关联模型的信息，各个client也不能有效地全局规划管理cache，在数据更新后的一致性方面也存在较高的代价。

?

TAO依旧以MySQL为底层数据库来存储数据，数据以ID划分到众多的shard上，每个MySQL服务器负责管理若干个Shard，TAO的缓存层中，多台Cache服务器组成一个Tier，一个Tier包含了支持所有TAO操作请求所需的信息。客户端程序通过类似的Shard算法与特定的Cache服务器通讯，由Cache服务器完成数据的读写请求以及与MySQL数据库的交互。

?

== 实现 ==

?

为了提高并发处理的能力，TAO的缓存层实际由两级的Tier组成（一个Leader和多个Follower），客户端与就近的Follower Tier通讯，而FollowerTier将写请求转发通过Leader Tier完成，读请求主要由Follower Tier完成，除非有数据Miss不在缓存中的，才向Leader Tier发送请求。

?

?

可以看到Followers并不与数据库交互。 为了适应全球化的布局，减少全局网络通讯延迟带来的影响，TAO的数据库和缓存层实际上如上图所示，又进一步划分为Master/Slave Region，每个Region都有上述的两极Tier，所有的写操作必须通过Master Region的Leader来完成，再异步同步给Slave Region的数据库，读操作则由Slave Region本地完成，如果本地数据库没有及时被更新，则有可能读取的是过时的数据。

?

以上Region的划分是增对每一个Shard，不同的Shard可能由不同的Master负责，由于关联的更新操作可能涉及多个Shard，为了减少通讯开销，所有的Master还是倾向于分配在同一个Region内部。

?

值得注意的是，每个Region都需要有完整的数据，而因为数据量巨大，所以单个Region可能是由多个地域上接近的数据中心组成的。

?

== 相关研究，项目等 ==

?

由于缓存层的存在，由RMDBS数据库（这里的MySQL）保证的ACID方面的指标，在一定程度上被减弱了。当然根据CAP理论，这也是大规模分布式数据库不可避免的问题，通常都会降低一致性要求。在TAO中，牺牲C不完全是出于满足AP的要求，很大一部分的原因是为了解决latency的问题，类似于这里说的：http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html

?

其它全球规模的数据库，如Google的Megastore，Spanner等系统，通过Paxos，GPS，原子时钟等各种机制保证数据的读写一致性。而从上面可以看到TAO在数据一致性方面，采用的是渐进一致性，存在读取过时数据等各种问题，整体的多层框架也有拼凑的感觉，但总体上来说，一切还是为了最大化海量并发请求下的吞吐率所做的妥协。

cs