淘宝是一家迅速发展的公司。全球网站排名公司Alexa提供的数据显示，2010年4月27日，Amazon、Ebay的用户占全球互联网用户的百分比 分别为3.47%和2.68%，而淘宝的用户占全球互联网用户的百分比则达到了4.1%，淘宝网日独立访问量从此超过了Amazon和Ebay。

　　淘宝的数据规模及其访问量对关系数据库提出了很大挑战：数十亿条的记录、数TB的数据、数千TPS、数万QPS让传统的关系数据库不堪重负，单纯的硬件升级已经无法使得问题得到解决，分库分表也并不总是凑效。下面来看一个实际的例子。

　　淘宝收藏夹是淘宝线上应用之一，淘宝用户在其中保存自己感兴趣的宝贝(即商品，此外用户也可以收藏感兴趣的店铺)以便下次快速访问、对比和购买等，用户可以展示和编辑(添加/删除等)自己的收藏。

　　淘宝收藏夹数据库包含了收藏info表(一条一条的收藏信息)和收藏item表(被收藏的宝贝和店铺)等：

• 　　收藏info表保存收藏信息条目，数十亿条
• 　　收藏item表保存收藏的宝贝和店铺的详细信息，数亿条
• 　　热门宝贝可能被多达数十万买家收藏
• 　　每个用户可以收藏千个宝贝
• 　　宝贝的价格、收藏人气等信息随时变化

　 　如果用户选择按宝贝价格排序后展示，那么数据库需要从收藏item表中读取收藏的宝贝的价格等最新信息，然后进行排序处理。如果用户的收藏条目比较多 (例如1000条)，那么查询对应的item的时间会较长：假设如果平均每条item查询时间是5ms，则1000条的查询时间可能达到5s，若果真如 此，则用户体验会很差。

　　如果把收藏的宝贝的详细信息实时冗余到收藏info表，则上述查询收藏item表的操作就不再需要了。但是，由于许多热门商品可能有几千到几十万人收藏，这些热门商品的价格等信息的变动可能导致收藏info表的大量修改，并压垮数据库。

　 　OceanBase是淘宝自主研发的海量数据库，并且已经开源( http://oceanbase.taobao.org/ )。在应用团队和OceanBase团队的共同努力下，上述问题得到了很好地解决：平均响应时间几十毫秒，最长响应时间一百多毫秒。与先前使用的关系数据 库相比，系统QPS和TPS提升了几倍，服务器数量反而减少了。

淘宝海量数据库之二：一致性选择

在之前的文章中介绍了《淘宝海量数据库之一：来自业务的挑战》。今天是它的后续文章，即一致性的选择问题。众所周知，一致性是数据最关键的属性之一。2000年，Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论：

　 　Brewer, E. A. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon)

　　即分布式系统不可能满足一致性(C: Consistency)，可用性(A: Availability)和分区容错性(P: Tolerance of network Partition)这三个需求。

　　大约两年后，Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性：

　 　Gilbert , S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2)

　　几种常见的一致性类型有：

　　强一致性：系统中的某个数据被成功更新(事务成功返回)后，后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型，也是关系数据库深受人们喜爱的原因之一。

　　弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作得到的不一定是更新后的值，这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在：即数据更新完成后在经过这个“不一致性时间窗口”，后续读取操作就能够得到更新后的值。

　　最终一致性：属于弱一致性的一种，即某个数据被更新后，如果该数据后续没有被再次更新，那么最终所有的读取操作都会返回更新后的值。

　 　关于最终一致性，Werner Vogels提出了NWR模型(Eventually Consistent - Revisited, By Werner Vogels on December 23, 2008 12:15 AM, http://www.allthingsdistributed.com/2008/12/eventually_consistent.html)：

　　·N：数据复制的份数(the number of nodes that store replicas of the data)

　　·W：数据更新完成前需要到达的节点数(the number of replicas that need to acknowledge the receipt of the update before the update completes)

　　·R：为了读取正确数据需要读取的节点数(the number of replicas that are contacted when a data object is accessed through a read operation)

　　Werner Vogels还写到，如果W+R > N，那么读写节点有重叠，读总是能够得到最新的数据，这就是强一致性。在传统的一主一备同步复制的关系数据库中，N=2，W=2，R=1;在非同步复制模型中，W变成1，此时W+R=N，一致性也就无法保证。

　　不过，NWR模型只代表了一类情形，例如，在传统的一主一备的非同步复制的关系数据库中，尽管N=2，W=1，R=1，如果只有主库提供服务，则一致性仍然是保证的，不过主机异常时，服务的恢复不是实时的，因此CAP理论依然适用。

　 　在调研中，我们发现一些项目正在或倾向于弱一致性或最终一致性，咋看这似乎表明这些工程师偏爱弱一致性或最终一致性。然而，在经过仔细沟通和深入分析 后，我们发现，这些项目采用弱一致性或最终一致性，其实是在高数据量(十几亿条记录、数TB数据)和高访问量(数千TPS、数万QPS)需求压力之下的无 奈选择。如果两个系统都能满足上述高数据量和高访问量需求且成本差异不是很大，那么在强一致性和若一致性(或最终一致性)两者中他们会毫不犹豫地选择前 者。

　　显而易见，作为整个系统中最为基础的部件，如果数据库的数据是弱一致，那么上层应用就不得不承受这种弱一致导致的种种后果，从上层 应用的角度看，这并不是十分友善的行为。由于上述原因，我们决心在我们的海量数据库中实现与传统关系数据库相同的强一致性，因为我们相信这种强一致性不仅 会简化数据库的管理，减轻数据库管理的工作量，尤其重要的是，上层应用不再需要关注数据的不一致性，应用程序也会因此而简化，并且易于开发和维护。