系统技术非业余研究

原文地址：http://www.alibabatech.org/article/detail/3405/0?ticket=d69f07f8-b60b-43f8-9572-7d795bb8429d
作者：鸣嵩
PPT这里下载：

该文已在《程序员》2012年10期上发表。

MySQL作为一个低成本、高性能、可靠性好而且开源的数据库产品，在互联网企业应用非常广泛，例如淘宝网有数千台MySQL服务器的规模。虽然近两年来NoSQL的发展很快，新产品层出不穷，但在业务中应用NoSQL对开发者来说要求比较高，而MySQL拥有成熟的中间件、运维工具，已经形成一个良性的生态圈等，因此从现阶段来看，MySQL占主导性，NoSQL为辅。
在过去一年时间里，我们（阿里集团核心系统数据库团队）在MySQL托管平台方向做了大量工作，设计和实现了一套UMP(Unified MySQL Platform)系统，提供低成本和高性能的MySQL云数据服务。开发者从平台上申请MySQL实例资源，通过平台提供的单一入口来访问数据，UMP系统内部维护和管理资源池，以对用户透明的形式提供主从热备、数据备份、迁移、容灾、读写分离、分库分表等一系列服务。平台通过在一台物理机上运行多个MySQL实例的方式来降低成本，并且实现了资源隔离，按需分配和限制CPU、内存和IO资源，同时支持不影响提供数据服务的前提下根据用户业务的发展动态的扩容和缩容。

架构的演变
UMP系统第一版基于mysql-proxy 0.8版修复若干bug，并对proxy插件中管理用户连接和数据库连接的状态机流程进行一些修改，同时编写Lua脚本实现去中心数据库获取用户认证信息和后台数据库地址，对用户进行验证，建立到后台数据库的连接和转发数据包等逻辑。

图1 UMP系统的第一版采用MySQL Proxy

在开发和部署第一版的过程中，我们逐渐认识到几个问题：
Read more…

今天曲山同学在线上问道：

我测试发现，如果cp一个文件，然后direct io读这个文件，会消耗很长时间。
我猜测dio不能用page cache，而这个文件cp以后都在cache里面，要强制刷到磁盘，才能读？
我cp这个文件很大，超过256M

由于数据文件默认是用bufferedio方式打开的，也就是说它的数据是先缓冲在pagecache里面的，写入的数据会导致大量的脏页，而且这部分数据如果内核内存不紧张的话，是一直放在内存里面的的。我们知道directio是直接旁路掉pagecache直接发起设备IO的，也就是说在发起IO之前要保证数据是先落地到介质去，所以如果文件比较大的话，这个时间会比较长。从pagecahce的回写行为我们可以知道，只要脏页的数量不超过总内存的10%, 我们的机器有4G的内存，所以2个100M的文件总共才200M，不会导致writeback发生，我们可以很顺利的观察到这个现象。

有了上面的分析，下面我们来重现下这个问题。以下是我的步骤：
Read more…