小试mysql分布式

一、需求

1.数据集中存储

2.

二、分布式组件(介绍内容摘自网络)

1.Amoeba

概述

Amoeba是一个以MySQL为底层数据存储，并对应用提供MySQL协议接口的proxy。它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库上执行。基于此可以实现负载均衡、读写分离、高可用性等需求。与MySQL官方的MySQL Proxy相比，作者强调的是amoeba配置的方便(基于XML的配置文件，用SQLJEP语法书写规则，比基于lua脚本的MySQL Proxy简单)。

Amoeba相当于一个SQL请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。用户需要结合使用MySQL的 Replication等机制来实现副本同步等功能。amoeba对底层数据库连接管理和路由实现也采用了可插拨的机制，第三方可以开发更高级的策略类来替代作者的实现。这个程序总体上比较符合KISS原则的思想。

优势

Amoeba主要解决以下问题:

a). 数据切分后复杂数据源整合

b). 提供数据切分规则并降低数据切分规则给数据库带来的影响

c). 降低数据库与客户端连接

d). 读写分离路由

不足

a)、目前还不支持事务b)、暂时不支持存储过程(近期会支持)

c)、不适合从amoeba导数据的场景或者对大数据量查询的query并不合适(比如一次请求返回10w以上甚至更多数据的场合)

d)、暂时不支持分库分表，amoeba目前只做到分数据库实例，每个被切分的节点需要保持库表结构一致:

Amoeba:阿米巴原虫

 

2.Cobar

Cobar是阿里巴巴研发的关系型数据的分布式处理系统，该产品成功替代了原先基于Oracle的数据存储方案，目前已经接管了3000+个MySQL数据库的schema，平均每天处理近50亿次的SQL执行请求。

首先，使用Cobar的核心功能如下：

分布式：
Cobar的分布式主要是通过将表放入不同的库来实现：
1. Cobar支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分
2. Cobar也支持将不同的表放入不同的库
3. 多数情况下，用户会将以上两种方式混合使用
这里需要强调的是，Cobar不支持将一张表，例如test表拆分成test_1, test_2, test_3.....放在同一个库中，必须将拆分后的表分别放入不同的库来实现分布式。

HA：
在用户配置了MySQL心跳的情况下，Cobar可以自动向后端连接的MySQL发送心跳，判断MySQL运行状况，一旦运行出现异常，Cobar可以自动切换到备机工作。但需要强调的是：
1. Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，当心跳检测到主机异常，切换到备机，如果主机恢复了，需要用户手动切回主机工作，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常。
2. Cobar只检查MySQL主备异常，不关心主备之间的数据同步，因此用户需要在使用Cobar之前在MySQL主备上配置双向同步，详情可以参阅MySQL参考手册。

其次，我们也需要注意Cobar的功能约束：

1) 不支持跨库情况下的join、分页、排序、子查询操作。
2) SET语句执行会被忽略，事务和字符集设置除外。
3) 分库情况下，insert语句必须包含拆分字段列名。
4) 分库情况下，update语句不能更新拆分字段的值。
5) 不支持SAVEPOINT操作。
6) 暂时只支持MySQL数据节点。
7) 使用JDBC时，不支持rewriteBatchedStatements=true参数设置(默认为false)。
8) 使用JDBC时，不支持useServerPrepStmts=true参数设置(默认为false)。
9) 使用JDBC时，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法设置参数。

三、结合项目实际情况

1.目前结构及演变

 

演变->

 

 

2.目前DBLogic管理着与十几个数据库的连接

 

四、缺陷

1.

 

 

五、作用和意义

1.数据库集中，便于管理。数据迁移只需修改路由的规则

2.可配置主备读写关系，写-->master，读-->slave。可适用于读写压力大的情况。也可摒弃目前游龙为了解决容灾和压力而设置的多个roledb。

 

六、思考

1.一头牛不能满足需求的时候，当思考着养一头更大更壮的牛不能解决问题时。可以考虑多使用头牛来工作。

2.读的压力必然大于写的压力。slaveDB不要浪费了

3....

 

 

未完待续