Redis集群小记

Redis近两三年变得来非常流行,它的设计很简洁,非常轻量级,至少到目前2.4.x为止,它的定位还是一个单机版的基于内存的kv数据库服务。当然作者Salvatore目前也正在进行Redis Cluster的设计和开发,有兴趣的可以看看这篇幻灯片

然而,单机性能毕竟有限,并且作为内存数据库,单机容易因宕机等原因导致中断服务,所以即使没有正式的Redis Cluter,我们常常不得不自己山寨Redis集群来使用。最近,想把Hadoop集群的计算结果,直接中转出来供外部使用。该数据读取的场景比较多,并且更新是常态。因此,希望这个数据服务能够承受高速读写,并且使用方便。于是打算用Redis搭个集群来提供,这里做一个小结。

在动手之前,需要先了解Redis的优缺点和它的适用场景。这方面的总结也很多,就不细述,简单列举一下。

Redis的优势在于:

  • 吞吐量很高。由于是内存数据库,因此支持高速读写,每秒10w级
  • 数据结构很丰富。支持string、list、hash、set、sorted set,且有丰富的数据操作方法,比如string可以按位操作,set可以方便的求交、求并,并且大多数操作都是O(1)的。

同样Redis的缺点也很明显:

  • 内存占用稍高。48GB内存的机器上,大概只能用到38GB,再多就开始swap了 ref
  • 没有太好的数据持久化方案。rdb有可能丢失数据;aof文件增长太快,并且从aof恢复比较慢。
  • Replication还比较简陋。master/slave一旦断开连接,需要重传整个snapshot,估计在以后的版本应该会有改进。

由于我需要的是一个存储服务,所以在选择Redis时,还是有些犹豫的。毕竟如果持久化有问题,当作Storage来用,的确有些发毛。具体在搭建服务的时候,考虑了下面一些问题:

  • 负载均衡(load balance)

    在Redis前端有主备路由进程,还有若干处理进程。请求发送到路由进程,然后简单round-robin的方式分派到处理进程,处理进程根据key去访问相应的redis服务。

  • 可扩展性(scalablilty)

    当数据量增加的时候,需要能够方便的扩容,这里使用简单的pre-sharding方式。

    比如,你可以估算一下数据最大规模,比如最多1TB+,假设每台server的内存是64GB,那么就可以划分到32个redis服务上去。然后,对key简单取模32,即可散列到各个redis服务上了。如果初始只需要4台server,那么每台server就可以跑8个redis服务;如果以后增加server,那么把其中的一些redis服务挪到新的服务器上;然后新旧redis服务通过配置slaveof,即可同步数据;同步完成后,再切换到新的redis服务,关闭老的redis服务。

  • 高可用性(high availability)

    服务一般都需要考虑可用性,需要成熟的failover机制进行故障恢复。做法都是增加冗余了,这里用到了master/slave方式,做读写分离。从Hadoop集群过来的数据写到master,而对外服务从slave读取数据。在这个服务里写操作是常态,而且压力很大。经过权衡测试,发觉master是否持久化,reducer的运行时间居然可以相差一个数量级,所以最终只在slave上使用aof持久化,并关闭appendfsync选项,追求最佳性能。master和slave之间自动replication,从CAP理论来说可以归为一个AP系统。

使用Redis时候的一些注意事项:

  • 在2.4.x里,如果设置了maxmemory,那么当内存占用没有达到极值时,设置expire的key到期后并不会被立即删除;所以,如果期望利用expire让redis清除过期数据,建议还是不要设置maxmemory。
  • pipeline接口,利用了MULTI和EXEC事务处理指令,可以减少网络IO,不过在latency很低的网络里效果并不是很明显。
  • 应该根据自己的应用场景调整redis配置,选择好性能和内存占用的trade-off。

    比如你用Hash的时候,如果能够估计你的应用的fields不会超过64项,每个value值不会超过1KB,那么如下配置后,有可能内存占用甚至能够减少一半,具体请参考官方说明

    hash-max-zipmap-entries 64
    hash-max-zipmap-value 1024

    此外2.4.x支持自动rewrite aof文件了,可以通过如下两个参数调整 BGREWRITEAOF 的频率:

    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

最后,提一下Hadoop集群操作Redis的注意事项。可以有两种办法把数据直接写到Redis里去。一是用Java派生 OutputFormat,在其中写Redis,好处是不用调整reduce的逻辑;二是直接在reduce里写Redis。

如果用Java或者C++程序写MapReduce程序话,没有太多好说的,并不太依赖Hadoop集群的环境。但是如果用Python的话,需要把 redis-py 复制到集群上;如果集群的python环境是2.4的话就比较郁闷,你还必须退回到redis-py 2.4.x之前的版本,并且不能简单的 import redis,需要按照下面的步骤来:

  1. 下载redis-py 2.3.x,解压后把其中的redis包单独提取出来,然后使用zip压缩,得到redis.zip。由于直接用 -file 上传zip文件到计算节点,会被自动解压(没查到资料为啥会自动解压zip,而tgz就没问题,清楚的盼点解),所以需要把redis.zip改名为redis.mod。

  2. 然后,在python脚本中这么使用redis包:

    import zipimport
    
    zipimportor = zipimport.zipimporter("./redis.mod")
    redis = zipimportor.load_module("redis")
    r = redis.Redis(host="10.129.0.14", port=6379, db=0)
  3. 最后,把需要的脚本和文件都上传到Hadoop集群上去,执行:

    $ hadoop jar /home/hadoop/hadoop/contrib/streaming/hadoop-0.20.2-streaming.jar \
             -D mapred.reduce.tasks=32 \
             -input ${input} \
             -output ${output} \
             -mapper "cat"  \
             -reducer reducer.py \
             -file ./reducer.py \
             -file ./redis.mod \
             -partitioner org.apache.hadoop.mapred.lib.KeyFieldBasedPartitioner \
             -jobconf mapred.job.name="an example to call redis in reduce"

还有就是应该控制好reducer的数量,并且先做好测试,保证M/R程序的正确性,否则直接把Redis搞爆了就麻烦了。

2012-02-24 16:45
status: part
comments powered by Disqus