自己写的分布式缓存，求轻拍

[qiyue201707]

最近写的一个分布式缓存, 感兴趣的可以

https://github.com/Leviathan1995/grape

兼容 Redis 协议, 因为 Redis 协议数据表现力很强, 但是集群的使用需要主从模式,所以考虑写一个完全 P2P 结构的分布式缓存, 通过一致性哈希分散数据, 使用客户端连接集群里任意节点就能进行服务,使用redis_cli新增节点和删除节点都特别简单.

TODO

目前支持的命令只有 SET,GET,后面慢慢加.

TTL

因为没有 master 的概念, 现在最主要的就是考虑如何实现节点的存活检测, 考虑要不要也像 Redis 加入哨兵机制,这个问题欢迎大家一起讨论...

[EDDYCJY]

差点以为楼主 95 年。。。

[qiyue201707]

@monsterxx03 是 单机的瓶颈需要考虑
@EDDYCJY 是

[JeffZ1993]

感觉 groupcache 更能满足这种需求吧，兼容 redis 协议，也没什么特别的优势

[qiyue201707]

@monsterxx03 我想纠正一个问题，为什么这种模式请求压力会在同一个服务器上，P2P 模式完全分散了压力

[monsterxx03]

https://github.com/Leviathan1995/grape/blob/master/server/server.go#L116

因为是 server 端 hash 后, forward 请求，如果所有的客户端初始都连到一台 server 上，瓶颈当然就在这台机器上，当然你可以通过配置管理让不同的 client 初始连不同的 server，但这样实际上很麻烦，可用性很差的(比如你连的一台机器要下线了)，不想动 client，基本就 twemproxy 那种代理模式最方便，坚持这种 server 端 forward 方式的话，要分散压力，必然要改 client 的, 做法会类似 elasticsearch 的 client https://github.com/elastic/elasticsearch-py/blob/master/elasticsearch/transport.py#L30

其实现在 redis 的分布式方案，可用的基本就 twemproxy, codis, redis cluster, 没动态扩容缩容需求 twemproxy 就够用.
codis 要引入 zookeeper, redis cluster 那种 smart client 很多人不喜欢，基本都根据自家情况做 tradeoff

[qiyue201707]

@monsterxx03 你说的这种问题在我看来无论什么样的模型都无法避免，在我看来，压力分流都要交给上层的业务自己去选择