Redis Learning Notes

Redis is an open source, BSD-based, robust K-V memory database, as defined by the Redis website. It provides five types of data structures: strings, hashes, lists, sets, and sorted sets. Redis is written entirely on ANSI C.

Redis is often used for caching purposes, while the popular cache framework in the Java World is memcached, EhCache. So I want to explore the difference between Redis and memcached, as follows:

1. All values of memcached are simple strings, and Redis supports richer data types, and richer data types often mean that complex functions can be supported in simple ways
2. Usually Redis is much faster than memcached.
3. Redis can persist cached data to disk, and memcached cannot. The memcached is a more pure cache, and Redis is less pure and can be used as a database.-based on this, the Redis list can be used as a high availability queue because the queue can be persisted to disk
4. Memcached claims to be a distributed cache, but it's just shard, not involving the collaboration of each instance
5. All Redis operations are atomic

I am more concerned about the 3rd above, so I have specifically more in-depth on this article to see a few articles. The description of Redis as a database is as follows:

?

1 2 3 4

Redis虽然是一个内存数据库，但也可以将数据持久化到硬盘，有两种持久化方式：RDB和AOF。 RDB持久化方式定时将数据快照写入磁盘。这种方式并不是非常可靠，因为可能丢失数据，但非常快速。 AOF持久化方式更加可靠，将服务端收到的每个写操作都写入磁盘。在服务器重启时，这些写操作被重新执行来 重新构建数据集。

By contrast memcached does not provide this persistence mechanism, why memcached not provide it? There should be a lot of reasons (Opinion), here are two articles:

2. Memcached is designed to be an object caching framework rather than a database
3. It may be dangerous to dump the cache to disk:?

   1 2 3 4 5 6 7 8 9 Ten

   Examine the following scenario: a. User update account information, account status is a b. Your code updates the database (such as the MySQL database), the account status in the database is a c. Your code updates the cache, the account status in the cache is a d. You will cache dump to disk and start working on the host where the cache is deployed, and the account status in both the disk and the cache is a E. The user updates the account information again, the account status is B f. Your code updates the database, The account status in the database is B g. Your code failed to update the cache (because the cache server is down this time) h. You restore the cache from disk, the account status in the cache is a i. The user views the account information, resulting in an account status of a

For the problem mentioned in 2nd above, it may be suggested that the order of F, G replacement, update the cache first, and then update the database, only the cache update successfully update the database. This can, in some cases, solve the problem of inconsistent read cache data caused by this write cache failure. But now write performance is down. The ideal state for using a caching framework is to not affect write performance, while significantly improving read performance and ensuring high data consistency (or accuracy, data modernity). So the recommended way to write a cache is to write asynchronously, and the proposal to change the order of F and G is not appropriate.

Here are a few tradeoffs when using the caching framework:

1. Write Cache performance (write cache): Synchronous write or asynchronous write
2. Cache data Modernity (read cache): Whether cached data needs to be synchronized with database data in real time
3. Whether the cache is more than just a cache (cache persistence): Whether it is also used as a database, whether a timed dump cache is required to disk

There is no Tiger-balm solution, because technology serves the business, and business scenarios are ever-changing.

Redis Learning Notes