中间件MyCAT自己之前也简单测试过，总结过。最近做分布式测试，我大体分了三个阶段：
一.环境部署，MHA和MyCAT的融合，读写分离
二.sharding策略和分库分表的压力测试
三.结合业务做分库分表的模拟测试
尤其是分库分表的测试方面，目前还是存在一些需要确认的点。
我在测试之前所想，做这个分布式测试的意义是什么？是想通过测试来论证什么，希望达到什么目标，是否稳定，功能是否满足需求，这些都是需要反复明确的地方。
当然，这些我没有留太多的时间下来，我希望是速战速决，但是测试质量还是需要基本保证，那就是测试的场景基本要全面一些。
测试工具的选择上，我目前先选择了sysbench,原生支持，操作起来相对容易控制，尤其是支持的场景很丰富，在一些流水型数据的业务中，我如果侧重测试密集型插入的场景，就可以很轻松的使用insert的模板来测试。
MyCAT的部署上本身是很简单的，无非是一些基本的环境配置。如果是一个新手，从安装Java到部署MyCAT,如果全程跟进，基本两个小时都能够拿下来。部署安装参见之前的一篇文章Mycat读写分离配置实践
而sharding策略的配置还是需要花一些时间的，首先是你得理解它的sharding逻辑。大体明白之后，事情就很简单了。
测试的场景，我是这样来规划的，首先在3个物理机上面部署了MySQL服务，每个服务器是一个sharding节点，然后有另外一台服务器部署了MyCAT,这样就是一个简单的分布式sharding环境。
要压测基本的性能情况，有几种测试的方法，假设测试的表为：sharding_table,存在的数据库为db1,db2,db3,db4
测试的场景就会很丰富.
场景1：
场景2：
在之前的基础上进行扩展，按照这个进度，基本就是3N的方式，所以就会有3,6,9,12这样的一些分布方式，这样的好处就是前期规划了，后期如果出现瓶颈，可以很方便的拆分。
要完成这些工作，每个场景测试偷工减料测试几分钟也是不行的，每个场景最起码得1个小时，按照这个要求，至少得20个小时，人是铁饭是钢，我不能一直守在那里。所以就在下班前写了个脚本，让它慢慢跑吧，明天上班收数。
我前期做了快速迭代，把每个场景都大体跑了下，得到了一个基本的数据分布，然后细化到每个场景一个小时来收到相对完整的数据情况。
脚本如下，我配置了10个sbtest[N]的表,如果是做分片，3个服务器节点切分成12个sharding分片，那就是120个表。测试的场景我是分为不同的sharding分片，不同的线程数。需要提前配置下rules.xml和schema.xml我是准备了好几份这个配置文件，到时候直接替换就行。
#!/bin/bash
time=3600
sleep_time=60
function clean_data
{
echo $time
echo ${sleep_time}
mysql -umycat_user -pmycat_user -P8066 -h127.0.0.1 <<EOF
use sbtestdb1
delete from sbtest1;
delete from sbtest2;
delete from sbtest3;
delete from sbtest4;
delete from sbtest5;
delete from sbtest6;
delete from sbtest7;
delete from sbtest8;
delete from sbtest9;
delete from sbtest10;
EOF
sleep ${sleep_time}
}
function sysbench_test
{
clean_data
shard_no=$1
thread_no=$2
/usr/bin/sysbench /usr/share/sysbench/oltp_insert.lua --db-driver=mysql
--mysql_storage_engine=innodb --mysql-user=mycat_user
--mysql-password=xxxx --mysql-port=8066 --mysql-host=127.0.0.1
--mysql-db=sbtestdb1 --auto_inc=1 --tables=10 --table-size=50000000
--threads=${thread_no} --time=$time --report-interval=5
run |tee sysbench_${thread_no}_sharding_${shard_no}.log
sleep ${sleep_time}
}
function change_sharding
{
shard_no=$1
date
echo 'SHARDING_NO:'${shard_no}
mv /usr/local/mycat/conf/schema.xml /usr/local/mycat/conf/schema.xml.tmp >/dev/null
cp /usr/local/mycat/conf/schema.xml.sharding_${shard_no} /usr/local/mycat/conf/schema.xml >/dev/null
/usr/local/mycat/bin/mycat restart >/dev/null
sleep ${sleep_time}
}
change_sharding 12
sysbench_test 12 16
sysbench_test 12 32
sysbench_test 12 64
sysbench_test 12 98
sysbench_test 12 128
change_sharding 9
sysbench_test 9 16
sysbench_test 9 32
sysbench_test 9 64
sysbench_test 9 98
sysbench_test 9 128
change_sharding 6
sysbench_test 6 16
sysbench_test 6 32
sysbench_test 6 64
sysbench_test 6 98
sysbench_test 6 128
change_sharding 3
sysbench_test 3 16
sysbench_test 3 32
sysbench_test 3 64
sysbench_test 3 98
sysbench_test 3 128感兴趣的也可以自己测试一下。从我目前测试的数据来说，这种方案效果还是很威猛的。
相关文章：
压测工具swingbench和sysbench对比(r12笔记第13天)
使用sysbench压力测试MySQL（三）(r12笔记第6天)
