• 幕客老师召集小伙伴
  • python自动化运维项目实战
  • nginx从入门到实战
  • 阿里云与Centos7实战

评缓存代理服务Nutcraker缺点

类似Memcache、Redis 这些K/V存储,最需要我们解决的就是它们的高可用性。

所以今天来谈谈实现缓存服务的高可用服务Twemproxy.

Twemproxy是Twitter公司开源的,是一个可以用作Memcache和Redis的代理服务。

1、Redis性能测试 

已经搭建的两台Redis服务,如下:

11:08 root@jeson.com#netstat -luntp|grep redis

tcp        0      0 0.0.0.0:6379                0.0.0.0:*                   LISTEN      23504/redis-server  

tcp        0      0 0.0.0.0:6380                0.0.0.0:*                   LISTEN      23167/redis-server  

搭建的nutcraker,如下: 

tcp        0      0 www.iaskjob.com:22121             0.0.0.0:*                   LISTEN      6365/nutcracker     

tcp        0      0 0.0.0.0:22222               0.0.0.0:*                   LISTEN      6365/nutcracker  

 

 

2、用redis-benchmark测试

 ./src/redis-benchmark -h 30.96.8.173 -p 22121  -c 1 -n 10

-h 服务器IP 

-p 端口

-c 同时增加的并发数

-n 总数量

-d 包的大小

 

 

  1. 前端使用 Twemproxy 做代理,后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。
  2. 后端一台 Redis 挂掉后,Twemproxy 能够自动摘除。恢复后,Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。
  3. Redis 挂掉后,后端数据是否丢失依据 Redis 本身的策略配置,与 Twemproxy 基本无关。
  4. 如果要新增加一台 Redis,Twemproxy 需要重启才能生效;并且数据不会自动重新 Reblance,需要人工单独写脚本来实现。
  5. 如同时部署多个 Twemproxy,配置文件一致(测试配置为 distribution :ketama,modula),则可以从任意一个读取,都可以正确读取 key对应的值。
  6. 多台 Twemproxy 配置一样,客户端分别连接多台 Twemproxy可以在一定条件下提高性能。根据 Server 数量,提高比例在 110-150%之间。
  7. 如原来已经有 2 个节点 Redis,后续有增加 2 个 Redis,则数据分布计算与原来的 Redis 分布无关,现有数据如果需要分布均匀的话,需要人工单独处理。
  8. 如果 Twemproxy 的后端节点数量发生变化,Twemproxy 相同算法的前提下, 原来的数据必须重新处理分布,否则会存在找不到key值的情况 
  9. 1、自身没有健康检查机制,虽然有效的实现了后端cache的性能、可用性分发,但需要依赖keeplived或者负载均衡设备实现代理自身的高可用性。

 

未完待续......

评缓存代理服务Nutcraker缺点

Pingbacks已打开。

引用地址

暂无评论

发表评论