Some test friends came to me and asked me, how to test redis? First 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 for: cache, queue, publish and subscribe, etc.
Therefore, the question "How to test redis?" can be transformed into:
-
How to test cache?
-
How to test queue?
-
How to test subscription?
In the technology stack I am exposed to, redis is rarely used for publishing and subscription. We mainly talk about caching and queues.
01 Classification of cache
There are several types of cache: file cache, database cache, memory cache, browser cache.
Browser cache 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 expires or the request explicitly informs that they need to be updated.
If the interface is output through direct rendering in the back-end language or template rendering such as smarty , file type caching will generally be selected.
Figure--File cache
With the rapid development of big front-end technology, the separation of front-end and back-end is becoming more and more popular, smart rendering is used less and less, and the interface response time requirements for back-end services are 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 currently: redis and memcached. They are both distributed key-value caching systems.
Above - redis cache
Memory cache is similar to database cache, but it is limited by the technology stack. For example, Java can be used, and it is used very frequently in Java, 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. If you are not careful, problems such as memory leaks may occur.
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.
Pictured above - combined use
The role of cache:
From the above content, you may already know that the two most important functions of cache are to speed up access and reduce server and DB pressure.
02 Cache usage scenarios
You may ask, does the above have nothing to do with testing? No, I think it is helpful to know the above 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. Not only developers need to know it, but testers also need to know it.
If an interface that should be cached is not cached and is discovered by you in advance before the stress test, wouldn't you feel proud? In fact, it corresponds to the role of cache. When the qps of the interface is high (for example, more than 100) or the response speed is required, or the server performance and db performance are poor, you can try to use cache to solve the problem.
Let me give a few examples:
1. In the new version of WeChat, the personal center has an additional "status" function.
WeChat has a very large user base and access QPS is very high. Hundreds of thousands of people access it at the same second. It is impossible to query the database every time.
For requirements like this, the general approach is as follows: first cache the user's status data in the app (browser cache), and then call the backend interface to request "status" data in a certain period of time through active push or passive pull. ;The interface reads data from the cache of redis/memcached and returns it; if the amount of data is not so large, the interface can directly read the 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 backend list page of a small e-commerce company. There are not many visitors, and the frequency of SKU changes is very low. It may be visited dozens of times in three days. In this scenario, there is no need to use cache, and second, the updated data needs to be seen immediately after the product information is updated. It is not suitable to use cache, so it is not recommended to use cache.
3. The same e-commerce management backend, this time a statistics page that counts the sales of goods yesterday/today/the past week.
This scenario can be viewed on a case-by-case basis, and there are many different solutions.
(We put aside various technical solutions for big data statistics and simply implement the statistical function of a system)
-
No real-time statistics required
You only need to count statistics once at a scheduled time. For example, you only need to see yesterday's statistics: you can directly store them in the db after counting by the scheduled script. When you need to view the statistics, you can directly query the db.
-
Need to query real-time statistical data
However, the execution efficiency of each statistical SQL that needs to be queried meets expectations: you can query the db directly every time you view the data, and the db is not under much pressure at this time.
-
Need to query real-time statistical data
And due to the huge amount of 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 are maintained in the cache. For example, if sales information is required, for each item sold, the sales statistics value cache + 1, Just query the cache at this time when viewing statistics.
03 How to generate cache
After understanding the usage scenarios of cache, let's talk about how to generate cache.
Generally speaking, there are two ways to use cache. I can briefly summarize it as: outside and inside .
First, let’s talk about how an interface request is processed in the program:
Pictured above - program processing flow
This is a typical MVC. The Controller receives and processes the request data, the Service processes the data obtained from the Model, and then the View outputs it.
For different scenarios, we can adopt various methods and add different caches on multiple nodes to solve different problems.
For example, if the request parameters are variable and the returned data is strongly related to the request parameters, it is suitable to cache the queried data "outside" (after filtering the request parameters). This type of data is generally cached for a short time, such as 5 minutes. It mainly deals with repeated requests with the same request parameters within a short period of time. If you encounter a request attack, even if the cache is valid for only 1 second, it is still very effective and can block a large number of requests.
Above - Caching "outside"
For example, if the request parameters change little 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 this optimal state, It is enough to read the cache without directly interacting with the db, which can greatly relieve the pressure on the db. This cache validity period can be set to a very long time.
Above - Caching "inside"
04 How to update cache
After talking about generation, let’s talk about cache update. After the cache is generated, it will not remain unchanged, so the cache needs to be updated.
There are several ways to update:
-
Automatically update after expiration: This is the laziest way to update. By setting the cache validity period, a new cache will be automatically created with new requests after the cache expires.
-
Delete the cache: After updating the db data, delete the cache directly and automatically create a new cache through new requests.
-
Reset the cache: After updating the db data, directly reset the cache.
05 redis cache test point
1. Performance testing perspective
Is the cache add/update function correct? Check whether the cache data is correct.
-
Add related logs and view the logs
-
Backdoor interface tool
-
Using the command line, memcached and reids can be viewed directly after logging in.
Cache deletion
-
The cache is valid and relevant business functions are verified.
-
The cache is deleted and relevant business functions are verified.
-
Cache expires and expires. Memcached and redis can set the expiration time and check whether there is an expiration time, right?
Excess elimination mechanism: What to do if the cache reaches the upper limit
cache penetration
cache avalanche
The redis cache service is stopped
cache timeout
After the cached data is accidentally modified, quickly restore it to the specified version.
Quickly restore cached data after it is accidentally deleted
2. Redis functional testing perspective
-
When the redis data takes effect, is the reading correct?
-
The redis data does not exist. Can the correct value be read from the db normally and written to Redis correctly and returned to the upper layer?
-
Is the performance normal when the data does not exist in redis or db?
-
When deleting data, are the data in redis and db consistent?
Finally: The complete software testing video tutorial below has been compiled and uploaded. Friends who need it can get it by themselves [guaranteed 100% free]
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.