Use Redis for pre-stock Cache

Use Redis for pre-stock Cache

Recently, in my work, I gradually switched the cache of one of the PHP projects from the previous APC cache to Redis, and implemented inventory maintenance based on the data structure supported by Redis. The cache is implemented at the business layer. It should be accurate to the ORM of the Model in the MVC Model. The main logic is to check the cache first. If the cache cannot be found, check the database again. However, these are not the main content of this article. I will share with you the cache design ideas of the inventory management function, hoping to bring you some gains, shortcomings, or better solutions, I hope you will give me more advice.

I. business background

In order to skip the background of our company's project, I decided to compare this question to a question on the examination paper. You do not need to pay attention to the business details ~ You can view the question:

Assume that you are the best collector in a country, and you have various valuable treasures in your hands. One day, you thought it was too boring to make a collection, and you planned to sell these treasures for some cash.

However, it is too low to sell these valuable treasures on the vegetable market. In the "Internet +" era, we certainly want to do something different: There is a 300-room building under your name (numbers 001 to 300), each room has a password lock safe, on every day of the next month (September 31-September 31), you will select 300 of the best "best treasures" (also known as class A treasures ), put them in the safe boxes of these 300 rooms. Every day, the treasure of each room has been settled. Everyone who wants to buy the treasure must book it online at least one day in advance, at that time, use the booking code to open the safe box to pick up the goods. You will not sell any unused treasures.

The front-end interface of a network reservation system is like this:

Click the three widgets to be filled in. The Selection box is displayed. The problem is that a room has only one treasure and cannot be reserved repeatedly. Therefore, after the buyer selects the treasure type and room number, when selecting the reservation date, a prompt should be given to the user in the date selection box. For example, if another user selected room 051 on April 9, the date selection box is displayed. For example, ("missing" is displayed on January 1, December 3 "):

So how can we store such a simple inventory system in redis?

Ii. Inventory Management Solution (Redis)

The most crude idea is that our inventory is actually a very large 3D array, the first dimension of the treasure type, the second dimension of the room number, the third dimension is the predetermined date. Redis supports five storage types: String, Hash, List, Set, Sorted Set. In the current scenario, both the Hash and Set types can meet the requirements. Here we choose to use the Hash type for storage.

The key of Redis is set to the treasure type + room number (for example, A: 205, A represents the best treasure, and 205 represents the room number), and the value of Redis is the hash type, the hash key is a date (for example,), and the hash value is true or false, indicating that it has been scheduled or not. Shown as follows:

If room 158 of Class A treasures has been booked in December 8

Redis Key-A: 158

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

Iii. Advanced scenarios & Inventory Management Solutions

The Class A treasures you launched are very popular and will soon be booked out. However, the price of hundreds of thousands of yuan is also prohibitive for many middle classes that are interested in collections but not so wealthy. As A result, you have selected class B treasures (also known as "high-quality treasures") from your favorites, which are more affordable.

Because there are more class B treasures than Class A treasures, you are going to use another method. In these 300 rooms, each room has another safe deposit box. This time, every other hour, you place a type-B treasure into the boxes of the 300 rooms. The unordered treasure will be reclaimed after this hour and replaced with the treasure of the next hour. After the buyer makes a reservation, the buyer will take away the treasures according to the specified hour. For Class B treasures, your booking system will have an option, that is, the pick-up time. For example:

Now, because there is an additional pre-condition (pick-up time), the stock is actually a large four-dimensional array in a rough way when you are doing inventory storage. The first dimension treasure type, the second dimension room number, the third dimension reservation date, and the fourth dimension Goods receiving time. How to store such treasures in Redis?

In fact, when we store the best treasures of Class A, our storage in Redis is A waste of dimensions,

At that time, only one true value was saved in hashValue to indicate that there was a reservation. This dimension was actually wasted. Considering that the pickup time is full, the whole day is to, ,......, There are 24 situations from to, so we can use a binary integer to indicate the scheduled time. For example, 1 indicates 0 to 1, 2 indicates 1 to 2, 4 indicates 2 to 3 ,......,

8388608 (= 2 ^ 23) indicates to 24. Multiple time periods are scheduled. You only need to take the values for logic or operation.

In this way, our Redis structure becomes like this:

For example, room 103 of Class B treasures was booked from eight o'clock A.M. to on October 11 and 6, and stored

Redis Key -- B: 103

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

For Class B treasures, when creating a new reservation, you must first extract the original hash value and perform logic or operations on the new reservation time, and then write the result back to Redis, instead, you cannot directly call hSet to set the hash value like A. When canceling A reservation, you must first retrieve the original hash value, remove the time period to be canceled from the hash value (XOR + logic and operation), and then write the remaining pre-purchased time back to Redis, rather than directly calling hDel to delete it.

4. Advanced and inventory management solutions

Since the launch of Class B treasures, your business has become more popular than ever before. As a result, new demands have emerged. Now there are a large number of tourists, student parties, and other people who have no rich savings to express their interest in your treasures, people traveling in this city want to bring some souvenirs back. However, although class B treasures are cheaper than Class A treasures, they are still A little expensive for these people. Therefore, you decide to sell the most affordable (Class C) treasures.

The largest number of treasures exists, so you have added 300 treasure boxes in each of the 100 rooms to store Class C treasures. These 100 treasure boxes are numbered 1, 2 ,......, 100. Similarly, every hour of every day, you place a C-type treasure in the 300 treasure chest of every 100 rooms (that is, the entire building will update 30000 Class C treasures every hour ). If no one has made a reservation, the treasure will be replaced in the next hour. Finally, this can satisfy everyone's needs.

For Class C treasures, your booking interface looks like the following:

We have another reservation condition. At this time, we are faced with the problem of inventory storage. As an example, this inventory is actually a large five-dimensional array. The treasure type, room number, reservation date, pick-up time, and treasure chest number each have a dimension. However, the above Redis dimensions are basically full. How should we store this time?

This Redis inventory storage must be combined with business characteristics. First of all, there are not many values available for the treasure chest number and pickup time dimensions. There are only 100 treasure chest numbers. You only need to convert the hash value into an array with a length of 100, each location in the array contains the pick-up time indicated by the INT type. However, hash value can only be string ...... As a result, we had to serialize an array and then deserialize it when reading it. Fortunately, the length is only 100, and the serialization efficiency does not become a bottleneck of the system.

For example, C-type treasures, room December 23, and treasure boxes 97 and 99 are reserved between and on May 25, 258, and are stored as follows:

Redis Key -- C: 258

Redis Value -- hash table ['2017-12-23 '=>' [97 => 2016, 99 => 6144] ', '2017-12-24 '=>' [97 => 2016, 99 => 6144] ']

Here, 6144 is represented as '123' in binary format, and hash value is the serialized string of the array. json format can be used in actual projects. Now Redis has three types of treasures for storage.

For Class C treasures, when users cancel or add a reservation, they cannot simply call hSet and hDel to overwrite and delete the reservation. to retrieve the reservation, bitwise operation with the scheduled time of picking up the goods.

5. Storage Optimization

In theory, inventory is a multi-dimensional array. What we do is how to store all dimensions properly and conveniently add, delete, and query dimensions. From the perspective of saving memory usage, Redis can be empty when no one has made A reservation at the beginning. for Class A treasures, if the hash value is false, the corresponding redis key or hash key does not exist at all.

In addition, the combined use of the treasure type and room number for redis keys will lead to a large number of keys related to the treasure inventory in redis. In order to facilitate unified management of these keys, you can add another redis cache to store all redis key values related to the inventory, as shown in. Note that the hash data type is not required this time, and the set type is sufficient. The complexity of addition, deletion, modification, and query is O (1 ). It stores the inventory key values of all redis instances.

One advantage of this is that, in some special cases one day, if we need to clear all the inventory-related caches, we can easily retrieve all the inventory keys and delete them. Another benefit is that it provides us with the idea of continuing to expand ...... Imagine that the most complex situation today is Class C treasures, with a total of five dimensions. Assume that in the future, you will no longer use the 300 rooms in a building to sell treasures, but multiple buildings. Then, when placing an order, you need to add another dimension-building number. In this case, we can degrade the inventory Key set to the building number to ensure scalability in more complex situations.

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

Vi. Summary

The previous step-by-step method described the problem, but in actual scenarios, these three types of treasures exist simultaneously in our business. The above design maintains the consistency of three types of treasures. If you only consider Class A treasures, the inventory has only three dimensions. In fact, you do not need to use the hash data type for storage. The set type is sufficient.

The main purpose of storing these reservations is to quickly find inventory conflicts. For example, if someone has set the Class A treasures of room 59 on April 9, December 3, another person wants to book the Class A treasures of the room on the same date and in the same period, and queries the inventory in the memory, we can easily tell the customer that the stock has been preemptible by others.

The above is a small cache design problem that I encountered in my business. Don't worry!

You may also like the following articles about Redis. For details, refer:

Install and test Redis in Ubuntu 14.04
Redis master-slave replication basic configuration https://www.bkjia.com/Linux/2015-03/115610.htm
Redis cluster construction and simple use of https://www.bkjia.com/Linux/2017-03/142210.htm
Installation and configuration https://www.bkjia.com/Linux/2017-02/140363.htm of Redis under CentOS 7
Ubuntu 14.04 install Redis with simple configuration https://www.bkjia.com/Linux/2017-01/139075.htm
Installing PHP7.0 Redis extension https://www.bkjia.com/Linux/2016-09/135631.htm in Ubuntu 16.04
Redis standalone & cluster offline installation and deployment https://www.bkjia.com/Linux/2017-03/141403.htm
CentOS 7.0 install Redis 3.2.1 detailed process and use FAQ https://www.bkjia.com/Linux/2016-09/135071.htm
Installing PHP7.0 Redis extension https://www.bkjia.com/Linux/2016-09/135631.htm in Ubuntu 16.04
Ubuntu 15.10 Redis cluster deployment documentation https://www.bkjia.com/Linux/2016-06/132340.htm
Redis practice PDF https://www.bkjia.com/Linux/2016-04/129932.htm
Redis hot migration practical summary https://www.bkjia.com/Linux/2017-02/141083.htm
Redis3.0 configuration file detailed description https://www.bkjia.com/Linux/2017-03/141369.htm

This article permanently updates link: https://www.bkjia.com/Linux/2018-03/151123.htm