- Some ideas of redis caching in the project
- Why not use redis as cache
Some ideas of redis caching in the project
First, there are three types of cached objects
1. For a single piece of data in the database (the table name and ID are permanently saved to redis as keys), the cache should be updated where there are updates (not applicable to data that needs to be updated frequently);
2. For some non paged lists that do not require real-time (multi table query), we can cache the list results in redis and set a certain cache time as the survival time of the data. Use the method name of obtaining the list as the key, and the list result is value; This situation is only used when it is not updated frequently and does not need to be updated in real time.
3. List that does not need real-time paging: you can put the paging result list into a map (key is the paging ID and value is the paging result), and then save the map to redis’s list (named key with this method). Then set a cache lifetime for the list (use expire). In this way, the data of the paging list can be obtained through the method name lrange, and the list can be traversed. Whether the paging data is in the cache can be determined by traversing the key of the map in the list. If yes, it will be returned, and if it does not exist, it will be rpush in. This method can solve the problem that the data of 1-5 pages has been reloaded, while the data of 6-10 pages is still cached data, resulting in dirty data.
Some detours I have taken
1. For data caching, it is not good to cache everything in redis, but cache some data with little change or high access rate to reduce the pressure of relational database.
2. Don’t try to judge whether there is a cache in the interceptor or filter, because every request (no matter whether the method corresponding to the request is cached or not) will go to redis to request data and judge, which will waste some memory resources and response time. Therefore, we should judge the methods that need caching.
3. If multiple get or set methods are used in a method, we need to minimize the need to obtain jedis objects in the jedispool. Therefore, we should only obtain jedis objects once in a method and return the object to the connection pool at the end of the method, so as to be as efficient as possible.
4. When setting the parameters in the connection pool, you should consider your own system requirements. Otherwise, there will often be unnecessary errors and waste of resources, such as no available object acquisition in the connection pool, spring initiating connection requests to redis from time to time.
Why not use redis as cache
We all know that using redis for caching is very fast, but in fact, sometimes we do not use redis for caching, but use local caching. For example, a project I contacted did not use redis as cache, but used table in Google toolkit as cache.
This table is actually a data structure. You can treat it as a map. Now let’s draw two pictures, one using table as cache and the other using redid as cache
Use table as local cache
Using redis as cache
The company adopts local caching, so why not adopt redis
Let’s think about the following questions
1. Is it fast to access local service cache or remote service redis?
There is no doubt that it is faster to access the cache of local services. Redis is on remote services after all. Assuming that the delay of accessing the local service cache is 50ms, the verification of accessing the remote redis may reach 58ms. This is the advantage of using local caching services
2. IDS transaction
In redis, although redis operations can guarantee atomicity, transactions in redis cannot guarantee atomicity. For example, if user a wants user B to transfer money, how to ensure its transactions
3. Redis will have one more IO
Although redis data is stored in memory, redis persistence operation will still write data to disk, which will increase the time-consuming of IO operation. The local cache only uses a data structure to store data without io
So what is the problem with using local caching?
For example, the data of user a is stored on the exchange1 node, while the data of user B is stored on the exchange2 node. Now, if user a wants to transfer money to user B, it will be more troublesome. It needs to do some other operations, which is a big disadvantage of using local cache
When will redis be used?
As the company’s project is a stock exchange, it has high requirements for delay and wants to achieve as low delay as possible, so it finally abandons the use of redis. For some projects that do not pay much attention to delay, it is very good to use redis for caching
The above is my personal experience. I hope I can give you a reference, and I hope you can support developpaer.