博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
为什么Codis比较慢,但我们还要用它呢?
阅读量:6038 次
发布时间:2019-06-20

本文共 694 字,大约阅读时间需要 2 分钟。

  1. 为什么 Codis 比 twemproxy 慢?

  • Codis 追求简洁的实现,我们没有针对内存进行优化,所以会比 twemproxy 还要多一倍拷贝。

  • Go 虽然使用 epoll,但是 IO 都不是直接完成的,而是通过 IO thread,所以需要更多的线程间通信和线程切换。

  • 所以单 CPU 情况下, Codis 吞吐能到 twemproxy 的 1/2,redis 的 1/4,说明我的实现还是可以的。

  • Codis 是 Go 开发的,底层 IO 本质也是通过 epoll 实现的。Go 为开发带来了方便,但是所有的便利都是以牺牲性能作为代价的。

那需要 Codis 有什么用?
  • 单 twemproxy:方便调整,性能不行

  • 多 twemproxy:调整需要技巧,可能需要停止服,看具体业务需求,无论如何都很痛苦。

  • Codis?

  • 适当的 CPU 就可以获得比 twemproxy 更好的性能和可靠性,同时具备横向扩展的能力

  • 可动态调整。这一点就足够了。

  • 对 redis 集群而言,CPU 和 内存,哪个更贵?而且通常 redis 集群 CPU 都是空闲的

  • 如果你的业务需要 10G:没必要用 twemproxy 或者 Codis,影响心情,给自己添麻烦。

  • 如果你的业务需要 400G:你可以选择 单/多 twemproxy + 多 redis,毕竟在相同吞吐下,twemproxy 比 codis 有更好地 CPU 利用率。

  • 但是一旦你的业务需要迁移数据,比如机器上下线,容量调整,怎么办?

转载自https://github.com/CodisLabs/codis/issues/309

你可能感兴趣的文章
程序员职业生涯探讨(转)
查看>>
移动应用跨平台之旅
查看>>
poj 1426 Find The Multiple(bfs)
查看>>
zabbix部署
查看>>
Redis持久化及复制
查看>>
Selenium基础知识(详解IDE命令、css及xpath定位一)
查看>>
Java Web整合开发(82)
查看>>
Scrum 简介
查看>>
Windows批处理 调用程序后 不等待子进程 父进程继续执行命令
查看>>
[BZOJ 4551][Tjoi2016&Heoi2016]树(并查集)
查看>>
smartcar.urdf.xacro
查看>>
C#设计模式学习笔记-单例模式
查看>>
BaseActivity
查看>>
django 使用mysql数据库的流程
查看>>
Java基础之String类
查看>>
数据库--释放mysql数据库资源
查看>>
jQueryUI Repeater 无刷新删除 新建 更新数据 - JQueryElement [7]
查看>>
FOJ有奖月赛-2015年11月 Problem A
查看>>
电商网站中添加商品到购物车功能模块2017.12.8
查看>>
android 模拟器 hardWare 属性说明
查看>>