淘宝OceanBase分布式系统负载均衡案例分享.doc

淘宝：OceanBase分布式系统负载均衡案例分享 摘要：Heroku因“随机调度+Rails单线程处理导致延迟增加的负载均衡失败”的案例之后，我们在思考：在负载均衡测试时发现问题并妥善解决的成功经验有没有？于是，挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致负载不均问题，并通过加权算法妥善解决”的成功案例，也就是本文。 编者按： 在CSDN云计算频道日前所做的文章《响应高达6秒 用户揭露Heroku私自修改路由造成高支出》中，网友们认为这是“因随机调度+Rails的单线程处理导致延迟增加的负载均衡失败的案例”。但在负载均衡测试时就能发现问题并妥善解决的成功经验有没有？在随后的微博中，支付宝的@Leverly评论：“去年双11前的压测OB就发现了存在严重的随机访问导致负载不均问题，还好通过加权算法很好的解决了。” 引发了我们的关注，于是有了本文。重点是淘宝在“双十一”背后，OceanBase分布式系统负载均衡的经验分享。 以下为正文： 云计算所具备的低成本、高性能、高可用性、高可扩展性等特点与互联网应用日益面临的挑战不谋而合，成为近年来互联网领域的热门话题。作为一名技术人员不难理解在云计算的底层架构中，分布式存储是不可或缺的重要组成部分。国外知名的互联网公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存储系统，在国内OceanBase是淘宝自主研发的一个支持海量数据的高性能分布式数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务[1]。 在分布式系统中存在着著名的“短板理论”[2]，一个集群如果出现了负载不均衡问题，那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。为了避免这种情况的发生，需要动态负载均衡机制，以达到实时的最大化资源利用率，从而提升系统整体的吞吐。 本文将结合OceanBase的实际应用和大家分享一个去年淘宝双十一前期的准备工作中遇到负载均衡相关案例，抛砖引玉，期望对大家的工作有所启发。 OceanBase架构介绍 OceanBase是一个具有自治功能的分布式存储系统，由中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成[1]，如图1所示。 图1 OceanBase 架构图 Tablet：分片数据，最基本的存储单元，一般会存储多份，一个Table由多个tablet构成； RootServer：负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。 UpdateServer：负责存储动态更新数据，存储介质为内存和SSD，对外提供写服务； ChunkServer：负责存储静态Tablet数据，存储介质为普通磁盘或者SSD。 MergeServer：负责对查询中涉及多个Tablet数据进行合并，对外提供读服务； 在一个集群中，Tablet的多个副本分别存储在不同的ChunkServer，每个ChunkServer负责一部分Tablet分片数据，MergeServer和ChunkServer一般会一起部署。 双十一前期准备 对于淘宝的大部分应用而言，“双十一”就是一年一度的一次线上压测。伴随流量不断刷新着历史新高，对每个系统的可扩展性提出了很大的挑战。为了迎战双十一各产品线对有可能成为瓶颈部分的流量进行预估和扩容成为刻不容缓的任务。在本文要分享的案例中，应用方根据历史数据预估读请求的访问峰值为7w QPS，约为平时的5-6倍，合计每天支持56亿次的读请求。当时OceanBase集群部署规模是36台服务器，存储总数据量为200亿行记录，每天支持24亿次的读请求。 当前集群的读取性能远不能满足需求，我们首先进行了一次扩容，上线了10台Chunkserver/Mergeserver服务器。由于OceanBase本身具有比较强的可扩展性，为集群加机器是一件非常简单的操作。中心节点Rootserver在新机器注册上线后，会启动Rebalance功能以Tablet为单位对静态数据进行数据迁移，见下图的示意，最终达到所有ChunkServer上数据分片的均衡分布。 表 1. 某Table的Tablet列表 图2.1 Tablet在三台ChunkServer上的分布 图2.2加入一台机器Tablet迁移后的分布 扩容完成后引入线上流量回放机制进行压力测试，以验证当前集群的性能是否可以满足应用的双十一需求。我们使用了10台服务器，共2000-4000个线程并发回放线上读流量对集群进行压测，很快发现集群整体的QPS在达到4万左右后，压测客户端出现