Amoeba 作为DataBase Proxy的开发框架。致力于解决数据切分、读写分离。以下将为您介绍
一、Amoeba 框架简介
• Built on Java NIO
1. 采用java NIO 框架无阻塞模式，不像传统的Socket编程在大量并发的情况非常浪费系统资源、
而且可扩展性也较差
• Reusable Server Connection
Amoeba 提供与数据库连接的可重用度非常高，在Amoeba系统内所Database Connection同时共享
给所有连接到Amoeba的客户端
• 提供读写分离、数据切分
1. 传统的读写分离技术需要通过客户端或者相关的Database Driver技术才能解决，而且客户端的
配置也比较复杂
2. 单台Database 性能总是有限制的，基于Amoeba上面可以寻找一种可线性扩展的多数据库支持。
Amoeba为DBA提供一种非常友好的类似SQL语法的数据切分规则同时客户端不用担心过多的
DataBase Server会给应用带来更多的配置。
• 支持高可用性、负责均衡
1. Amoeba 提供Database 连接的异常检测与连接恢复功能。
2. 用户可节省使用其他昂贵的负载均衡的硬件设备，Amoeba提供多台Database Server负载均衡策略
（轮询、当前活动连接数量）
二、amoeab 序列图
三、启动过程解析
1. 加载Log4j配置文件，配置日志信息
2. 初始化ProxyRuntimeContext ，比如加载配置文件，做一些初始化操作，设置一些上下文信息
3. 注册Reporter 功能
4. 创建Mysql客户端代理的连接管理器（该管理器管理客户端到代理服务器和代理服务器到服务端的连接，并调度分配连接）。
5. 读取IP权限表，并注册到Mysql连接管理器中
6. 最后启动服务。启动服务以后，Mysql 连接管理将监听指定的端口，开始提供服务。
四、MysqlClientConnectionManager机制
MysqlClientConnectionManager 的类的继承关系如下：
其中Looping在run方法中做两件事情：
- 执行方法 willStart()，做端口监听的相关信息初始化操作，详细可见： ServerableConnectionManager.willStart() 方法
- iterate() ： 轮询监听端口，以处理响应的网络事件（包括从客户端<--->Mysql代理服务器 和 Mysql代理服务器<-->mysql目标服务器之间的交互事件）
MysqlClientConnectionManager 在收到网络事件以后，调用 MySqlCommandDispatcher 对网络事件进行分发处理（详细的分发方法后续详细分析）。
Amoeba 作为DataBase Proxy的开发框架。致力于解决数据切分、读写分离。以下将为您介绍
一、Amoeba 框架简介
• Built on Java NIO
1. 采用java NIO 框架无阻塞模式，不像传统的Socket编程在大量并发的情况非常浪费系统资源、
而且可扩展性也较差
• Reusable Server Connection
Amoeba 提供与数据库连接的可重用度非常高，在Amoeba系统内所Database Connection同时共享
给所有连接到Amoeba的客户端
• 提供读写分离、数据切分
1. 传统的读写分离技术需要通过客户端或者相关的Database Driver技术才能解决，而且客户端的
配置也比较复杂
2. 单台Database 性能总是有限制的，基于Amoeba上面可以寻找一种可线性扩展的多数据库支持。
Amoeba为DBA提供一种非常友好的类似SQL语法的数据切分规则同时客户端不用担心过多的
DataBase Server会给应用带来更多的配置。
• 支持高可用性、负责均衡
1. Amoeba 提供Database 连接的异常检测与连接恢复功能。
2. 用户可节省使用其他昂贵的负载均衡的硬件设备，Amoeba提供多台Database Server负载均衡策略
（轮询、当前活动连接数量）
二、amoeab 序列图
三、启动过程解析
1. 加载Log4j配置文件，配置日志信息
2. 初始化ProxyRuntimeContext ，比如加载配置文件，做一些初始化操作，设置一些上下文信息
3. 注册Reporter 功能
4. 创建Mysql客户端代理的连接管理器（该管理器管理客户端到代理服务器和代理服务器到服务端的连接，并调度分配连接）。
5. 读取IP权限表，并注册到Mysql连接管理器中
6. 最后启动服务。启动服务以后，Mysql 连接管理将监听指定的端口，开始提供服务。
四、MysqlClientConnectionManager机制
MysqlClientConnectionManager 的类的继承关系如下：
其中Looping在run方法中做两件事情：
- 执行方法 willStart()，做端口监听的相关信息初始化操作，详细可见： ServerableConnectionManager.willStart() 方法
- iterate() ： 轮询监听端口，以处理响应的网络事件（包括从客户端<--->Mysql代理服务器 和 Mysql代理服务器<-->mysql目标服务器之间的交互事件）
MysqlClientConnectionManager 在收到网络事件以后，调用 MySqlCommandDispatcher 对网络事件进行分发处理（详细的分发方法后续详细分析）。
评论
分布式事务方面一直是我比较迷惑的地方，至今我们还在摸索哪些适合用即时一致性，哪些适合非即时一致性，希望有机会能请教你们。
我们也希望这个项目能够慢慢的变的强大，设置能用来解决内部网络应用的庞大数据据。 估计下去， 我们会增加事务处理的机制， 但是目前， 这个需求对于我们来说不是那么紧急。 下个版本我们将会增加群集监控功能。设计一个能监控整个driver server监控， 管理的能力。
事务补偿机制的问题， 这个很多大的站点， 比如ebay, 他是拒绝join, 拒绝在线事务， 他们是通过事务的补偿机制完成的， 这样的机制， 是现实的。
2.开始是从开源项目中发现这个项目的，所以以为是一个在推广中的开源项目。
3.我是觉得你们单独做成一个独立启动的服务，增加了一层远程调用，会有一些开销，不过，可能对于你们要处理的查询，这点开销可以忽略了。
1.这个东西是支持超规模数据的， hibernate就算了， 基本还是用ibatis.
2. 如此大规模的下的数据， 对不起， 请自己实现事务管理服务器。
3. 如果你少于一亿条频繁读写的数据， 放弃吧。
至于是否是脱离现实， 就看有没有人用了， 不好意思， 我们部署了32X2个MYSQL群集使用。 差不多如此而已。
呵呵,自己实现事物管理，问题是,我在何处征用被这个产品代理的RM?你的意思是直接改源码?你提到大规模数据，是否指这里使用事务会过长占用连接资源?需要改用异步的补偿机制来实现一致性?
至于你说的超规模,基本还是用ibatis,我只能说，ibatis能做的，hibernate扩展后也能做到.hibernate很多时候其实都是在用面向对象的方法拼SQL,如果深刻理解这些拼sql的规则，在SQL方面跟用ibatis拼SQL有什么区别呢?不信你可以举例,我来回答你.
1亿条数据?我正是因为需要在分布式数据中处理上亿的数据，才会看到这个产品.不明白你的意思，可能是我表达的不好，我只是觉得，这个产品的一些好的想法如果能建立在更大众化的基础上会更受欢迎.我们之前的一个项目里，也是做了一个类似的东西，但是我们是把这些"sql解析","按规则查找数据源","合并查询结果"这些功能加入到了spring和hibernate中间的一层.
再看了， 我觉得有必要再阐述下：
1。关于ibatis, 在大规模的数据下， 我们需要能做SQL的调整， 全部使用原生的SQL是为给DBA更好的工作， 所有SQL能让DBA审查。 这个早期的HIBERNATE是很难做到JAVA代码与SQL分离的。
2。 关于是不是更大众化的， 我是很有意见的，毕竟要处理频繁处理上亿数据， 这本身就不是大众化了。 也是少部分程序员才有机会做的事情。
3。 为什么不使用独立的JAR， 这个也有争论， 独立的JAR在开发测试上， 会有些问题。 不容易维护， 使用代理机制， 可以把开发测试完全独立开来， 开发测试可以在一个数据库上完成。 独立应用更容易扩展与管理。
4。另外， 我们做这个OPENSOURCE本身就已经有付出很大的勇气了。 再怎么做， 我们首先要满足企业自身的需求， 再才会满足别人的需求， 我们架构团队开发资源很紧张， 基本2个人半年完成这么多的代码， 已经是非常累了。 说实话， 这东西我们连哪个公司开发的都没有说， 因此不存在炫耀或者其他， 仅仅是把我们的做法公示出来， 很多不是对各大型站点如何解决性能问题很感兴趣么， 这也算是给大家一些提示吧。
估计最近在上线过程， 发布新版肯定是没有时间了。 明年再说吧。 目前代码控制转到公司内部了。
我们在开发这个产品的时候， 是为了对付单一表， 大规模数据的。
我知道现在hibernate也能做SQL配置了。 但是， 至少我用的时候弊端太多了。 hibernate的卫道士未免也太多了。 hibernate的学习成本和其他的弊端非常多， 最新的版本，我都能看到在动态SQL处理上的问题。 好了， 不讨论hibernate的问题。 这个是实验出来的结果。
目前， 昨天刚上线的新版本ameoba,对了， 估计你们看到的版本是比较老的。
我们的现在Amoeba处理４００００条ＳＱＬ／秒。现在还是比较稳定的。
1.这个东西是支持超规模数据的， hibernate就算了， 基本还是用ibatis.
2. 如此大规模的下的数据， 对不起， 请自己实现事务管理服务器。
3. 如果你少于一亿条频繁读写的数据， 放弃吧。
至于是否是脱离现实， 就看有没有人用了， 不好意思， 我们部署了32X2个MYSQL群集使用。 差不多如此而已。
呵呵,自己实现事物管理，问题是,我在何处征用被这个产品代理的RM?你的意思是直接改源码?你提到大规模数据，是否指这里使用事务会过长占用连接资源?需要改用异步的补偿机制来实现一致性?
至于你说的超规模,基本还是用ibatis,我只能说，ibatis能做的，hibernate扩展后也能做到.hibernate很多时候其实都是在用面向对象的方法拼SQL,如果深刻理解这些拼sql的规则，在SQL方面跟用ibatis拼SQL有什么区别呢?不信你可以举例,我来回答你.
1亿条数据?我正是因为需要在分布式数据中处理上亿的数据，才会看到这个产品.不明白你的意思，可能是我表达的不好，我只是觉得，这个产品的一些好的想法如果能建立在更大众化的基础上会更受欢迎.我们之前的一个项目里，也是做了一个类似的东西，但是我们是把这些"sql解析","按规则查找数据源","合并查询结果"这些功能加入到了spring和hibernate中间的一层.
1.这个东西是支持超规模数据的， hibernate就算了， 基本还是用ibatis.
2. 如此大规模的下的数据， 对不起， 请自己实现事务管理服务器。
3. 如果你少于一亿条频繁读写的数据， 放弃吧。
至于是否是脱离现实， 就看有没有人用了， 不好意思， 我们部署了32X2个MYSQL群集使用。 差不多如此而已。
首先,一个企业里的应用,大部分都是以下情况:
1.数据源使用的是应用服务器上配置的数据源.
2.必须要有事务管理
3.有很大可能是使用了spring+hibernate或者ibates
对于以上情况，请教一下,这个产品如何提供支持??