Deep Dive into redis and read redis-from-the-ground-up

There is an article on the Internet about redisArticleRedis: http://blog.mjrusso.com/2010/10/17/redis-from-the-ground-up.html. We strongly recommend that you read this article if you are interested in redis or want to use it.

When talking about redis, the first reaction is the memory K/V cache, and many people will compare it with memcached. After all, they all use memory as the storage medium. If we simply compare the difference between redis and memcached, most people will get the following points:

1 redis not only supports Simple K/V data, but also provides storage of data structures such as list, set, and hash.

2. redis supports data backup, that is, data backup in master-slave mode.

3. redis supports data persistence. Data in the memory can be stored on the disk and loaded again during restart.

Aside from this, you can go deep into the internal structure of redis to observe more essential differences and understand the redis design. I think the most important reference is the redis memory model design. We recommend that you refer to these two articles:Redis virtual memory: the story and the codeAndRedis virtual memory subsystem.

In redis, not all data is stored in the memory. This is the biggest difference from memcached (I personally think so ). Redis only caches information about all keys. If redis finds that the memory usage exceeds a threshold value, it triggers swap operations."Swappability = age * log (size_in_memory )"Calculate the key value that needs to be swap to the disk. Then, the values corresponding to these keys are persisted to the disk and cleared in the memory. This feature allows redis to maintain data that exceeds the memory size of its machine. Of course, the memory of the machine must be able to maintain all keys. After all, the data will not be operated by swap. At the same time, because redis will provide the Service Main Line and the sub-threads that perform the swap operation will share this part of the memory when swap data is sent to the disk, if the swap data is updated, redis will block this operation until the subthread completes the swap operation.

You can refer to the comparison before and after using the redis special memory model:

 
VM off: 300 K keys, 4096 bytes values: 1.3G used
VM on: 300 K keys, 4096 bytes values: 73 m used
VM off: 1 million keys, 256 bytes values: 430.12 m used
VM on: 1 million keys, 256 bytes values: 160.09 m used
VM on: 1 million keys, values as large as you want, still: 160.09 m used
 

When reading data from redis, if the value corresponding to the read key is not in memory, redis needs to load the corresponding data from the swap file and then return it to the requester. Here there is an I/O thread pool problem. By default, redis will be congested, that is, after all swap files are loaded, it will respond accordingly. This policy is suitable for batch operations when the number of clients is small. However, if you apply redis to a large websiteProgram. Therefore, when redis runs, we set the size of the I/O thread pool, and perform concurrent operations on the read requests that need to load the corresponding data from the swap file to reduce the blocking time.

If you want to use redis in a massive data environment, I believe it is indispensable to understand the Memory Design and blocking of redis.

 

For more articles about nosql, refer to: http://www.cnblogs.com/gpcuster/tag/NoSQL/