前段时间调研了一下oneproxy，google收录的资料比较少，基本都是看得官方的博客文章．
oneproxy，出生于阿里系的人员之手，主要的目的是为了解决数据库变迁所带来的问题．
特点
负载均衡 + 分库分表 + 大数据 + SQL监控 + 安全审计
说说我想了解的几个方面吧～
SQL监控
在解决安全方面，oneproxy有几个层次验证拦截．
1．网络隔离，oneproxy可以限制其他机器对端口的访问
- 登录验证，就是数据库用户密码验证
- 访问限制，就是MySQL等常见的权限验证
- 应用验证，类似于Google的动态口令，发送一个特殊的SQL语句来对数据库的访问进行解锁
- SQL白名单，需要搜集目前可以执行的SQL模板形成白名单，可以有效的防止SQL注入．
除此之外，还有基于客户端IP地址的流量控制，而且还有很多监控相关的数据可以查看，具体就不罗列了．
负载均衡
由于oneproxy实际上是一个代理，所以实际上，后端到底是访问哪个数据库，对于用户本身是未知的．
如同haproxy或者codis这一类应用一样，它可以减少实际数据库的链接数，减少tcp链接频繁创建．
所以，oneproxy不能用use,存储过程，prepare这一类的操作．
更大的好处是，多实例数据库可以防止单点故障．
我看oneproxy有相关的配置，可以让它优先去访问master还是slave数据库，但是这个操作是oneproxy实例级别的，大部分业务场景都是读写分离，但是对于部分实时性要求比较高的场景，读写都会在主数据库完成，即使是开了SemiSync也是不够的，是否可以做到指定呢？还是说，这时候实际上，开发不应该基于MySQL等来完成实时的一致性校验．
目前的策略是 read_slave, read_balance, big_slave, big_balance．完整的介绍传送门
分库分表
这是很多proxy都需要支持的一个特性，mysql实际上也是支持单实例的分区的，不过这对SQL解析和merge数据方存在一定的挑战．这个特性的基础上，大表可以根据需要分散到各个不同的数据库实例之中，对查询的性能瓶颈有很大的突破．不过存在的问题，比如分布式事务的支持，我看oneproxy还是没有解决的，毕竟老大难．
这里有个很不错的功能，是在分库分表的情况下，可以生成对应的主键．创送们 从前自己实现的分表里面，主键是通过redis来维护的自增值．用oneproxy的话，就方便多了～