Some test friends came to ask me, how to test redis? First of all we need to know, what is redis? what can it do
Redis is a high-speed storage database of key-value type.
Redis is often used as: cache, queue, publish and subscribe, etc.
Therefore, the question "how to test redis?" can be transformed into:
- How to test the cache?
- How to test the queue?
- How to test subscription?
In the technology stack I have come into contact with, redis is rarely used for publish and subscribe. Let's mainly talk about cache and queue.
01. Cache classification
There are several types of caches: file caches, database caches, memory caches, browser caches.
Browser caching refers to the browser's own caching capabilities. In order to speed up page loading, modern browsers often download resource files such as css and js once and then cache them for a period of time until the cache fails or the request explicitly informs that they need to be updated.
If the interface is output through direct rendering of the back-end language , smarty and other template rendering methods , the file type cache is generally selected.
Figure - file cache
With the rapid development of large front-end technology, the separation of front-end and back-end becomes more and more popular, and the smarty rendering method is used less and less, and the interface response time requirements for back-end services are also getting higher and higher. File caching is no longer suitable for this scenario. Database caching is becoming more and more popular.
The most common database caches are: redis and memcached. They are both distributed key-value cache systems.
Above - redis cache
Memory cache is similar to database cache, but limited by the technology stack. For example, Java can be used, and Java is used very frequently, but PHP cannot be used. The memory cache is faster than the database cache, but because the memory cannot be increased all the time, it has more restrictions, and problems such as memory leaks will occur if you don't pay attention.
In actual use, the Java interface often stuffs some high-frequency data into the memory cache as the first-level cache, and stuffs the sub-high-frequency data into redis as the second-level cache, and finally queries the data from the db.
Picture above - combination use
The role of caching:
From the above content, you may already know that the two most important functions of caching are to speed up access and reduce server and db pressure.
02. Usage scenarios of caching
You may ask, the above has nothing to do with testing? No, I think knowing the above is still helpful for testing. Do you know when to add cache and when not to add cache in terms of technical implementation ? This is the technical control of an interface, which not only needs to be known by developers, but also by testers.
Don’t you feel proud if you discover an interface that should add caching without adding caching before the pressure test? In fact, it corresponds to the role of the cache one by one. When the qps of the interface is high (for example, more than 100) or there is a requirement for response speed, or the server performance and DB performance are poor, you can try to use the cache to solve the problem.
Let me give a few examples:
1. In the new version of WeChat, there is an additional "status" function in the personal center.
The number of WeChat users is very large, and the access qps is very high. Hundreds of thousands of people visit at the same time, and it is impossible to query the database every time.
Similar to this kind of demand, the general approach is: first cache the user's state data in the app (browser cache), and call the back-end interface to request "state" data by actively pushing or passively pulling in a certain period of time ;The interface reads data from the redis/memcached cache and returns it; if the amount of data is not so large, the interface can directly read data from the memory cache and return it; after the data is returned, the cache in the user app is updated.
Above - Example 1
2. There is a product management background list page of a small e-commerce company. The number of visitors is not large, and the frequency of sku changes is very low. It may be visited dozens of times in 3 days. This kind of scenario does not need to use caching, and second, you need to see the updated data immediately after the product information is updated, which is not suitable for caching, so it is not recommended to use caching.
3. The same e-commerce management background, this time it is a statistics page, which counts the sales of goods yesterday/today/nearly a week.
There are many different solutions for this scenario.
(We put aside various technical solutions for big data statistics, and simply realize the statistical function of a system)
- No need for real-time statistics
, only need to make regular statistics once, for example, only look at yesterday’s statistical data: it can be directly stored in db after statistics by timing script, and directly query db when you need to view statistical data - It is necessary to query real-time statistical data
, but the execution efficiency of each statistical SQL that needs to be queried meets expectations: every time you view the data, you can directly query the db, and the pressure on the db is not high at this time - Real-time statistical data needs to be queried
and due to the huge business data, the execution efficiency of each statistical sql is very low or cannot be directly counted: various indicators can be summarized and the statistical values can be maintained in the cache. For example, sales information is required. Value cache +1, just query the cache at this time when viewing statistics
03. How to generate cache
After understanding the usage scenarios of the cache, let's talk about how the cache is generated.
Generally speaking, there are two ways to use the cache, which I briefly summarize as: outside and inside .
First, let’s talk about how an interface request is processed in the program:
Figure above - program processing flow
This is a typical MVC, the Controller receives and processes the request data, the Service processes the data obtained in the Model, and then the View outputs it.
For different scenarios, we can take multiple ways to add different caches on multiple nodes to solve different problems.
For example, in response to changing request parameters, if the returned data is strongly related to the request parameters, it is suitable to cache the queried data "outside" (after the request parameters are filtered). This type of data is generally cached for a short period of time, such as 5 minutes. It mainly deals with repeated requests with the same request parameters in a short period of time. If you encounter a request attack, even if the cache validity period is only 1 second, it is still very effective and can block a large number of requests.
Above - caching "out there"
For example, in the case that the request parameters do not change much and the returned data is very close to the data stored in the db, it is suitable to cache the data "inside", that is, update the cache while updating the db. In the optimal state of this situation, Only needing to read the cache is enough, and there is no need to interact directly with the db, which can greatly relieve the pressure on the db. This cache validity period can be set very long.
Above - "inside" the cache
04. How to update the cache
After talking about the generation, let's talk about the update of the cache. After the cache is generated, it will not remain unchanged normally, so the cache needs to be updated.
There are several ways to update:
- Auto-renew after expiration: This is the laziest way to renew. By setting the validity period of the cache, a new cache is automatically created through a new request after the cache expires.
- Delete cache: After updating the db data, delete the cache directly, and automatically create a new cache through a new request.
- Reset the cache: After updating the db data, reset the cache directly.
05. Redis cache test point
1. Performance testing angle
Whether the cache increase/update function is correct, check whether the cache data is correct
- Add related logs, view logs
- backdoor tool
- Using the command line, memcached and reids can log in and view directly
cache delete
- Valid cache, verify related business functions
- The cache is deleted and the relevant business functions are verified
- The cache expires and expires, memcached and redis can set the expiration time, check whether there is an expiration time, right?
Excessive Elimination Mechanism: What to Do When the Cache Reaches the Upper Limit
cache penetration
cache avalanche
redis cache service stopped
cache timeout
After the cached data is modified by mistake, quickly restore to the specified version
After the cache data is deleted by mistake, quickly restore the data
2. Redis function test angle
- When the redis data takes effect, is the reading correct?
- The redis data does not exist, can you read the correct value from the db normally, write it into Redis and return it to the upper layer
- Is the performance normal when the data does not exist in redis and db?
- When deleting data, is the data in redis and db consistent?
The following is the supporting information. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
Information acquisition method:
