Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to use Redis to do the relevant knowledge of the scheduled inventory cache function, the content is detailed and easy to understand, the operation is simple and fast, and it has certain reference value. I believe everyone will have some gains after reading this article on how to use Redis to do the scheduled inventory cache function. Let's take a look at it together.

I. Business Background

In order to omit the background of our company project, I decided to analogize this question to a question on a test paper. As for the details of the business, you don't need to pay attention to it ~ just look at the topic:

Suppose you are a country's most cattle collectors, hands have a variety of values linked to the treasure. Until one day, you decided that collecting was too boring and decided to sell these treasures for some cash.

However, selling these valuable treasures in the vegetable market was too low. In the "Internet +" era, of course, we have to play some different selling methods: There's a 300-room building in your name.(numbered 001 to 300), a combination lock safe in each room, next month Every day (December 1 to December 31), you will select 300 of the best "best treasures"(also known as Class A treasures) and put them into the safes of these 300 rooms. What treasures will be placed in each room every day has been determined. All those who want to buy treasures must book online at least one day in advance, and then open the safes themselves with the reservation code. Unreserved items will be taken back by you and will no longer be sold.

To make such a network reservation system, its front-end interface is roughly like this:

The three controls to be filled in in the above picture, click to appear selection box. The problem now was that there was only one treasure in a room and it could not be booked repeatedly. So after the buyer selects the item type and room number, when selecting the scheduled date, give the user a prompt in the date selection box. For example, room 051 has been reserved on December 3, and now another user selects room 051. When the date selection box pops up, December 3 should be set as not selectable. As shown below (shown as "missing" on December 3):

So, how does such a simple inventory system store in redis?

II. Inventory Management Scheme (Redis)

The crudest idea is that our inventory is really a large three-dimensional array, the first dimension is the treasure type, the second dimension is the room number, and the third dimension is the scheduled date. Redis supports 5 storage types: String, Hash, List, Set, Sorted Set. In the current scenario, both Hash and Set types can meet the requirements, so we choose to use Hash type for storage.

The key of Redis is set as treasure type + room number (e.g. A:205, A represents the best treasure, 205 is the room number), the value of Redis is hash type, hash key is date (e.g. 2016-12-05), hash value is true or false, indicating that it has been reserved or not. Illustrated as:

If Class A Treasure Room 158 has been reserved on December 8, store as

1

2

3

Redis Key -- A:158

Redis Value -- hash table ['2016-12-08' => 1]

III. Advanced Scenario & Inventory Management Scheme

The Class A treasure you launched was very popular, and it was booked a lot soon after it was launched. However, the price of hundreds of thousands of yuan also makes many interested in collecting, but not so rich middle class deterred. Therefore, you selected a Class B treasure (also known as a "high-quality treasure") from your own collection, which is slightly inferior to Class A treasures. The price is more affordable.

Since there are more Class B treasures than Class A treasures, you want to change the way you play. In these 300 rooms, each room has another safe. This time, you will put a Class B treasure into each of the 300 rooms every hour. The treasures that are not reserved will be taken back after this hour and replaced with treasures for the next hour. After the buyer orders, he will pick up the treasure according to the scheduled hour. For Class B treasures, your reservation system will have an additional option, namely the time of collection. As shown below:

Now, because there is an additional predetermined condition (pickup time), when doing inventory storage, think roughly, inventory is actually a large four-dimensional array. The first dimension is treasure type, the second dimension is room number, the third dimension is scheduled date, and the fourth dimension is collection time. How do you store this kind of treasure in Redis?

In fact, think about it carefully. When storing Class A top-grade treasures, our storage in Redis is a waste of dimensions.

At that time, hashValue only had one true to indicate that there was a reservation, and this dimension was actually wasted. Considering that the pickup time is all on the whole hour, that is, 0 to 1 o'clock, 1 to 2 o'clock,..., 23 to 24 o'clock, a total of 24 cases, so we can use binary integers to express the scheduled time. For example, 1 means 0 to 1 o'clock, 2 means 1 to 2 o'clock, 4 means 2 to 3 o'clock,...

8388608 (= 2^23) represents 23 to 24 points. A plurality of time periods are predetermined, and only the logical OR operation of the numerical value is required.

So our Redis structure looks like this:

For example, Class B Treasure Room 103, reserved from 8 a.m. to 12 a.m. on December 5 and 6, is stored in redis as

1

2

3

Redis Key -- B:103

Redis Value -- hash table ['2016-12-05' => 3840, '2016-12-06' => 3840]

For Class B treasures, when making a new reservation, you need to pay attention to taking out the original hash value first, doing a logical OR operation with the new scheduled picking time, and then writing the result back to Redis, instead of directly calling hSet to set the hash value like Class A treasures; When canceling the reservation, pay attention to taking out the original hash value first, subtracting the time period to be cancelled from the hash value (exclusive OR + logical AND operation), and then writing the remaining reserved pickup time back to Redis, instead of calling hDel directly to delete it.

IV. Advanced again & inventory management scheme

Ever since the introduction of Class B treasures, your business has been much more prosperous than before. So new demand has come, now there are a large number of tourists, student parties and other people who do not have rich savings expressed great interest in your treasures, people who come to the city to travel want to bring some souvenirs back. However, although Class B treasures were cheaper than Class A treasures, they were still a little expensive for these people. Therefore, you decided to sell your most valuable treasure (Class C treasure).

This section has the largest number of treasures, so you add 100 chests to each of these 300 rooms, which are specially used to store Class C treasures. These 100 treasure chests were numbered 1, 2,..., 100. Similarly, every hour of the day, you will place one Class C treasure into each of the 100 treasure chests in each of the 300 rooms (which means that the entire building will update 30000 Class C treasures every hour). If there is no reservation, the treasure will be replaced in the next hour. Finally, everyone's needs could be satisfied.

For Class C items, your booking interface looks like this:

We've got one more reservation. At this point, we are faced with the problem of inventory storage. As usual, this inventory was actually a large five-dimensional array. Treasure type, room number, reservation date, collection time, and treasure chest number each occupied a dimension. However, our Redis dimensions are basically full. How should we store them this time?

This time Redis inventory storage must be combined with business characteristics. First of all, the two dimensions of treasure chest number and retrieval time could not take too many values. There were only 100 treasure chest numbers. As long as the hash value was changed into an array with a length of 100, each position of the array would have the retrieval time represented by the INT type. However, hash value can only be string... So, I have to do an array serialization operation, and then deserialize it back when reading it. Fortunately, the length was only 100, so serialization efficiency was not a bottleneck for the system.

For example, Class C treasures, December 23 and 24, Room 258, Treasure Chest 97 and 99 were reserved between 11:00 and 13:00, and the storage was as follows:

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]' ]

Where 6144 is expressed as '11000000000' in binary, hash value is the string after array serialization, and json format can be used in actual projects. All right, Redis now has storage for all three treasures.

For Class C treasures, when the user cancels the reservation or adds a reservation, it is also impossible to simply call hSet and hDel to set and delete the overwrite. To take out the reserved situation, it is necessary to do a bit operation with the predetermined picking time.

V. Storage optimization

Inventory is a multidimensional array in theory, the main work we do is how to store each dimension reasonably, and can easily add, delete and query operations. From the perspective of saving memory, when no one has reserved it at the beginning, Redis can be empty. For Class A treasures, hash value equals false and there is no corresponding redis key or hash key.

In addition, the combination of treasure type and room number as redis key will lead to a large number of keys related to treasure inventory in redis. In order to facilitate unified management of these keys, you can add a redis cache to store all redis key values related to treasure inventory, as shown in the following figure. Note that this time we don't need hash data type, set type is enough, add, delete and change the complexity of O(1). It stores all the inventory key values that already exist in redis.

One advantage of doing this is that, in the event that we encounter some special situation and need to empty all the inventory related caches, we can easily take out all the inventory keys and delete them. Another benefit is that it gives us a way to continue expanding…Imagine that the most complex situation now is a Class C treasure, with a total of five dimensions. Suppose in the future, instead of using 300 rooms in a building to sell treasures, you have multiple buildings, so users have to add another dimension-building number when placing orders. In this case, we can completely degenerate this extra inventory Key set into a building number to use, ensuring scalability in more complex situations that may occur.

After this expansion, each time a predetermined record is added, it is necessary to check whether the corresponding redis key value already exists in the inventory key set. If there is no redis key value, it is necessary to add the redis key value to the inventory key set. Deletion is similar.

About "how to use Redis to do predetermined inventory cache function" The content of this article is introduced here, thank you for reading! I believe everyone has a certain understanding of the knowledge of "how to use Redis to do predetermined inventory cache function." If you still want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.