存储贝海拾珠(上).pdfVIP

1 业务的挑战 2 2 一致性选择 3 3 事务的ACID 4 4 系统架构(一) 5 5 系统架构(二) 6 6 数据结构 7 7 读写事务 8 8 破解随机IO 难题 9 9 克服单点失效(一) 11 10 克服单点失效(二) 12 11 解决单点瓶颈(一) 13 12 解决单点瓶颈(二) 14 13 每日合并 15 14 故障恢复 17 15 数据校验 18 16 负载平衡 19 17 联表实现 20 1 1 业务的挑战 作为一个电子商务企业，从一开始，数据库及其事务能力在淘宝就扮演着十分关键的角色，淘宝也积累了丰富的数 据库的架构和规划等方面的经验，产生了众多优秀的DBA。 淘宝是一家迅速发展的公司。全球网站排名公司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 是淘宝自主研发的海量数据库，并且已经开源( / ) 。在应用团队和OceanBase 团队的共同努力下，上述问题得到了很好地解决：平均响应时间几十毫秒，最长响应时间一百多毫秒。与先前使用 的关系数据库相比，系统QPS 和TPS 提升了几倍，服务器数量反而减少了。 2 2 一致性选择 众所周知，一致性是数据最关键的属性之一。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. Brewers conjecture