redis开发札记

redis开发躺坑记录…

由于公司收藏功能全部使用redis存储数据，数据库冷备，redis流量不断增加，最后经过技术选型，使用twemproxy增加redis分片，容纳更多流量。 然而在开发中出现一些问题

#hashtag
首先是开发中用到了redis的有序数组，即zset，并且使用到其中一条命令ZUNIONSTORE，在测试环境的单机系统中功能正常，但是线上环境twemproxy中功能却不能正常使用，数据异常，不得不紧急回滚。 查询twemproxy的Redis Command Support，支持的命令包含ZUNIONSTORE，但下面包含一行小字

ZINTERSTORE and ZUNIONSTORE support requires that the supplied keys hash to the same server. You can ensure this by using the same hashtag for all keys in the command. Twemproxy does no checking on its end to verify that all the keys hash to the same server, and the given command is forwarded to the server that the first key hashes to.

zset的命令中，不光是ZUNIONSTORE，ZINTERSTORE也需要将key hash到同一分片服务器，才能保证结果正常。 这里的hash需要key使用hashtag，即在key中添加{}，默认情况下，twemproxy会使用整个key来计算哈希；如果存在{}，twemproxy只使用{}内的数据，计算hash值。 如果不想改动key，而且数据量较小，也可以手动zrange出两个zset再zadd到目的key，不过这个操作的流量、CPU开销，就是zeunion的几倍了。

此文档特殊备注的还有以下几个命令：

• MSET support is not Atomic mset操作不是原子的
• RPOPLPUSH, SIDFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE, SUNION, SUNIONSTORE, PFMERGE同样要求，源key和目标key，使用hashtag，hash到同一台服务器
• EVAL使用多个key时，要求同上

#pipeline优化

#连接获取超时