How to use Redis for scheduled inventory caching function

1. Business background

I decided to compare this question to the questions on the exam paper to avoid introducing the background of our company's projects. As for the details of the business, you don’t need to pay attention to it~ Just read the title:

Suppose you are the best collector in a certain country, and you have various treasures with continuous value in your hands. One day you may feel that your collection is getting boring and decide to sell these valuable items for cash.

But it is too low to sell these valuable treasures in the vegetable market. In the "Internet" era, of course we have to play some different selling methods: there is a 300-room building (numbered 001 to 300) in your name, and each room has a password-locked safe. In the next month ( Every day from December 1st to December 31st), you will select 300 of the best "top treasures" (also called Class A treasures) and put them in the safes of these 300 rooms, each room every day The treasures to be placed have already been decided. Anyone who wants to buy treasures must make a reservation online at least one day in advance, and then use the reservation code to open the safe and pick up the goods. Treasures that are not reserved will be taken back by you and will no longer be sold.

To build such an online reservation system, its front-end interface may look like this:

Click on the three controls to be filled in in the picture above. A selection box will appear. The problem now is that there is only one treasure in a room and it cannot be booked twice. After the buyer selects the treasure type and room number, it is recommended to provide some prompt information in the date selection box when they select the reservation date. For example, room No. 051 has been booked on December 3, and now another user has selected room No. 051. Then when the date selection box pops up, December 3 must be set as unselectable. As shown below (December 3rd is displayed as "missing"):

So, how can such a simple inventory system be stored in redis?

2. Inventory Management Solution (Redis)

Our initial idea is that our inventory can be regarded as a huge three-dimensional array, where the first dimension represents the treasure type, and the second dimension The first dimension represents the room number, and the third dimension represents the reservation date. Redis provides five storage types: String, Hash, List, Set, and Sorted Set. We can use the Hash type to store data in the current scenario because it can meet our needs, and the Set type is also a feasible option.

The key of Redis is set to the treasure type room number (for example, A:205, A represents the best treasure, 205 is the room number), the value of Redis is the hash type, and the hash key is the date (for example, 2016-12-05 ), the hash value is true or false, indicating that it has been booked or not. The graphic representation is:

If Room 158 of Category A treasure has been booked on December 8, it will be stored as

3. Advanced Scenario & Inventory Management Solution

The launch of Class A top treasures has been warmly welcomed, and a large number of orders have already been placed shortly after its launch. Many middle-class people are interested in collecting, but the high prices often put them off. So, you choose type B treasures from your collection. It is slightly inferior to type A treasures, but the price is more reasonable, and it is also called "excellent treasure".

Since there are more treasures in type B than in type A, you plan to change the way of playing. In these 300 rooms, put a safe in each room. This time, you will put a safe in each room every hour. Put a B-type treasure into each of the 300 room boxes. The treasures that have not been reserved will be taken back after this hour and replaced with treasures for the next hour. After the buyer makes a reservation, he will pick up the treasure according to the scheduled hours. For Category B treasures, your reservation system will have an additional option, which is the pickup time. As shown in the picture below:

Now because there is an additional predetermined condition (pickup time), when doing inventory storage, if you think about it in a rough way, the inventory is actually a big four-dimensional array. This sentence can be rewritten as: The four-dimensional information includes treasure type, room number, reservation date and pickup time. How to store this kind of treasure in Redis?

In fact, if you think about it carefully, when storing Class A top-quality treasures, our storage in Redis is a waste of dimensions.

In fact, only one hashValue storage was used at that time The predetermined status is reached, causing the information in this dimension to be wasted. Considering that the pick-up time is all on the hour, that is, 0 to 1 o'clock, 1 to 2 o'clock,..., 23 to 24 o'clock, a total of 24 situations throughout the day, so we can completely use binary integers to represent the reserved items time. For example, 1 represents 0 to 1 point, 2 represents 1 to 2 points, 4 represents 2 to 3 points,...,

23 to 24 points can be represented by 2 to the 23rd power (8388608). To reserve multiple time periods, you only need to perform a logical OR operation on the values.

In this way, our Redis structure becomes like this:

For example, Class B treasure room 103, the morning of December 5th and 6th Booked from 8:00 to 12:00, stored in redis as

1 2 3

##Redis Key —— A:158 Redis Value —— hash table ['2016-12-08' => 1]

1 2 3

Redis Key —— B:103 Redis Value —— hash table [ '2016-12-05' => 3840, '2016-12-06' => 3840]

For B-type treasures, when making new reservations, you need to take out the original hash value first, do logical OR operation with the new scheduled pickup time, and then write the result back to Redis, instead of doing the same thing as Like Class A treasures, hSet is directly called to set the hash value; when canceling the reservation, pay attention to taking out the original hash value first, deducting the time period to be canceled from the hash value (XOR logical AND operation), and then re-setting the hash value. The remaining reserved pickup times are written back to Redis and cannot be deleted directly by calling hDel.

4. Advanced & Inventory Management Plan

Since the launch of Class B treasures, your business has become much more popular than before. So new demand has come again. Now there are a large number of tourists, students and other people without huge savings who are very interested in your treasures. People who come to this city want to bring some souvenirs back. Although the price of type B treasures is slightly lower than that of type A, it is still a bit expensive for these people. So, you decide to sell your most affordable treasures (Category C treasures).

Among these 300 rooms, Type C treasures store the largest number, so you add 100 treasure boxes specifically for storing Type C treasures in each room. These 100 treasure boxes are numbered No. 1, No. 2,..., No. 100. Similarly, every hour of the day, you will put a C-type treasure into the 100 treasure boxes in each of these 300 rooms (which means that the entire building will update 30,000 C-type treasures every hour). pieces). If no one makes a reservation, the treasure will be replaced the next hour. Finally, everyone's needs can be met.

For C-type treasures, your reservation interface will look like this:

We have added another reservation condition. At this time, we are faced with the problem of inventory storage. As usual, this inventory is actually a large five-dimensional array. The treasure type, room number, reservation date, pickup time, and treasure box number each occupy one dimension. We have used up all the capacities of Redis before. What should we do now to store data?

This time the Redis inventory storage must be combined with business characteristics. First of all, the two dimensions of treasure chest number and pickup time do not have too many value ranges. There are only 100 treasure chest numbers. Just change the hash value into an array with a length of 100, and each position of the array contains INT. The pickup time indicated by the type is sufficient. However, the hash value can only be string... So, we have to do an array serialization operation, and then deserialize it back when reading. Fortunately, the length is only 100, so serialization efficiency will not become the bottleneck of the system.

The storage method is: On December 23rd and 24th, among the C-type treasures in Room 258, the treasure chests numbered 97 and 99 have been reserved between 11 am and 1 pm

##

Among them, 6144 is expressed in binary as "110000000000", and the hash value is the string after array serialization. The json format can be used in actual projects. Okay, now Redis has storage for three types of treasures.

For Category C treasures, when the user cancels a reservation or adds a new reservation, it is also not possible to simply call hSet and hDel to overwrite settings and delete. The already reserved situation must be taken out. , and perform bitwise operations with the scheduled pickup time.

5. Storage Optimization

The inventory is theoretically a multi-dimensional array. The main work we do is how to store each dimension reasonably and make it easy to add, delete and query. operate. From the perspective of saving memory, Redis can be empty when no one has made a reservation at the beginning. For Class A treasures, the hash value is equal to false and there is no corresponding redis key or hash key. Effective.

In addition, combining the treasure type and room number to make a redis key will result in a larger number of keys related to the treasure inventory in redis. In order to facilitate the unified management of these keys, we can add another redis cache. It is specially used to store all redis key values ​​related to treasure inventory, as shown in the figure below. It should be noted that in this case, using the set data type can meet the requirements, instead of using the hash data type, because the complexity of addition, deletion, modification and query of the set data type is O(1). It stores all inventory key values ​​that already exist in redis.

One advantage of doing this is that if we encounter some special circumstances one day and need to clear all inventory-related caches, we can easily remove all Inventory key and delete it. Another benefit is that it provides us with ideas for continued expansion... Imagine that the most complicated situation now is type C treasures, with a total of 5 dimensions. Suppose in the future, you no longer use 300 rooms in one building to sell treasures, but multiple buildings, then users will have to add another dimension when placing orders - the building number. When encountering this situation, we can completely reduce the extra inventory Key set to building numbers for use, ensuring scalability in more complex situations that may arise.

After this expansion, every time you add a new reservation record, you need to check whether the corresponding redis key value already exists in the inventory key set. If it does not exist, you need to add the redis key value to the inventory key set. middle. The deletion operation is similar.

1 2 3

##Redis Key —— C :258 Redis Value —— hash table ['2016-12-23' => ; '[97 => 6144, 99 => 6144]', '2016-12-24' => ; '[97 => 6144, 99 => 6144]' ]

The above is the detailed content of How to use Redis for scheduled inventory caching function. For more information, please follow other related articles on the PHP Chinese website!