@dingpan314 感觉到温暖了

@leriou 啥?? 延时用处很大

@GTim
* 多进程，性能随 CPU 线性增长
* 支持配置在线 Reload
* 统计信息增加延时指标
* 支持 Redis 主从模式

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

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

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

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

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

@Mirana 微博是指 cacheservice?

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

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

@BBCCBB 是的, 第二种如果是本身项目不是特别活跃的时候也是一种比较好的方式，不用维护两个库

3. 如果存在 `get /a/:b/:c`，就不能再定义 `get /a/:b`。 最新版本已经 FIX

1. 这个是 README 格式 copy 没有去掉，已经 FIX
2. 是的，例子上可能是有些误导，实际上使用应该是在 init 的时候添加路由，实际使用就不用再关心
3. 这个是实现的 bug, 如果先添加 `get /a/:b/` 就可以添加 `get /a/:b/:c`， 这个我会 FIX
5. 这点我后面对比压测下当前的实现和正则的性能差别，如果差别不大，不会去做特殊优化。

最后以上建议都很棒，感谢回馈～

@artandlol 哈哈，抢先一步

@spice630

1. 启动部分失败直接退出并提示信息(这时候一定是有问题才会占用失败)，处理完重启。
2. 提供一套独立的日志接口

@0915240 甚可思

@agtc 感谢支持哈

@gouchaoer ok, 多谢提醒。

@yuankui ngrep 很好。