基于nutcracker 的redis分布式缓存的实现的注意

1 TwemProxy配置经验

 What’s awesome about Twemproxy is that it can be configured both to disable nodes on failure, and retry after some time, or to stick to the specified keys -> servers map. This means that it is suitable both for sharding a Redis data set when Redis is used as a data store (disabling the node ejection), and when Redis is using as a cache, enabling node-ejection for cheap (as in simple, not as in bad quality) high availability.
The bottom line here is: if you enable node-ejection your data may end into other nodes when a node fails, so there is no guarantee about consistency. On the other side if you disable node-ejection you need to have a per-instance high availability setup, for example using automatic failover via Redis Sentinel.

当redis做存储的使用时为了保持数据的一致性，应该禁用auto_eject_hosts,也就是当某个节点失败之后并不删除该节点，所以，在每个redis实例上需要额外做一些高可用的配置，比如使用Redis Sentinel(开发中)。
当redis做缓存的使用的时候应该启用auto_eject_hosts，当某个节点失败的时候将该节点删除，虽然丧失了数据的一致性，但作为缓存使用，保证了这个集群的高可用性。

    
       1）不支持mutiple keys的原因，将这个放在用户设计上，避免从mutiple keys上进行聚合等操作的时间
Currently is AFAIK even more strict than Redis Cluster that instead allows MULTI/EXEC blocks if all the commands are about the same key.
But IMHO it's the way to go, distribute the subset you can distribute efficiently, and pose this as a design challenge early to the user, instead to invest a big amount of resources into "just works" implementations that try to aggregate data from multiple instances, but that will hardly be fast enough once you start to have serious loads because of too big constant times to move data around.
在twemproxy中，一些在redis中如get的命令，如果报错，会一直占有这个链接
Twemproxy在errors时，可以监控到error，但是无法做到用其他node代替当前node进行操作，只是发出一个 A SLAVE OF NOONE commond
       twemproxy is already able to monitor instance errors, count the number of errors, and eject the node when enough errors are detected. Well it is a shame it is not able to take slave nodes as alternatives, and instead of eject nodes use the alternate nodes just after sending a SLAVE OF NOONE command. This would turn it into an HA solution as well
  在twemproxy中，对failover失效转化的处理，是用sentinel configuration有规律的更新服务器表
··2) Or alternatively, I would love if it could be able to work in tandem with Redis Sentinel, checking the Sentinel configuration regularly to upgrade the servers table if a failover happened.
  · 还有一种替代的方法，是有一个hot-configure,在失败的时候，可是转化到这个配置文件，进行代理操作proxy ASAP
3) Another alternative is to provide a way to hot-configure twemproxy so that on fail overs Sentinel could switch the configuration of the proxy ASAP.

启动参数

Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
                  [-c conf file] [-s stats port] [-a stats addr]
                  [-i stats interval] [-p pid file] [-m mbuf size]

Options:
  -h, --help             : this help
  -V, --version          : show version and exit
  -t, --test-conf        : 测试配置文件是否存在或者是否存在语法错误
  -d, --daemonize        : 守护进程启动
  -D, --describe-stats   : 打印状态
  -v, --verbosity=N      : 设置日志级别 (default: 5, min: 0, max: 11)
  -o, --output=S         : 设置日志文件位置 (default: stderr)
  -c, --conf-file=S      : 设置配置文件位置 (default: conf/nutcracker.yml)
  -s, --stats-port=N     : 设置状态监控端口 (default: 22222)
  -a, --stats-addr=S     : 设置状态监控IP (default: 0.0.0.0)
  -i, --stats-interval=N : 设置状态监控聚合时间间隔 (default: 30000 msec)
  -p, --pid-file=S       : 设置pid文件 (default: off)
  -m, --mbuf-size=N      : 设置缓存块的大小 (default: 16384 bytes)

一般我会这样启动：

 nutcracker -d -c /usr/local/nutcracker/nutcracker.yml -o /usr/local/nutcracker/nutcracker.log