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

与 rediscluster 相比有啥优势

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

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

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

@Mirana 微博是指 cacheservice?

@hulk 恩

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

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

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

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

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

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

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

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

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

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

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

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