基于此可以实现负载均衡、读写分离、高可用性等需求。与MySQL官方的MySQL Proxy相比，作者强调的是amoeba配置的方便（基于XML的配置文件，用SQLJEP语法书写规则，比基于lua脚本的MySQL Proxy简单）。
Amoeba相当于一个SQL请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。用户需要结合使用MySQL的 Replication等机制来实现副本同步等功能。amoeba对底层数据库连接管理和路由实现也采用了可插拨的机制，第三方可以开发更高级的策略类来替代作者的实现。这个程序总体上比较符合KISS原则的思想。
什么是Amoeba?
Amoeba(变形虫)项目，该开源框架于2008年 开始发布一款 Amoeba for Mysql软件。这个软件致力于MySQL的分布式数据库前端代理层，它主要在应用层访问MySQL的 时候充当SQL路由功能，专注于分布式数据库代理层（Database Proxy）开发。座落与 Client、DB Server(s)之间,对客户端透明。具有负载均衡、高可用性、SQL 过滤、读写分离、可路由相关的到目标数据库、可并发请求多台数据库合并结果。 通过Amoeba你能够完成多数据源的高可用、负载均衡、数据切片的功能，目前Amoeba已在很多 企业的生产线上面使用。主要解决：
- 降低 数据切分带来的复杂多数据库结构
- 提供切分规则并降低 数据切分规则 给应用带来的影响
- 降低 db 与客户端的连接数
- 读写分离
为什么要使用Amoeba？
随着传统的数据库技术日趋成熟、计算机网络技术的飞速发展和应用范围的扩充，数据库应用 已经普遍建立于计算机网络之上。这时集中式数据库系统表现出它的不足：集中式处理，势必造成性 能瓶颈；应用程序集中在一台计算机上运行，一旦该计算机发生故障，则整个系统受到影响，可靠性 不高；集中式处理引起系统的规模和配置都不够灵活，系统的可扩充性差。在这种形势下，集中式数 据库将向分布式数据库发展。而Amoeba的透明、简易配置及多个优点使其成为分布式数据库代理产品中的优秀选择。
分布式数据库代理的相关概念
Amoeba在分布式数据库领域将致力解决数据切分，应付客户端“集中式”处理分布式数据。这里集中式是一个相对概念，客户端不需要知道某种数据的物理存储地。避免这种逻辑出现在业务端， 大大简化了客户端操作分布式数据的复杂程度。分布式数据库系统的优点：
- 降低费用。分布式数据库在地理上可以式分布的。其系统的结构符合这种分布的要求。允许用 户在自己的本地录用、查询、维护等操作，实行局部控制，降低通信代价，避免集中式需要更高要求 的硬件设备。而且分布式数据库在单台机器上面数据量较少，其响应速度明显提升。
- 提高系统整体可用性。避免了因为单台数据库的故障而造成全部瘫痪的后果。
- 易于扩展处理能力和系统规模。分布式数据库系统的结构可以很容易地扩展系统，在分布式数 据库中增加一个新的节点，不影响现有系统的正常运行。这种方式比扩大集中式系统要灵活经济。在 集中式系统中扩大系统和系统升级，由于有硬件不兼容和软件改变困难等缺点，升级的代价常常是昂贵和不可行的。
Amoeba相关产品及其介绍
1、Amoeba for MySQL
Amoeba for MySQL致力于MySQL的分布式数据库前端代理层，它主要在应用层访问MySQL的时候充当query 路由功能，专注分布式数据库proxy开发。座落与Client、DB Server(s)之间。对客户端透明。具有负载均衡、高可用性、Query过滤、读写分离、可路由相关的query到目标数据库、可并发请求多台数据库合并结果。 在Amoeba上面你能够完成多数据源的高可用、负载均衡、数据切片的功能。目前在很多企业的生产线上面使用。Amoeba for mysql对客户端程序来说，它是一个虚拟的mysql，对外提供mysql协议。客户端连接amoeba就象连接mysql一样。在amoeba内部需要配置相关的认证属性。
2、Amoeba for Aladdin
与Amoeba for MySQL 类似，客户端连接Aladdin必须用MySQL 协议，之所以用MySQL协议，主要是想借助mysql使用的广泛程度以及对各种开发语言的支持。Aladdin后端可以同时连接各种数据库。只要这些数据库提供jdbc驱动。aladdin的出现可以解决企业在数据库整合上面提供积极的帮助。使用者不需要知道后端到底使用了什么类型的数据库、数据库的物理地址什么，这些由aladdin来分析sql语句，并且获得相应的要查询的表跟条件，然后由这些规则结合这些条件进行路由到相关的物理数据库。
3、Amoeba for MongoDB
随着NoSQL的日益兴起，mongoDB作为一款nosql数据库以其优异的性能得到了广泛的关注。可以说，mongoDB填补了传统关系型数据库以及传统键值型数据库的空白，并且兼具两者优秀特质。Amoeba for MongoDB将提供与Amoeba for MySQL类似的，完全自主、可控的切分方式、并尝试完成同样的auto sharding的功能。 基于Amoeba框架，跟以往的产品一样具备心跳检测、负载均衡、故障转移、查询聚合等功能，保留了之前的配置方式，只要熟悉amoeba其中一款产品的配置，那么上手将非常容易的。
比较Amoeba及其类似产品
1、Amoeba for Mysql 与MySQL Proxy比较
在MySQL proxy 6.0版本 上面如果想要读写分离并且 读集群、写集群 机器比较多情况下，用mysql proxy 需要相当大的工作量，目前mysql proxy没有现成的 lua脚本。mysql proxy根本没有配置文件， lua脚本就是它的全部，当然lua是相当方便的。那么同样这种东西需要编写大量的脚本才能完成一 个复杂的配置。而Amoeba for Mysql只需要进行相关的配置就可以满足需求。
2、Amoeba for mongoDB与mongos比较
mongodb中的数据切分有一个chunk的概念，每个chunk代表一个数据段（range)，当一个chunk的大小到达了指定的数据大小，就会自动切分成两个。 Mongos是根据数据段（chunk）进行切分的，且切分依据的字段必须是一个key。而目前大多的应用中，id（尤其是用户ID）是无序化的，可能有些用户是手机号、有些是会员卡号等等。这使得proxy的range切分难以实施。 因此，虽然mongodb的mongos提供了automatic sharding的功能，但由于数据切分的不可控，常常不能满足我们的需要。 Amoeba for MongoDB提供完全自主、可控的切分方式。
Amoeba不能做什么？
- 目前还不支持事务
- 暂时不支持存储过程（近期会支持）
- 不适合从amoeba导数据的场景或者对大数据量查询的query并不合适（比如一次请求返回10w以上甚至更多数据的场合）
- 暂时不支持分库分表，amoeba目前只做到分数据库实例，每个被切分的节点需要保持库表结构一致
Amoeba的架构
Amoeba 作为DataBase Proxy的开发框架。致力于解决数据切分、读写分离。以下将为您介绍Amoeba 框架
- Built on Java NIO
- NIO 框架采用无阻塞模式，不像传统的Socket编程在大量并发的情况非常浪费系统资源、而且可扩展性也较差
- Reusable Server Connection
- Amoeba 提供与数据库连接的可重用度非常高，在Amoeba系统内所有Database Connection同时共享给所有连接到Amoeba的客户端
- 提供读写分离、数据切分
- 传统的读写分离技术需要通过客户端或者相关的Database Driver技术才能解决，而且客户端的配置也比较复杂
- 单台Database 性能总是有限制的，基于Amoeba上面可以寻找一种可线性扩展的多数据支持。Amoeba为DBA提供一种非常友好的类似SQL语法的数据切分规则。
同时客户端不用担心过多的DataBase Server会给应用带来更多的配置。
- 支持高可用性、负责均衡
- Amoeba 提供Database 连接的异常检测与连接恢复功能。
- 用户可节省使用其他昂贵的负载均衡的硬件设备，Amoeba提供多台Database Server负载均衡策略（轮询、当前活动连接数量）。
- Amoeba Sequence