用HSCALE实现MySQL的数据分布式存储
针对单个表过大造成的性能问题，MySQL在5.1开始引入了分区表(partition)，可以将数据在内部拆分存储，对应用透明，但是分区表只能将表在同一个数据库内部分解，而且对于表的维护(比如执行alter table)还是比较麻烦。手工分表也是一个解决方法，手工分表还有一个好处是可以将表分布到不同的服务器中，实现分布式存储。但是手工分表要求应用程序做相应的改写，以支持从不同的表中来存取数据。
HSCALE简单来说就是一个支持手工分表的中间层，对于应用来说看起来还是一个表，而由HSCALE来负责底层子表的数据存取。HSCALE是基于MySQL Proxy的一个插件应用，通过MySQL Proxy的lua脚本拦截分拆对应的SQL语句来实现数据的分布存储，而且使用lua脚本可以自由定制分表策略，比起MySQL自己的partition更加灵活些。现在版本还是0.2，功能有限，只能实现同库分表，但是基于MySQL Proxy的架构，未来要实现示分库分表也不是什么难事。
作者利用mysqlslap对HSCALE和MySQL Proxy做了几组性能测试，结果参考这里，还有这里。
当然，现在MySQL Proxy和HSCALE都是刚刚起步，要在产品库中应用还有很长的一段路要走，从上面的性能测试中可以看到基于最新的MySQL Proxy 0.7版的HSCALE性能有了较大的提升，期待后续版本有更好的表现。
MySQL Proxy工作机制浅析
MySQL Proxy处于客户端应用程序和MySQL服务器之间，通过截断、改变并转发客户端和后端数据库之间的通信来实现其功能，这和WinGate之类的网络代理服务器的基本思想是一样的。代理服务器是和TCP/IP协议打交道，而要理解MySQL Proxy的工作机制，同样要清楚MySQL客户端和服务器之间的通信协议，MySQL Protocol包括认证和查询两个基本过程：
认证过程包括：
- 客户端向服务器发起连接请求
- 服务器向客户端发送握手信息
- 客户端向服务器发送认证请求
- 服务器向客户端发送认证结果
如果认证通过，则进入查询过程：
- 客户端向服务器发起查询请求
- 服务器向客户端返回查询结果
当然，这只是一个粗略的描述，每个过程中发送的包都是有固定格式的，想详细了解MySQL Protocol的同学，可以去这里看看。MySQL Proxy要做的，就是介入协议的各个过程。首先MySQL Proxy以服务器的身份接受客户端请求，根据配置对这些请求进行分析处理，然后以客户端的身份转发给相应的后端数据库服务器，再接受服务器的信息，返回给客户端。所以MySQL Proxy需要同时实现客户端和服务器的协议。由于要对客户端发送过来的SQL语句进行分析，还需要包含一个SQL解析器。可以说MySQL Proxy相当于一个轻量级的MySQL了，实际上，MySQL Proxy的admin server是可以接受SQL来查询状态信息的。
MySQL Proxy通过lua脚本来控制连接转发的机制。主要的函数都是配合MySQL Protocol各个过程的，这一点从函数名上就能看出来：
- connect_server()
- read_handshake()
- read_auth()
- read_auth_result()
- read_query()
- read_query_result()
至于为什么采用lua脚本语言，我想这是因为MySQL Proxy中采用了wormhole存储引擎的关系吧，这个虫洞存储引擎很有意思，数据的存储格式就是一段lua脚本，真是创意无限啊。
使用MySQL Proxy和MySQL Replication实现读写分离
MySQL Replication可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。MySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多个proxy的连接参数即可。
