Redis千万级的数据量的性能测试

2019独角兽企业重金招聘Python工程师标准>>>

从图中可以猜测到还会有Redis 2.2.1 的测试，相同的测试环境，1K的数据量，使用ServiceStack.Redis客户端进行如下测试： 1) Set操作 2) Get操作 3) Del操作 每一套测试分别使用三个配置进行测试： 1) 绿色线条的是开启Dump方式的持久化，5分钟持久化一次 2)

   

     

 　　从图中可以猜测到还会有Redis 2.2.1  的测试，相同的测试环境，1K的数据量，使用ServiceStack.Redis客户端进行如下测试：

　　1) Set操作

　　2) Get操作

　　3) Del操作

　　每一套测试分别使用三个配置进行测试：

　　1) 绿色线条的是开启Dump方式的持久化，5分钟持久化一次

　　2) 蓝色线条是开启AOF方式的持久化，每秒写入磁盘一次

　　3) 红色线条是关闭任何的持久化方式

　　对于每一个配置都使用相同的其他配置：

　　1) 开启VM 最大内存10GB(128字节一页)之后开始换出，VM空间160GB

　　2) 最大使用内存15GB，确保在Dump的时候有足够的剩余内存

　　3) 开启压缩，没有配置主从

　　现在来看一下测试结果：

　　

 

　　从这个图中可以看出：

　　1)  对于没有持久化的方式，读写都在数据量达到800万的时候，性能下降几倍，此时正好是达到内存10G，Redis开始换出到磁盘的时候。并且从那以后再也没办法重新振作起来，性能比Mongodb还要差很多。

　　2) 对于AOF持久化的方式，总体性能并不会比不带持久化方式差太多，都是在到了千万数据量，内存占满之后读的性能只有几百。

　　3)   对于Dump持久化方式，读写性能波动都比较大，可能在那段时候正在Dump也有关系，并且在达到了1400万数据量之后，读写性能贴底了。在Dump的 时候，不会进行换出，而且所有修改的数据还是创建的新页，内存占用比平时高不少，超过了15GB。而且Dump还会压缩，占用了大量的CPU。也就是说， 在那个时候内存、磁盘和CPU的压力都接近极限，性能不差才怪。

　　总结一下：

　　1)   Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。对于这个版本的Redis，不建 议使用任何的持久化方式。否则到时候可能会死的比较难看。说白了，期望Redis是memcached的升级版，带有各种数据结构，但是不要期望 Redis来和Mongodb/Kt等来比。

　　2)   对于VM其实也是不建议开启，虽然开启VM可以让Redis保存比内存更多的数据，但是如果冷热数据不是很明显的话性能会非常差(我的测试都是随机查询 Key，冷热不明显)。当然，对于冷热明显的情况下可以设置200%  - 400%的内存作为VM空间，也不建议设置10倍的内存空间作为VM(像我的配置一样)。

　　3)   ServiceStack.Redis客户端好像有几个Bug，首先RedisTypedClient的Dispose居然没有实现，应该是要调用 client.Dispose()，其次RedisNativeClient的Info属性不是每次都获取最新值的，第三 PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加没看到减的地方，也不知道这是干 啥的，其实每次都取第一个不是Active的Client就可以了，PooledRedisClientManager也没有把超时使用的Active的 Client强制回收(避免使用的时候忘记Dispose占用过多的连接)。有关这几点，我会尝试联系ServiceStack.Redis的作者。

转载于:https://my.oschina.net/u/239645/blog/217671