三千万数据量下redis2.4的一统计情况

先说一下工作场景，要求做一个服务，满足：处理千万级别数据，单个请求响应时间在20ms以下。由于是存储的数据式为key:list[]，所以很适合使用redis来存放数据，为了测试一下redis存储的效率问题，才有了这篇文章。 第一步：造数据。思路如下：（1）先产生三

       先说一下工作场景，要求做一个服务，满足：处理千万级别数据，单个请求响应时间在20ms以下。由于是存储的数据格式为key:list[]，所以很适合使用redis来存放数据，为了测试一下redis存储的效率问题，才有了这篇文章。

     第一步：造数据。思路如下：（1）先产生三千万个key，为了解决随机函数不能很好平均分布的问题，采用两步走的方法来造3000W个key。首先，从key从1到3000万依次产生，解决数量问题。然后，再使用随机函数产生1000W数据，添加到这些key中。（2）为了提高效率，使用50个线程并发造数据，每个线程负责60万数据的入库工作。（3）对于其中的几种长度的key，插入1万条数据。【3000万数据，大约使用3G左右的内存，实体机内存为8G，分配给redis 4G】

第二步：计算访问速度。为了能比较准确地反映查询速度，产生1万个随机的key并进行访问，10000次get，大约用时15625ms，平均1.56ms一次。

查询时，对于key长度为14，且存有10000个数据的list，执行lrange(key,0, -1)，时间为31ms,而key长度为10，且存有10000个相同数据的list，执行lrange(key,0, -1)，时间为16ms。

插入时，list的key长度为14时插入10000个数据，用时23015ms，而key为10时，用时19875ms。

可见key长度增加4，查询时间由16ms上升到31ms，而插入一条记录的时间由1.9875ms上升到2.3015ms。

三点结论：

一：控制key的长度，尽量使用有意义且简短的词。

二：控制list的长度，尽量不要超过一万，如果可能超过一万，需要考虑过期删除机制。

三：redis占用的内存最好不要超过实际内存的50%，否则在插入时会有读取超时的情况。

 

测试环境 操作系统：Linux x86_64 内存8G，redis版本：2.4.18【最新为2.6.14http://redis.io】