- 计划中的redis-cluster: Multiple instances is a share-nothing architecture.
- 2.6 中实现了Redis Sentinel, 即将实现 partial resynchronization
- Twemproxy 是 single-threaded proxy
- What's awesome about Twemproxy is that it can be configured both to disable nodes on failure, and retry after some time
- 失败时, 可以disable 或者 retry - 作为data store : retry - 作为cache: disable(node-ejection)
同样的一组后端, 可以配成两种:
redis1: listen: 0.0.0.0:9999 redis: true hash: fnv1a_64 distribution: ketama auto_eject_hosts: true timeout: 400 server_retry_timeout: 2000 server_failure_limit: 1 servers: - 127.0.0.1:6379:1 - 127.0.0.1:6380:1 - 127.0.0.1:6381:1 - 127.0.0.1:6382:1 redis2: listen: 0.0.0.0:10000 redis: true hash: fnv1a_64 distribution: ketama auto_eject_hosts: false timeout: 400 servers: - 127.0.0.1:6379:1 - 127.0.0.1:6380:1 - 127.0.0.1:6381:1 - 127.0.0.1:6382:1
限制:
- 不支持 mset, transaction:
I think that twemproxy do it right, not supporting multiple keys commands nor transactions. Currently is AFAIK even more strict than Redis Cluster that instead allows MULTI/EXEC blocks if all the commands are about the same key. - 对mget, mdel 支持, 性能待测试:
However there is some support for commands with multiple keys. MGET and DEL are handled correctly. Interestingly MGET will split the request among different servers and will return the reply as a single entity. This is pretty cool even if I don't get the right performance numbers with this feature (see later). So I expected to see almost the same numbers with an MGET as I see when I run the MGET against a single instance but I get only 50% of the operations per second. Maybe it's the time to reconstruct the reply, I'm not sure. mget 只有50% - 不支持EVAL,
- non supported command: closes the connection.
- sending just a "GET": hang
- 错误处理: (antirez 测试还挺认真)
希望: 支持HA
- 能直接做主从切换.
- 配置热加载也可以啊~ (checking the Sentinel configuration regularly to upgrade the servers table if a failover happened.)
性能: 好!!!
- This Thing Is Fast. Really fast, it is almost as fast as talking directly with Redis. I would say you lose 20% of performances at worst.
- MGET可以优化 (目前性能降低50%)
结论: - I strongly suggest Redis users to give it a try.
人们的讨论:
- 对于MGET: The response time will then beat leastas slow as the slowest node
存储分片和Twemproxy核心解读
antirez(Redis作者)写过一篇对twemproxy的介绍http://antirez.com/news/44, 他认为twemproxy是目前Redis 分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望
- 每个server其实就是一个后端的缓存服务程序
- connection在Twemproxy中非常重要，它分为三种类型的connection:proxy，client和server
- struct msg是连接建立后的消息内容发送载体，这个复杂的msg结构很大程度是因为需要实现pipeline的效果，多个msg属于同一个conn，conn通过接收到内容解析来发现几个不同的msg。
- 涉及到三个重要的结构:server, connection, message。
- Twemproxy的架构比较清晰，对Twemproxy源码印象较深的是对logging的合理布局和错误处理的清晰，这是第一次看大公司开源出来的代码，非常重视logging和错误处理。
- 我的fork: 由于Twitter开源的Twemproxy直接使用epoll驱动，导致其他不支持epoll的系统无法使用，因此我fork了一个版本，加入了kqueue支持，让FreeBSD和Mac os x能够成功编译运行
这位同学2013.10 还是一个大四学生. github 上人气挺高:https://github.com/yuyuyu101
redis-twemproxy-benchmark
http://blog.jpush.cn/redis-twemproxy-benchmark/
- twemproxy 可以开http监控端口:http://ip:22222json格式
- 性能基本和单台一样.
- 多个twemproxy 实例, 性能可以更好.
- 不支持除mget，del之外的redis批处理命令，如取多个集合交集等等
- 不支持脚本eval