1)使用atlas却发现“读库闲置，框架还是去主库读写数据”

配置完atlas之后，发现使用jdbc框架的话，读库和写库各司其职，但是使用mybatis框架之后，就发现框架的读写都去了主库，把读库放置一边，那么这种情况是因为“有事务存在的话，atlas就会强制走主库”，遇到这种情况就检查一下是否有事务的存在，比如@Transactional，如果要解决的话，就加上“@Transactional(propagation=Propagation.NOT_SUPPORTED)”即可。

2)自动读写分离挺好，但有时候我写完马上就想读，万一主从同步延迟怎么办?

SQL语句前增加 /*master*/ 就可以将读请求强制发往主库。在mysql命令行测试该功能时，需要加-c选项，以防mysql客户端过滤掉注释信息。不过这不能从本质上解决问题，使用Atlas需要考虑到这点， 提高主机的IO性能，加大memory可以缓解延迟症状，但依旧不能避免延迟的出现，尤其是读多写少的应用。

3)resource limit问题

atlas有自己的连接池，会吃掉很多CPU, php应用端改用短链接来连接atlas, 这时候atlas对php发送来的sql只负责验证和转发的操作，后端DB的连接由atlas自己管理,未使用的连接线程进行剔除操作(DB的wait_timeout和interactive_timeout设置为300s,超时亦退出)。

如果MySQL后端的连接数也满了可能会报以下错误:

可以临时增加MySQL connection数量:

关于Too many open files错误，可能由两种情况引起:

一、php长连接连接到atlas后，每个线程占用一个FD,直到超出系统资源限制而出现too many错误;

二、php应用端发送到atlas的sql过多，大量并发的情况下,linevent维护的队列过多，每个event吃一个FD，超出系统资源限制引起too many错误;

避免too many错误,增加用户的ulimit值加大FD的使用量,可增加系统ulimit 资源到 ~/.bash_profile文件或/etc/security/limits.conf文件: