基本架构： 写请求全部定向到主库，数据通过日志异步复制到副库，读请求可根据情况路由到主库或者副库，分散读压力目前读的压力平均分到3台服务器，性能提升在20-30%左右


中间件连接池会根据 CONNECTION的AUTO COMMIT 状态来缓冲连接，如果过程中AUTOCOMMIT的值发生变化，则之前缓存的数据库连接会失效. 导致重新建立连接性能下降. JDBC事务控制恰恰会主动把CONNECTION的 AUTOCOMMIT属性设为 FALSE （默认为TRUE). 如果禁用事务，数据完整性得不到保证并且会引发其他错误. 好在ONEPROXY最新版本已经解决了这个问题  （题外话，好像MYCAT连接池的设计思路也类似，使用时有没有坑有待验证）


在高并发下 ONEPROXY 中间件的连接池大小要调整

ONEPROXY 中间件的字符集要设置成UTF8，默认是GBK, 如果没有设对，那么对象序列化的BLOB存到MYSQL数据库会损坏导致无法反序列化
 


在写主数据库，读多个副数据库的架构下，最常见的问题是数据复制不及时，导致定向到副库的读请求没有读到数据ONEPROXY 通过事务控制来解决这个问题，如果读和写操作都在一个事务里，那么他们都会到被定向到主数据库所以事务的边界控制很重要，但是现在应用的代码非常混乱，导致控制事务很困难，ONEPROXY提供了一个折衷的方案，可指定对于某个表定向到主库/副库，现在对于读写都很频繁的表，购物车，订单，订单行，促销，支付记录等一律指定路由到主库错误率目前基本控制在零. 曾经也尝试过用PERCONA的参数 WSREP_CAUSAL_READS 来解决上述问题，但是并没有效果