存档

文章标签 ‘redis’

RedisCluster数据覆盖问题

2017年6月28日 没有评论

碰到一个典型的问题:
redis的set数据,有大量的读redis和少量的写源(同时删除redis中对应的key),在读的时候做miss回源。

碰到的问题:
少量写后删除key,会同时有大量的读去回源,源压力暴涨,且导致了多次写。回源越慢,源的压力就越大。

计划由读miss回源改为写时覆盖,问题是:set好像没办法覆盖,只能先删除key后再加,删除key时,还是会引发读回源。

看到redis支持rename,就想到一个办法:
少量写的时候,先把数据写到一个新key里,然后rename成老key,从命令上看是支持覆盖的:https://redis.io/commands/rename

RENAME key newkey

Available since 1.0.0.
Time complexity: O(1)
Renames key to newkey. It returns an error when key does not exist. If newkey already exists it is overwritten, when this happens RENAME executes an implicit DEL operation, so if the deleted key contains a very big value it may cause high latency even if RENAME itself is usually a constant-time operation.
Note: Before Redis 3.2.0, an error is returned if source and destination names are the same.
Return value
Simple string reply

Examples
redis> SET mykey "Hello"
"OK"
redis> RENAME mykey myotherkey
"OK"
redis> GET myotherkey
"Hello"
redis> 

结果是出错:

>rename newkey oldkey
(error) CROSSSLOT Keys in request don't hash to the same slot

更多内容…

分类: 工作 标签: , , , ,

Redis的CLUSTERDOWN问题现场

2016年11月4日 没有评论

2016-10-30 05:28,redis集群出现一次CLUSTERDOWN问题,看起来是因为网络抖动引起的,记录现场信息备用。
Redis 3.0.7 64bit cluster mode
三台服务器(285/286/287),每台服务两个实例(30001/30002)

285上3001实例当时的日志9d21b96013bbee9319a2387a243271c255b411dd

31672:S 30 Oct 05:28:11.809 # Cluster state changed: fail
31672:S 30 Oct 05:28:30.551 * FAIL message received from d4a1b5802d51faa245e1f7e2723f05521faa0c2c about 94bd2201144028727f5560b3e088b9224f08d5b3
31672:S 30 Oct 05:28:30.551 * FAIL message received from d4a1b5802d51faa245e1f7e2723f05521faa0c2c about 4a0d258e31dd4220fbe6d08b06ff2bb63e4cb3ed
31672:S 30 Oct 05:28:30.939 # Cluster state changed: ok
31672:S 30 Oct 05:28:31.941 * Clear FAIL state for node 94bd2201144028727f5560b3e088b9224f08d5b3: slave is reachable again.
31672:S 30 Oct 05:28:31.941 * Clear FAIL state for node 4a0d258e31dd4220fbe6d08b06ff2bb63e4cb3ed: slave is reachable again.

285上30002实例日志d4a1b5802d51faa245e1f7e2723f05521faa0c2c

31722:M 30 Oct 05:28:13.388 # Cluster state changed: fail
31722:M 30 Oct 05:28:30.531 * Marking node 94bd2201144028727f5560b3e088b9224f08d5b3 as failing (quorum reached).
31722:M 30 Oct 05:28:30.531 * Marking node 4a0d258e31dd4220fbe6d08b06ff2bb63e4cb3ed as failing (quorum reached).
31722:M 30 Oct 05:28:30.551 * Clear FAIL state for node 4a0d258e31dd4220fbe6d08b06ff2bb63e4cb3ed: slave is reachable again.
31722:M 30 Oct 05:28:31.553 * Clear FAIL state for node 94bd2201144028727f5560b3e088b9224f08d5b3: slave is reachable again.
31722:M 30 Oct 05:28:35.459 # Cluster state changed: ok

更多内容…

分类: 工作 标签: ,

tcpdump和strings的组合用法

2015年5月8日 没有评论

tcpdump是抓包工具,strings是输出可见字符工具,组合应用会有比较漂亮的用法。

1、用来监控当前服务器上对MySQL的访问。

tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings

2、用户监控当前服务器上对Redis的访问。

tcpdump -i eth0 -s 0 -l -w - dst port 6379 | strings

只要是有明文传输的地方,都可以这么用。

分类: 工作 标签: , , ,

Redis减负之getset

2015年4月28日 没有评论

业务中存在一些跟每个用户相关的数据,高频读写却对精确度要求不高,但也要确保在一定的范围内。数据一般为两种:时间戳或某个自增产生的序号
最初:直接读写DB,业务稍增长后db负载过高。
现状:改为读写redis,value中增加序列号,满千次写一次DB,redis中未命中时读DB。

具体实现方式:
先get,得到xxx.n,当n大于等于1000时,入库set成yyy.1,否则set成yyy.n+1。一个流程中,两次缓存操作,千分之一次DB操作。

今天改为另一种方式:
直接getset yyy, 得到xxx,取yyy和xxx的差值,找一个合理的阈值,超过阈值时触发存储。

优点:
用户数据高频操作时,完全不会写DB,热度降到某个限制以下时,有限的写几次,即:更扛压。原方案用户数据高频操作时写DB必须是同比增加的。

缺点:
确定阈值时麻烦,需要考量高峰和低谷时的情形,去评估主要用户的冷热程度。

需要注意的地方:校验是否需写DB时用的缓存值是上次存入redis,而不是上次存入DB的。如果是时间数据,阈值设置成8小时,不能认为一天就会写三次,实际上中间有阈值内使用时,就会低于三次,甚至如果用户数据操作闲置时间不会低于8小时,就一直不会触发入DB。

分类: 工作 标签: ,