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

从图中可以猜测到还会有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占用过多的连接)。 最新内容请见作者的GitHub页：http://qaseven.github.io/
实战Redis序列化性能测试(Kryo和字符串) 将Java对象实例保存在Redis时，将对象序列化成字符串或者序列化成byte数组再存入，以上两种方式孰优孰劣？字符串方式来存取的好处是编码和调试更简单容易，而byte数组的优势又在哪里呢，实战验证吧
devops| redis 数据量暴涨进行数据清理实战 redis 作为程序员的 「瑞士军刀」, 在现有业务中扮演着重要的角色. 为了避免触雷, 「保卫世界和平」, 对 redis 数据进行分析并清理.