• 博客园logo
  • 会员
  • 众包
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • HarmonyOS
  • Chat2DB
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
CL.TANG
非官方言论,知识谨慎吸收
博客园    首页    新随笔    联系   管理    订阅  订阅

mysql代理件试用对比

2-3台服务器(1master,1-2slave),一台客户机(loadrunner打压)

 

1. mysql-proxy

  试用很不稳定。经常丢失连接,并且在并发用户测试下的成绩很烂

  否定。

2. amoba

  比较稳定,但有限制,不能使用事务,如果你的项目里有事务逻辑,那么他不能使用。个人认为很多项目都需要有事务的支持,以保证数据的正确性。

  否定。

 

3. Atlas

  是经过360的基础团队修改过的mysql-proxy,比mysql-proxy稳定得多。但是仍然不理想。

  测试Atlas支持创建600个connection,后来就会 lost connection, 2台机器读写分离,后来在加了一台从服务器,效果一样。当然,mysql-proxy是10位数级别,更惨,不得不说360团队对mysql效率提升是10倍20倍的。

  但是,在测试前的单机测试(不使用任何中间件)中,却能创建1000个链接。查看Atlas的sql日志,也是正常进行读写分离。

  同时,在错误处理上, Atlas说有的数据可能主从同步不及时,在主库中有,在从库中没有的时候支持在sql前面加上“/*master*/”,个人试了一下正常使用,但是有个问题:

  我之所以选择这种代理mysql中间件的原因就是我不想修改业务代码,为什么选择中间件就是想用最快的速度达到读写分离,负载均衡,同时不要让我修改我的业务,试想,我要业务多了,改sql并且用可能会降低性能的中间件还不如在业务层进行读写分离。

  另外,现在很多项目是使用orm框架来操作数据库的,并不是使用原生sql,Atlas这样做是想让我修改orm框架吗?

  所以,Atlas是我以为最接近成功使用一个mysql代理层,但是还是不够。

 

4

 

4. 

posted @ 2016-10-18 14:14  CL.TANG  阅读(2443)  评论(1)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3