mysql分布式存储方案
① Mysql Mycat 分布式架构
参考： https://www.jianshu.com/p/5e0062f6cf62
图中是两组分片，红色我们称为shard1，蓝色我们称为shard2
51 52是服务器
两个3307互为主从(双主)，3309是本地3307的从库
说明：没有明确说明是只在某一个节点上做的，就是两个节点都做
两台虚拟机 db01 db02
每台创建四个mysql实例：3307 3308 3309 3310
mysql软件我们之前已完成二进制安装，直接初始化即可
我们server-id规划为：db01上是7/8/9/10,db02上是17/18/19/20
"箭头指向谁是主库"
10.0.0.51:3307 <-----> 10.0.0.52:3307
10.0.0.51:3309 ------> 10.0.0.51:3307
10.0.0.52:3309 ------> 10.0.0.52:3307
两个分片，每个分片四个mysql节点
shard1：
Master：10.0.0.51:3307
slave1：10.0.0.51:3309
Standby Master：10.0.0.52:3307
slave2：10.0.0.52:3309
shard2：
Master：10.0.0.52:3308
slave1：10.0.0.52:3310
Standby Master：10.0.0.51:3308
slave2：10.0.0.51:3310
shard1
10.0.0.51:3307 <-----> 10.0.0.52:3307
db02
db01
db02
10.0.0.51:3309 ------> 10.0.0.51:3307
db01
10.0.0.52:3309 ------> 10.0.0.52:3307
db02
shard2
10.0.0.52:3308 <-----> 10.0.0.51:3308
db01
db02
db01
10.0.0.52:3310 -----> 10.0.0.52:3308
db02
10.0.0.51:3310 -----> 10.0.0.51:3308
db01
这个复制用户在谁上建都行
注：如果中间出现错误，在每个节点进行执行以下命令
常见方案：
360 Atlas-Sharding 360
Alibaba cobar 阿里
Mycat 开源
TDDL 淘宝
Heisenberg 网络
Oceanus 58同城
Vitess 谷歌
OneProxy
DRDS 阿里云
我们装的是openjdk，不是官方的那个
Mycat-server-xxxxx.linux.tar.gz
http://dl.mycat.io/
配置环境变量
我们mycat的命令也是在bin目录下
启动
8066就是对外提供服务的端口，9066是管理端口
连接mycat：
默认123456
db01:
我们一般先把原schema.xml备份，然后自己新写一个：
xml和html看起来差不多，xml是从下往上调用的
前三行我们不用看，直接从第四行schema开始看起：
定义了schema，然后以/schema结尾
为什么要用逻辑库？
业务透明化
此配置文件就是实现读写分离的配置
重启mycat
读写分离测试
总结：
以上案例实现了1主1从的读写分离功能，写操作落到主库，读操作落到从库.如果主库宕机，从库不能在继续提供服务了。
我们推荐这种架构
一写三读，
不设置双写的原因是：性能没提升多少，反而引起主键冲突的情况
配置文件：
之后重启：mycat restart
真正的 writehost：负责写操作的writehost
standby writeHost ：和readhost一样，只提供读服务
我们此处写了两个writehost，默认使用第一个
当写节点宕机后，后面跟的readhost也不提供服务，这时候standby的writehost就提供写服务，
后面跟的readhost提供读服务
测试：
读写分离测试
对db01 3307节点进行关闭和启动,测试读写操作
结果应为另一台(52)的3307(17)是写，3309(19)是读
一旦7号节点恢复，此时因为7落后了，写节点仍是17
balance属性
负载均衡类型，目前的取值有3种：
writeType属性
负载均衡类型，目前的取值有2种：
switchType属性
-1 表示不自动切换
1 默认值，自动切换
2 基于MySQL主从同步的状态决定是否切换 ，心跳语句为 show slave status
datahost其他配置
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1">
maxCon="1000"：最大的并发连接数
minCon="10" ：mycat在启动之后，会在后端节点上自动开启的连接线程，长连接，好处是连接速度快，弊端是占内存
tempReadHostAvailable="1"
这个一主一从时（1个writehost，1个readhost时），可以开启这个参数，如果2个writehost，2个readhost时
<heartbeat>select user()</heartbeat> 监测心跳
其他参数sqlMaxLimit自动分页,必须在启用分表的情况下才生效
创建测试库和表:
我们重启mycat后连接到8066
发现跟一个库一样，实际上已经分到不同的物理硬件上了
分片：对一个"bigtable"，比如说t3表
热点数据表 核心表
(1)行数非常多，800w下坡
(2)访问非常频繁
分片的目的：
（1）将大数据量进行分布存储
（2）提供均衡的访问路由
分片策略：
范围 range 800w 1-400w 400w01-800w 不适用于业务访问不均匀的情况
取模 mod (取余数) 和节点的数量进行取模
枚举 按枚举的种类分，如移动项目按省份分
哈希 hash
时间 流水
优化关联查询（否则join的表在不同分片上，效率会比单库还要低）
全局表
ER分片
案例：移动统一：先拆出边缘业务，再按地域分片，但对应用来说是统一的
vim rule.xml
<tableRule name="auto-sharding-long">
<rule>
<columns>id</columns>
<algorithm>rang-long</algorithm>
</rule>
<function name="rang-long"
class="io.mycat.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
</function>
===================================
vim autopartition-long.txt
0-10=0
11-20=1
创建测试表：
mysql -S /data/3307/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"
测试：
重启mycat
mycat restart
mysql -uroot -p123456 -h 127.0.0.1 -P 8066
insert into t3(id,name) values(1,'a');
insert into t3(id,name) values(2,'b');
insert into t3(id,name) values(3,'c');
insert into t3(id,name) values(4,'d');
insert into t3(id,name) values(11,'aa');
insert into t3(id,name) values(12,'bb');
insert into t3(id,name) values(13,'cc');
insert into t3(id,name) values(14,'dd');
取余分片方式：分片键（一个列）与节点数量进行取余，得到余数，将数据写入对应节点
vim schema.xml
<table name="t4" dataNode="sh1,sh2" rule="mod-long" />
vim rule.xml
<property name="count">2</property>
准备测试环境
创建测试表：
mysql -S /data/3307/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"
重启mycat
mycat restart
测试：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t4(id,name) values(1,'a');
insert into t4(id,name) values(2,'b');
insert into t4(id,name) values(3,'c');
insert into t4(id,name) values(4,'d');
分别登录后端节点查询数据
mysql -S /data/3307/mysql.sock
use taobao
select * from t4;
mysql -S /data/3308/mysql.sock
use taobao
select * from t4;
t5 表
id name telnum
1 bj 1212
2 sh 22222
3 bj 3333
4 sh 44444
5 bj 5555
sharding-by-intfile
vim schema.xml
<table name="t5" dataNode="sh1,sh2" rule="sharding-by-intfile" />
vim rule.xml
<tableRule name="sharding-by-intfile">
<rule> <columns>name</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name="hash-int" class="org.opencloudb.route.function.PartitionByFileMap">
<property name="mapFile">partition-hash-int.txt</property>
<property name="type">1</property>
<property name="defaultNode">0</property>
</function>
partition-hash-int.txt 配置：
bj=0
sh=1
DEFAULT_NODE=1
columns 标识将要分片的表字段，algorithm 分片函数， 其中分片函数配置中，mapFile标识配置文件名称
准备测试环境
mysql -S /data/3307/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"
重启mycat
mycat restart
mysql -uroot -p123456 -h10.0.0.51 -P8066
use TESTDB
insert into t5(id,name) values(1,'bj');
insert into t5(id,name) values(2,'sh');
insert into t5(id,name) values(3,'bj');
insert into t5(id,name) values(4,'sh');
insert into t5(id,name) values(5,'tj');
a b c d
join
t
select t1.name ,t.x from t1
join t
select t2.name ,t.x from t2
join t
select t3.name ,t.x from t3
join t
使用场景：
如果你的业务中有些数据类似于数据字典，比如配置文件的配置，
常用业务的配置或者数据量不大很少变动的表，这些表往往不是特别大，
而且大部分的业务场景都会用到，那么这种表适合于Mycat全局表，无须对数据进行切分，
要在所有的分片上保存一份数据即可，Mycat 在Join操作中，业务表与全局表进行Join聚合会优先选择相同分片内的全局表join，
避免跨库Join，在进行数据插入操作时，mycat将把数据分发到全局表对应的所有分片执行，在进行数据读取时候将会随机获取一个节点读取数据。
vim schema.xml
<table name="t_area" primaryKey="id" type="global" dataNode="sh1,sh2" />
后端数据准备
mysql -S /data/3307/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null);
mysql -S /data/3308/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null);
重启mycat
mycat restart
测试：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t_area(id,name) values(1,'a');
insert into t_area(id,name) values(2,'b');
insert into t_area(id,name) values(3,'c');
insert into t_area(id,name) values(4,'d');
A
join
B
为了防止跨分片join，可以使用E-R模式
A join B
on a.xx=b.yy
join C
on A.id=C.id
<table name="A" dataNode="sh1,sh2" rule="mod-long">
<childTable name="B" joinKey="yy" parentKey="xx" />
</table>
当前做分布式的厂商有几家，我知道比较出名的有“华为云分布式数据库DDM”和“阿里云分布式数据库”，感兴趣可以自行搜素了解下。
分布式数据库的几点概念可以了解一下。
数据分库：
以表为单位，把原有数据库切分成多个数据库。切分后不同的表存储在不同的数据库上。
以表中的数据行记录为单位，把原有逻辑数据库切分成多个物理数据库分片，表数据记录分布存储在各个分片上。
路由分发：
在分布式数据库中，路由的作用即将SQL语句进行解析，并转发到正确的分片上，保证SQL执行后得到正确的结果，并且节约QPS资源。
读写分离：
数据库中对计算和缓存资源消耗较多的往往是密集或复杂的SQL查询。当系统资源被查询语句消耗，反过来会影响数据写入操作，进而导致数据库整体性能下降，响应缓慢。因此，当数据库CPU和内存资源占用居高不下，且读写比例较高时，可以为数据库添加只读数据库。
③ Mysql数据库3种存储引擎有什么区别
MySQL常见的三种存储引擎为InnoDB、MyISAM和MEMORY。其区别体现在事务安全、存储限制、空间使用、内存使用、插入数据的速度和对外键的支持。具体如下：
1、事务安全：
InnoDB支持事务安全，MyISAM和MEMORY两个不支持。
2、存储限制：
InnoDB有64TB的存储限制，MyISAM和MEMORY要是具体情况而定。
3、空间使用：
InnoDB对空间使用程度较高，MyISAM和MEMORY对空间使用程度较低。
4、内存使用：
InnoDB和MEMORY对内存使用程度较高，MyISAM对内存使用程度较低。
5、插入数据的速度：
InnoDB插入数据的速度较低，MyISAM和MEMORY插入数据的速度较高。
6、对外键的支持：
InnoDB对外键支持情况较好，MyISAM和MEMORY两个不支持外键。
三种引擎特点如下：
1、InnoDB存储引擎
InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），其它存储引擎都是非事务安全表，支持行锁定和外键，MySQL5.5以后默认使用InnoDB存储引擎。
InnoDB特点： 支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。
如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。
2、MyISAM存储引擎
MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但不支持事务，不支持外键。
MyISAM特点： 插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比较低，也可以使用
3、MEMORY存储引擎
MEMORY存储引擎将表中的数据存储到内存中，为查询和引用其他表数据提供快速访问。
MEMORY特点： 所有的数据都在内存中，数据的处理速度快，但是安全性不高。如果需要很快的读写速度，对数据的安全性要求较低，可以选择MEMOEY。
它对表的大小有要求，不能建立太大的表。所以，这类数据库只使用在相对较小的数据库表。
(3)mysql分布式存储方案扩展阅读：
mysql其余不太常见的存储引擎如下：
1、BDB： 源自Berkeley DB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性
2、Merge ：将一定数量的MyISAM表联合而成一个整体，在超大规模数据存储时很有用
3、Archive ：非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差
4、Federated： 将不同的Mysql服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用
5、Cluster/NDB ：高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用
6、CSV： 逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个.CSV文件。这是一种普通文本文件，每个数据行占用一个文本行。CSV存储引擎不支持索引。
7、BlackHole ：黑洞引擎，写入的任何数据都会消失，一般用于记录binlog做复制的中继
④ 一个数据库有两张表，同步两张表的数据
如果是同一个mysql服务端的两个数据库同步可考虑下触发器，如果是不同端口的两个mysql服务端跟在两台服务器同步配置上没有区别。
数据库最好不要做主从，不然性能会降低很多的。
可以采取其他的方法撒，比如分布式存储。可以考虑下memcachedb，实现持久存储。
表结构一致的话，可以考虑映射表去实现来的（shell脚本定时同步，触发器），不过shell脚本会将环境搞的复杂一点，维护也会相对麻烦.
映射表具体实现（在要同步的数据库下创建相同的表结构）：
CREATE TABLE table_name
(
column_name column_type ....
....
key ....
)
ENGINE=MYISAM DEFAULT CHARSET=utf8
CONNECTION="mysql://user:pwd@ip_address/db_name/table_name";
⑤ 单机MySQL数据库怎么做成分布式数据库集群
"可以采用开源的MyCat解决方案，优点是免费，缺点是出现问题可能要自己解决或者去社区寻找解决方案；
也可以采用北京万里开源软件有限公司的集群解决方案，后端使用开源的MySQL存储数据，优点是有任何问题他们都可以帮忙解决，而且不用担心系统后续的扩展、集群高可用等情况，他们的工程师还开发过MySQL核心代码，找他们可以睡个安稳觉，缺点是不免费，他们还有自己的国产数据库GreatDB，100%兼容MySQL。
对于初创企业，可以考虑选择免费的开源解决方案，毕竟遇到的问题可能有限，如果要想长期稳定发展，还是选择万里开源这样的公司比较靠谱一些。"
⑥ 一个大型、稳健、成熟的分布式系统的背后，往往会涉及众多的支撑系统基础设施
树苗中2包是需要混合浸泡吗？一个大型、稳健、成熟的分布式系统的背后，往往会涉及众多的支撑系统，我们将这些支撑系统称为分布式系统的基础设施。除了前面所介绍的分布式协作及配置管理系统ZooKeeper,我们进行系统架构设计所依赖的基础设施，还包括分布式缓存系统、持久化存储、分布式消息系统、搜索引擎，以及CDN系统、负载均衡系统、运维自动化系统等，还有后面章节所要介绍的实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。
分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显着提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。
⑦ 分布式缓存是什么
分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显着提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。
⑧ MySQL的sharding的程序是不是要自己开发的
不一定需要自己开发。Shard层可以位于：
1、DAO层：一般需要自行开发，可以灵活定制
2、ORM层：比如guzz、Hibernate Shard
3、JDBC API层：比较难，有一个商业产品dbShards
4、应用服务器与数据库之间通过代理实现：MySQL Proxy、amoeba.....
一 背景
当数据库中的数据量越来越大时，不论是读还是写，压力都会变得越来越大。采用MySQL
Replication多master多slave方案，在上层做负载均衡，虽然能够一定程度上缓解压力。但是当一张表中的数据变得非常庞大时，压力还是
非常大的。试想，如果一张表中的数据量达到了千万甚至上亿级别的时候，不管是建索引，优化缓存等，都会面临巨大的性能压力。
二 定义
数据sharding，也称作数据切分，或分区。是指通过某种条件，把同一个数据库中的数据分散到多个数据库或多台机器上，以减小单台机器压力。
三 分类
数据分区根据切分规则，可以分为两类：
1、垂直切分
数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成，我们垂直的将这些“数据块”切开，然后将他们分散
到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。以表为单位，把不同的表分散到不同的数据库或主机上。规则简单，实施方便，适合业
务之间耦合度低的系统。
Sharding详解" title="MySQL Sharding详解" height="373" width="553">
垂直切分的优点
(1)数据库的拆分简单明了，拆分规则明确;
(2)应用程序模块清晰明确，整合容易;
(3)数据维护方便易行，容易定位;
垂直切分的缺点
(1)部分表关联无法在数据库级别完成，需要在程序中完成;
(2)对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求;
(3)事务处理相对更为复杂;
(4) 切分达到一定程度之后，扩展性会遇到限制;
(5)过读切分可能会带来系统过渡复杂而难以维护。
2、水平切分
一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。以行为单位，将同一个表中的数据按照某种条件拆分到不同的数据库或主机上。相对复杂，适合单表巨大的系统。
Sharding详解" title="MySQL Sharding详解" height="372" width="553">
水平切分的优点
(1)表关联基本能够在数据库端全部完成;
(2)不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;
(3)应用程序端整体架构改动相对较少;
(4)事务处理相对简单;
(5)只要切分规则能够定义好，基本上较难遇到扩展性限制;
水平切分的缺点
(1)切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则;
(2)后期数据的维护难度有所增加，人为手工定位数据更困难;
(3)应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。
3、联合切分
实际的应用场景中，除了那些负载并不是太大，业务逻辑也相对较简单的系统可以通过上面两种切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑稍微
复杂一点，系统负载大一些的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，而需要将上述两种切分方法结合使用，不同的场景使用不同的切
分方法。
Sharding详解" title="MySQL Sharding详解" height="480" width="342">
联合切分的优点
(1)可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;
(2)让系统扩展性得到最大化提升;
联合切分的缺点
(1)数据库系统架构比较复杂，维护难度更大;
(2)应用程序架构也相对更复杂;
四 实现方案
现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，此处只作一下简要的介绍。
1、 Mysql Proxy + HASCALE
一套比较有潜力的方案。其中MySQL Proxy 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy
的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用
Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE
各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。
MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer一样，同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。
实际上，MySQLProxy本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写LUA脚本来实现。
MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy，然后经由MySQLProxy进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图：
Sharding详解" title="MySQL Sharding详解" height="480" width="420">
通过上面的架构简图，我们可以很清晰的看出MySQLProxy在实际应用中所处的位置，以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读，我这里就不累述浪费纸张了。
http://forge.mysql.com/wiki/MySQL_Proxy
2、 Hibernate Shards
这是 Google 技术团队贡献的项目(http://www.hibernate.org/414.html)，该项目是在对Google 财务系统数据
Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate
就能搞定，技术成本较低;相对弹性的 Sharding 策略以及支持虚拟 Shard 等。
3、 Spock Proxy
这也是在实际需求中产生的一个开源项目，基于Mysql Proxy扩展。Spock(http://www.spock.com/)是一个人员查找的 Web
2.0 网站。通过对自己的单一 DB 进行有效 Sharding化 而产生了Spock
Proxy(http://spockproxy.sourceforge.net/ ) 项目，Spock Proxy 算得上 MySQL Proxy
的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以Spock Proxy 也是基于 Rails 构建，关注 ROR
的朋友不应错过这个项目。
http://spockproxy.sourceforge.net/
4、 Amoeba for MySQL
Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。目前，Amoeba已经具有Query路由，Query过滤，读写分离，负载均衡以及HA机制等相关内容。
Amoeba 主要解决的以下几个问题：
(1)数据切分后复杂数据源整合;
(2)提供数据切分规则并降低数据切分规则给数据库带来的影响;
(3)降低数据库与客户端的连接数;
(4)读写分离路由。
我们可以看出，Amoeba所做的事情，正好就是我们通过数据切分来提升数据库的扩展性所需要的。
Amoeba并不是一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的开发框架，目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。
AmoebaForMySQL主要是专门针对MySQL数据库的解决方案，前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说，AmoebaForMySQL和一个MySQL数据库没有什么区别，任何使用MySQL协议的客户端请求，都可以被AmoebaForMySQL解析并进行相应的处理。下如可以告诉我们AmoebaForMySQL的架构信息(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384">
AmoebaForAladin则是一个适用更为广泛，功能更为强大的Proxy程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务，但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说，只要前端应用程序通过MySQL协议连接上来之后，AmoebaForAladin会自动分析Query语句，根据Query语句中所请求的数据来自动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384">
咋一看，两者好像完全一样嘛。细看之后，才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后，根据分析结果判断出数据源数据库，然后选择特定的JDBC驱动和相应协议连接后端数据库。
其实通过上面两个架构图大家可能也已经发现了Amoeba的特点了，他仅仅只是一个开发框架，我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外，还可以基于自身的需求进行相应的二次开发，得到更适应我们自己应用特点的Proxy程序。
当对于使用MySQL数据库来说，不论是AmoebaForMySQL还是AmoebaForAladin都可以很好的使用。当然，考虑到任何一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会相对更高一些。所以，对于仅仅需要使用MySQL数据库的时候，我还是建议使用AmoebaForMySQL。
AmoebaForMySQL的使用非常简单，所有的配置文件都是标准的XML文件，总共有四个配置文件。分别为：
(1)amoeba.xml：主配置文件，配置所有数据源以及Amoeba自身的参数设置;
(2)rule.xml：配置所有Query路由规则的信息;
(3)functionMap.xml：配置用于解析Query中的函数所对应的Java实现类;
(4)rullFunctionMap.xml：配置路由规则中需要使用到的特定函数的实现类;
如果您的规则不是太复杂，基本上仅需要使用到上面四个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离，负载均衡等配置都在amoeba.xml中进行。此外，Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由，路由规则可以在rule.xml进行设置。
目前Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了，曾经在与相关开发者的沟通过程中提出过相关的建议，希望能够提供一个可以进行在线维护管理的命令行管理工具，方便在线维护使用，得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面暂时还是Amoeba无法做到的，即使客户端应用在提交给Amoeba的请求是包含事务信息的，Amoeba也会忽略事务相关信息。当然，在经过不断完善之后，我相信事务支持肯定是Amoeba重点考虑增加的feature。
关于Amoeba更为详细的使用方法读者朋友可以通过Amoeba开发者博客(http://amoeba.sf.net)上面提供的使用手册获取，这里就不再细述了。
案例(http://pengranxiang.iteye.com/blog/1145342)
操作文档(http://docs.hexnova.com/amoeba/chap-getting-started.html)
5、 HiveDB
和前面的MySQLProxy以及Amoeba一样，HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。
HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异，他并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现的数据切分工作。
在HiveDB中，通过用户自定义的各种Partitionkeys(其实就是制定数据切分规则)，将数据分散到多个MySQLServer中。在访问的时候，在运行Query请求的时候，会自动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给客户端应用程序。
单纯从功能方面来讲，HiveDB可能并不如MySQLProxy和Amoeba那样强大，但是其数据切分的思路与前面二者并无本质差异。此外，HiveDB并不仅仅只是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。
下面是HiveDB官方网站上面一章图片，描述了HiveDB如何来组织数据的基本信息，虽然不能详细的表现出太多架构方面的信息，但是也基本可以展示出其在数据切分方面独特的一面了。
Sharding详解" title="MySQL Sharding详解" height="471" width="553">
http://www.hivedb.org/
6、 DataFabric
application-level sharding
master/slave replication
https://github.com/bpot/data_fabric
7、PL/Proxy
前面几个都是针对MySQL 的 Sharding 方案，PL/Proxy 则是针对 PostgreSQL 的，设计思想类似 Teradata 的
Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发。 PL/Proxy
的设计初衷就是在这一层充当”数据总线”的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。大名鼎鼎的 Skype 用的就是
PL/Proxy 的解决方案。
8、Pyshards
这是个基于Python的解决方案。该工具的设计目标还有个 Re-balancing 在里面，这倒是个比较激进的想法。目前只支持 MySQL
数据库。
http://code.google.com/p/pyshards/wiki/Pyshards
9、其他实现数据切分及整合的解决方案
除了上面介绍的几个数据切分及整合的整体解决方案之外，还存在很多其他同样提供了数据切分与整合的解决方案。如基于MySQLProxy的基础上做了进一步扩展的HSCALE，通过Rails构建的SpockProxy，以及基于Pathon的Pyshards等等。
不管大家选择使用哪一种解决方案，总体设计思路基本上都不应该会有任何变化，那就是通过数据的垂直和水平切分，增强数据库的整体服务能力，让应用系统的整体扩展能力尽可能的提升，扩展方式尽可能的便捷。
只要我们通过中间层Proxy应用程序较好的解决了数据切分和数据源整合问题，那么数据库的线性扩展能力将很容易做到像我们的应用程序一样方便，只需要通过添加廉价的PCServer服务器，即可线性增加数据库集群的整体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。
五 注意事项
下面我们所说的分区，主要是指水平分区。
1、在实施分区前，我们可以查看所安装版本的mysql是否支持分区：
mysql> show variables like "%partition%";
如果支持则会显示：
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| have_partitioning | YES |
+-------------------+-------+
2、分区适用于一个表的所有数据和索引，不能只对数据分区而不对索引分区，反之亦然，同时也不能只对表的一部分进行分区。
3、分区类型
(1)RANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区。
(2)LIST 分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。
(3)HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算(新浪微博采用的方案)。
(4)KEY 分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL
服务器提供其自身的哈希函数。必须有一列或多列包含整数值。
无论使用何种类型的分区，分区总是在创建时就自动的顺序编号，且从0开始记录。当有一新行插入到一个分区表中时，就是使用这些分区编号来识别正确的分区。
4、MySQL提供了许多修改分区表的方式。添加、删除、重新定义、合并或拆分已经存在的分区是可能的。所有这些操作都可以通过使用ALTER TABLE
命令的分区扩展来实现。
5、可以对已经存在的表进行分区，直接使用alter table命令即可。