1、fmt.Printf有严格的类型限制,比如:%s对应字符串,%d对应数字。而在java中,%s可以适配任意类型。
2、go func()的执行不一定是按调用发起顺序执行的,而且当main结束后,所有协程将不会继续执行。

- 阅读剩余部分 -

SSDB,版本1.9.3
当删除数据时,SSDB服务会卡死一段时间。

计划换成pika,已经有别的团队在实施了

后记:用pika后发现,get set速度确实比ssdb快一些,但针对业务的主要场景zrscan测试发现,pika比ssdb慢四到五倍。

今天在做服务更新时,发现老服务停掉很久以后,新服务还是启不来,提示:端口被占用。

这种情况之前碰到过多次,一般是老服务没停掉,所以端口还在被占,这次是老服务确认停掉很久了,端口依然被占,感觉略诡异。
最终找到原因了,备忘一下。

- 阅读剩余部分 -

刚好这几天有童鞋产生了这一系列误解,备忘一下。

1、info信息的最后一行
# Keyspace
db0:keys=645145,expires=585678,avg_ttl=15585373
keys现存的key数量,这个没问题,expires是当前存在的key里带过期时间的数量,很容易误解为已经过期的数量。
已经过期的数量是Stats区的expired_keys:
expired_keys:243043954

2、slowlog,官方文档https://redis.io/commands/slowlog
初次查很容易被吓到,比如官方举的这个例子,get请求居然花了30毫秒,太慢了
[code]
redis 127.0.0.1:6379> slowlog get 2
1) 1) (integer) 14
2) (integer) 1309448221
3) (integer) 15
4) 1) "ping"
2) 1) (integer) 13
2) (integer) 1309448128
3) (integer) 30
4) 1) "slowlog"
2) "get"
3) "100"
[/code]

- 阅读剩余部分 -

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

285上3001实例当时的日志9d21b96013bbee9319a2387a243271c255b411dd
[code]
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.
[/code]

285上30002实例日志d4a1b5802d51faa245e1f7e2723f05521faa0c2c
[code]
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
[/code]

- 阅读剩余部分 -