美图开源内部改造的 Twemproxy(Redis/Memcached 缓存代理)

[hulk]

1. 类似 Nginx 采用 Master-Wokers 的方式来支持多进程
2. 支持配置在线 reload
3. 支持 Redis Master-Slave 读写分离
4. 增加了访问延时(请求和服务响应延时)分布，这个对于定位问题和监控极其重要

欢迎来拍砖，更欢迎问题反馈和 PR.

代码地址: https://github.com/meitu/twemproxy

性能上舔着脸说绝对比当前其他一些解决方案好很多，由于是多进程，内部压测在连接均匀的场景下，随着 CPU 线性增长，最终瓶颈在网卡。内部机器千兆网卡，8 核在小包场景下 QPS 达到 50W/s, 如果网卡有多队列绑定多核性能会更好

[enenaaa]

与 rediscluster 相比有啥优势

[hulk]

@enenaaa 这个问题很好, 第一个是这个东西是针对于 Redis/Memcached 协议的代理，所以 Redis 只是一部分。2. Redis Cluster 功能确实强大(在线扩容，缩容等等)，但存在的问题是运维成本高，另外就是客户端在部分语言上没那么成熟。3. 其实对于大部分业务来说，master-slave 远远足够，不太需要 cluster 这种东西

当然光从 Redis 角度来说，如果有这个能力和资源，上 Redis Cluster 在扩容缩容上很方便，但就是自动化运维部署要跟上，多个业务也不太适合混布（资源隔离问题）

[Mirana]

微博也做了一个，我们在长连接场景下解决连接数平均花费了很多功夫

[hulk]

@Mirana 微博是指 cacheservice?

[Mirana]

@hulk 恩

[Showfom]

支持一下，希望国内的公司能有越来越多这种开源的项目

[hulk]

@Showfom 感谢支持，国内很多公司很多开源很多是纯粹是 KPI 指标，经常开完就基本不维护了(不是黑某个公司，哈哈)，我们之前也开源过一些东西，都在坚持更新和及时处理问题。

[hulk]

@Mirana 赞，今天刚和前同事讨论过 cache service，很多优化很棒，但也背负了很多历史包袱。

[GTim]

过来友情支持下，我会说当年面试美图到了副总那面的时候被刷了？

问题是就是类似.... 答案就是题主你说的这个，我当初懵了，Redis 哪有这个啊，哦，原来是第三方的，然后就刷了

那个时候啥啥的都还没出，Twemproxy 当时正火者....

[hulk]

@GTim 感谢，哈哈，差点就是同事。

[yanaraika]

不错。但是已经 2018 年了比起主从复制我选择基于 raft 的 redis-cluster，国内的 SRE 体系还是落后先进水平一个身位

[gandofyan]

问题是,即使是 Cluster, 也不能跨越这个坑:"Redis Cluster is not able to guarantee strong consistency."

[hulk]

@gandofyan Redis 更多定位是 cache 而是不会 storage，所以才会选择异步复制的方式来提高性能，同时也牺牲了一定的一致性。现在即使是很多 storage 也不不保证强一致，比如 mysql 也是异步复制

[gandofyan]

@hulk 这是 Redis 的思路, 但是如果反向来想一下, 在 Redis 的性能标准之下, 即使做到同步修改对于响应时间的影响也不大, 特别是在实现集群机制之后.

Mysql 或者其他的关系型数据库的问题, 是基于磁盘的操作, 很难优化成 同步修改.
而 Redis 这样基于内存的产品, 是有机会可以实现的.
这一点上, 可以参考 IMDG 的产品. 而不是 Cache 的产品.

[hulk]

@gandofyan 这个看你怎么理解了, Redis 本身以高性能著称，如果变成同步写带来除了延时至少翻倍(性能也会倍减)