一个大型MySQL分布式系统诞生

from  http://zhaolinjnu.blog.sohu.com/116545760.html

    在淘宝，有一个业务系统，在一年半以前，这个业务系统很小，访问量很低，相关的表跟核心数据库放在一起，后来由于产品升级，新产品的许多功能很受会员的喜爱，会员大量使用，很快就对核心数据库造成了相当程度的IOPS冲击与威胁，也迅速消耗着核心存储的空间，为了不影响淘宝的核心业务，我们将此业务相关的表迁移出了核心库，创建了一个独立的ORACLE数据库，这种拆分数据库的方式，就是大家常说的垂直拆分。

    这种拆分方式，对上层业务应用程序变动很小，只是需要改一下数据库连接而已。尽管数据库独立了，但从本质上来讲，并没有优化这个业务的数据库。在新的数据库里，此产品仍然在高速发展，每天都制造着大量的数据，表和索引越来越大，存储空间达到了T级。由于此业务访问的离散性，对存储IOPS消耗极高，占用了大量的宝贵的存储资源。为了减少这种消耗，我们首先在业务层面进行了优化，拿掉了一些不必要的产品功能，并加入了一些限制，控制了一部份不正常的数据增长；在数据库层面，通过观察SQL，发现了应用程序中可以改进的业务逻辑以及进行必要有索引调整；还有对有些业务点加上适当的前端的Cache策略。通过以上的改进，在一定程度上缓解了整个系统的压力。

     对整个系统的根本性改造，我们一直在探索。对于技术出身的我们来说，一个小小的xx业务系统，占用了这么多的昂贵的存储硬件资源与ORACLE软件资源，心里总有一些不平静，要去改造它。而且这个业务系统仍然在不断的膨胀，好几个表的数据都超过了十亿级，进行索引调整的难度越来越大，对于前端业务的不断变化，这种调整又是必须的。采用集中式的ORACLE数据库方式，在前期，会在相当程度上减少前端应用程序的复杂性，但到了一定的规模过后，你会发现你要付出的代价也会呈指数级的增长，可维护性在逐渐降低。而且在这种高IOPS，高并发的情况下，数据库也会很容易出问题。

     从去年开始，taobao开始在一些小系统上采用MySQL数据库，但使用的方式跟ORACLE并没有什么不同。搭建master-slave主从复制结构，应用程序访问master，slave只起到接管的作用。为了改造这个业务系统，采用这么简单的结构是不行的。我们确立了几点目标，第一搭建一个分布式集群；第二集群采用廉价的PC；第三实现读写分离，slave也要承担一定的业务读；第四是用内存来支撑IOPS，不是硬盘。对于此项目业务的数据库，根据什么规则做sharding，又是摆在我们面前一个问题？在做这个架构设计的时候，我们sharding的原则，是要保证大量的访问都是在单库上完成的，不需要跨库merge与sort。我们确立了基本方案过后，联合开发与架构，细化了设计方案，在几个月前，开始了这场攻坚。

    因为是要对大表做数据的水平拆分，将数据拆分到多个数据库上，有几个重要的问题需要思考：
1.怎么把在ORACLE中几十亿的数据按规则迁到mysql集群中；
2.如何产生主键唯一值；
3.大表根据规则拆成小表，具体拆分粒度是多少？每个库多少表？
4.如何解决这么多库这么多表的路由问题；
5.如何解决跨库的merge与sort；
6.如何对连接进行管理；
7.如何做数据订正；
8.我们需要开发哪些集群管理工具，比如说建表工具；
9.集群遇到停电怎么办？
10.如何对集群中的数据进行历史迁移？
11.尽管集群采用廉价的PC，但具体采用何种PC,差别还是挺大的，如何平衡集群的规模与可管理性方面的问题?
12.集群对机房电力的消耗与机柜占用问题?

    在项目进行期间，DBA团队先后进行了几次数据迁移测试，在数据仓库与SA团队的帮助下，尽管经历了一些困难与挑战，但最终这些问题，大都一一解决。这个项目先后进行了三次程序发布，发布期间平滑迁移数据32亿条左右，感谢负责此项目的DBA同事们与可敬可爱的开发工程师们。这个项目，也使得我们的分布式中间件有了进一步的发展与完善，大大减化了上层业务系统开发的复杂度，不必关心下层业务数据的存放逻辑，感谢架构团队的精益求精。

    项目发布后，经过观察，各库不管是master与slave,负载基本相同，但集群中各库负载基本上都在6以上，稍微有点偏高。进行了一些SQL调化，主要是索引调整后，负载降到2以下。说起索引调整，这也是第一次对这么大的mysql集群做DDL，做一次大概需要好几个小时。这个时间消耗，超过了自己的预期。

    项目一期已经完成，二期很快又会启动，如果你想不断挑战自我，实现自我价值，加入淘宝DBA团队，这里有一流的环境，成为一名优秀的mysql DBA指日可待。