[url]http://qing.weibo.com/1243233955/4a1a3ea33300004d.html[/url]
源自新浪的一篇相当不错的redis实战分享,总结一下:
1.redis对内存相当敏感,虽然它有VM,出于对性能的要求一般都要求所有数据都放在内存里,不会启用VM,记得曾看过一篇文章,说使用内存最好保持在总内存的3/5之内,超过了就可能引起swap抖动。看这篇文章,新浪似乎居然没有设置内存使用上限,有点意外。
2.在缓存宕机重启后,如何让数据迅速热起来是个问题。新浪用的似乎是快照而不是AOF,它的恢复速度已经是最快的了,也要用几十个小时。
3.hgetAll这个血淋淋的例子教育我们,没有经过详细测试和评估的API千万别用。
4.无论是server级的监控还是api级的监控,都是非常重要的,我们常常只注重server级的监控,但到真正棘手的问题出现的时候,api级的监控就是你迅速定位问题的有力武器。
5.新浪能用手机看服务器log,不知道我们能做到不?在这个例子里如果没这个手段,估计发现问题也是几天之后了,值得学习。
源自新浪的一篇相当不错的redis实战分享,总结一下:
1.redis对内存相当敏感,虽然它有VM,出于对性能的要求一般都要求所有数据都放在内存里,不会启用VM,记得曾看过一篇文章,说使用内存最好保持在总内存的3/5之内,超过了就可能引起swap抖动。看这篇文章,新浪似乎居然没有设置内存使用上限,有点意外。
2.在缓存宕机重启后,如何让数据迅速热起来是个问题。新浪用的似乎是快照而不是AOF,它的恢复速度已经是最快的了,也要用几十个小时。
3.hgetAll这个血淋淋的例子教育我们,没有经过详细测试和评估的API千万别用。
4.无论是server级的监控还是api级的监控,都是非常重要的,我们常常只注重server级的监控,但到真正棘手的问题出现的时候,api级的监控就是你迅速定位问题的有力武器。
5.新浪能用手机看服务器log,不知道我们能做到不?在这个例子里如果没这个手段,估计发现问题也是几天之后了,值得学习。