How to solve Redis cache problem

LevelDB is here!

#This is a NOSQL storage engine library open sourced by Google and is an indispensable tool in the field of modern distributed storage. Based on it, Facebook developed another NOSQL storage engine library, RocksDB, which follows LevelDB's advanced technical architecture while also solving some of LevelDB's shortcomings. You can compare RocksDB to a hydrogen bomb, which is more powerful than LevelDB. Many modern open source databases use RocksDB as the underlying storage engine, and TiDB is one of the famous examples.

But why should I talk about LevelDB instead of RocksDB? The reason is that the LevelDB technical architecture is simpler, clearer and easier to understand. It will be very easy to understand if we have a thorough understanding of LevelDB first and then take a look at RocksDB. RocksDB is just a series of optimizations based on LevelDB. When we break the RocksDB problem, TiDB's nuclear-powered spaceship is already greeting us not far ahead.

What’s wrong with Redis caching?

When we use Redis as a cache, there is usually still a persistent database that records complete cold and hot data. Data consistency between Redis and the persistence layer database is controlled by the application itself. When there is no data in the cache, the application needs to load the data from the persistence layer and put it into the cache. When data updates occur, the cache needs to be invalidated.

function getUser(String userId) User {<br/>  User user = redis.get(userId);<br/>  if user == null {<br/>    user = db.get(userId);<br/>    if user != null {<br/>      redis.set(userId, user);<br/>    }<br/>  }<br/>  return user;<br/>}<br/><br/>function updateUser(String userId, User user) {<br/>  db.update(userId, user);<br/>  redis.expire(userId);<br/>}<br/>

Friends who have development experience in this area know that writing such code is quite tedious. All business codes involving caching need to add this part of logic.

Strictly speaking, we also need to carefully consider cache consistency issues. For example, in the updateUser method, the database correctly performs the update, but the cached redis fails to be invalidated due to network jitter and other reasons. Then the data in the cache It becomes expired data. Readers can consider that even if the order of setting up cache and updating persistent storage is reversed, other problems may still arise.

High concurrency situations with multiple processes can also lead to cache inconsistency. For example, if a process calls the getUser() method on a certain userId, because it is not in the cache, it needs to be loaded from the database. The results have just been loaded and we are about to set up the cache. At this time, the memory fullgc code is paused for a while, and at this time another process calls the updateUser method to update the database and invalidate the cache (in fact, there is no cache in the cache. data). Then the previous process finally finishes fullgc and starts setting up the cache. At this time, the expired data is cached.

How is LevelDB solved?

LevelDB combines the Redis cache and persistence layer into one, helping you handle the cache and persistence layer at once. With LevelDB, your code can be simplified as follows

function getUser(String userId) User {<br/>  return leveldb.get(userId);<br/>}<br/><br/>function updateUser(String userId, User user) {<br/>  leveldb.set(userId, user);<br/>}<br/>

And you no longer have to worry about cache consistency issues. LevelDB's data updates are either successful or unsuccessful, and there is no intermediate Schrödinger state. Users do not need to pay attention to the details of data consistency because LevelDB integrates memory cache and persistence layer disk files internally.

What exactly is LevelDB?

We mentioned before that it is a non-relational storage engine, which is different from the concept of Redis. Redis is a complete database, while LevelDB is just an engine. If the database is compared to a high-end sports car, the storage engine is its engine, that is, its core and heart. With this engine, we can package it with a series of accessories and decorations to become a database. However, don’t underestimate accessories and decorations. It is very difficult to achieve the ultimate. Packaging LevelDB into a simple and easy-to-use database requires adding too many exquisite accessories. LevelDB and RocksDB have been around for so many years, but very few can build a complete production-level database based on them.

LevelDB can be viewed as an in-memory key-value database. It provides a basic Get/Set API through which we can read and write data in code. You can also think of it as an advanced HashMap of unlimited size. We can stuff unlimited Key/Value data into it as long as the disk can fit it.

Because it can only be regarded as an in-memory database, the data stored in it cannot be shared between processes or machines. In the distributed field, how can LevelDB show its talents?

To achieve this, the network API needs to be wrapped on top of the LevelDB in-memory database. When multiple processes are located on different machines and want to access the resource, they must all access it uniformly through the network API interface. This forms a simple database. Apply the Redis protocol to encapsulate the network layer, and you can use the Redis client to read and write the database.

If we want to consider the high availability of the database, we can transform it into a distributed NOSQL database with a master-slave structure by adding the master-slave replication function to the above stand-alone database. Adding a layer of forwarding proxy (load balancer such as LVS, F5, etc.) in front of the master-slave database can achieve real-time switching of the master-slave database.

If the data capacity you need is so large that the hard disk of a single machine cannot accommodate it, then a data sharding mechanism is needed to distribute the entire database data to multiple machines, and each machine is only responsible for reading part of the data. Write work. There are many data sharding solutions. You can shard through forwarding agents like Codis, or use client forwarding mechanism like Redis-Cluster. You can also use TiDB's Raft distributed consistency algorithm to manage shards in groups. piece. The simplest and easiest to understand is Codis' forward proxy sharding.

When the amount of data continues to grow and new nodes are required, the data on the old node must be partially migrated to the new node. A new advanced accessory is used to manage the balancing and migration of data - data balancing. device.

The above is the detailed content of How to solve Redis cache problem. For more information, please follow other related articles on the PHP Chinese website!