redis的内存陷阱

整天发些转来的帖子, 自己总结太少了. 把我前段时间redis的让我头疼的地方写一下，因为这个原因本来用redis的数据被迁到tokyoCabinet上。

 

redis是个对内存依赖性很强的NoSql数据库，在内存足够的情况下性能出色

 

如果只有一台机子去部署redis，一定要特别小心。

 

比如我有台24G的服务器，理所当然我会将大量内存分配给redis。

 

比如20G的内存， 问题来了， 当你对redis插入数据后，redis会异步将数据dump到硬盘中

 

想起来很完美，问题是它会fork一个进程，并占去同样大小的内存，你需要的内存瞬间便为 20G+20G =40G

 

这时内存超过了物理内存的限制，马上会启动虚拟内存，我的机子上是8G虚拟内存，重点是这个是linux的虚拟内存，并不是redis自己的虚拟内存。

 

linux的虚拟内存 page很大，IO剧增，dump速度会非常慢，整个服务器的性能降到冰点，服务请求都会堵塞。最严重到机子坏掉。

 

对于单台机子最好是降低redis虚拟内存设置，page可以根据配置修改，这个虚拟内存比linux的虚拟内存好很多，因为page小很多。

 

如果你的redis既有读又有写，那么最好不要让redis占去大半的内存。

 

可以设置它的虚拟内存到8G，这还要根据你的key值大小的衡量，因为key是必须在内存中的，这样一来就算启用了虚拟内存，redis占去的实际内存也会超出设想。

 

天哪， 就是说必须给redis留出他本身需要一倍以上的内存，平时在不插入数据的时候，内存空着不用，浪费。

 

此外官方文档中建议对key小，value很大的数据设置虚拟内存。

 

另外master/slave不是很成熟，目前只支持主从，Redis在master是非阻塞模式，也就是说在slave执行数据同步的时候，master是可以接受客户端的请求的，并不影响同步数据的一致性，然而在slave端是阻塞模式的，slave在同步master数据时，并不能够响应客户端的查询

Redis的master/slave模式下，master提供数据读写服务，而slave只提供读服务