Vivo global mall: design and practice of commodity system architecture

One 、 Preface

With the rapid growth of user level ,vivo Official Mall v1.0 The disadvantages of the single structure of the network are gradually exposed ： The modules are becoming more and more bloated 、 Inefficient development 、 Performance bottlenecks 、 System maintenance is difficult .

from 2017 It started in v2.0 Architecture upgrade , Vertical system physical split based on business module , Separate out the business lines and perform their respective duties , The ability to provide services , Support the main station business together .

The commodity module is the core of the whole link , The increase of modules seriously affects the performance of the system , Service oriented reform is inevitable .

This article will introduce vivo Problems and solutions encountered in the construction of mall commodity system , Share architecture design experience .

Two 、 Commodity system evolution

Split the commodity module from the mall , Independent for commodity system , Gradually develop to the bottom , For the mall , Search for , members 、 Provide basic standardized services such as marketing .

The commodity system architecture is as follows ：

The commodity system in the early stage is messy , There are many business modules , Such as commodity activity business 、 Second kill business , Inventory management , With the continuous development of business , The commodity system carries more business, which is not conducive to system expansion and maintenance .

Therefore, we should gradually sink the commodity business and take it as the bottom layer 、 The most basic business system , And provide high-performance services for many callers , The following describes the upgrade history of the commodity system .

2.1 Commodity activities 、 Gift stripping

With the increasing commodity activities , There are many ways to play , At the same time, the additional attributes related to the activity are also increased , These are not strongly related to commodity information , More inclined to user Marketing , It should not be coupled with the core commodity business , Therefore, it is incorporated into the mall promotion system .

Gifts are not just mobile phones 、 parts , It could be an integral 、 Members, etc , These are not suitable for the commodity system , Nor does it belong to the content of the commodity module , Therefore, it will be merged into the mall promotion system at the same time .

2.2  Second kill independence

as everyone knows , The second kill is characterized by ：

• Time limit ： The time frame is very short , It ends after the set time
• limited ： The quantity of goods is very small , Well below actual inventory
• Large amount of visits ： The price is low , It can attract a lot of users

Based on the above characteristics , Doing a second kill is not done overnight , Due to system resource sharing , When the sudden large traffic impact will cause the denial of service of other businesses in the commodity system , The risk of blocking the core transaction link , Therefore, it is an independent second kill system , Providing services to the outside world alone .

2.3  The consignment system was established

The main sales category of our mall is mobile phones and mobile phone accessories , There are few categories of goods , In order to solve the problem of not rich categories of non mobile phone products , The operator considers cooperation with well-known e-commerce , Expect to introduce more commodity categories .

To facilitate subsequent extensions , And non-invasive to the original system , After consideration, we separate a subsystem , Used to undertake consignment business , Finally, it is expected to make a complete platform , Follow up by providing open API Let other e-commerce actively access our business .

2.4  Inventory stripping

The pain point of inventory management ：

• Because our inventory is to the commodity dimension , Only one field identifies the quantity , Every time you edit an item, you need to adjust the inventory for the item , Inventory management cannot be realized dynamically ;
• At the same time, the marketing system also has its own activity inventory management mechanism , Inlet dispersion , Weak correlation ;
• Both saleable inventory and active inventory management are based on actual inventory , It is easy to cause configuration errors .

Based on the above pain points , At the same time, in order to facilitate the operation and management of inventory , It also lays a foundation for future sales using actual inventory , We set up an inventory center , It also provides the following main functions ：

• And ecms Real time synchronization of physical inventory ;
• According to the warehouse distribution of the actual inventory , Calculate the estimated delivery warehouse and delivery time of goods , So as to calculate the expected delivery time of goods ;
• Complete low inventory warning , Can be based on available inventory 、 Average monthly sales, etc , Dynamically remind operators to order .

3、 ... and 、 Challenge

As the lowest system , The main challenge is stability , High performance , The ability of data consistency .

3.1  stability

• Avoid stand-alone bottlenecks ： Select the appropriate number of nodes according to the pressure measurement , Don't waste , It also ensures communication , Can deal with sudden traffic .
• Business current limit downgrade ： Limit the current of the core interface , Priority is given to ensuring that the system is available , When the traffic pressure on the system is too high, the non core business will be degraded , Give priority to core business .
• Set a reasonable timeout ： Yes Redis、 Set reasonable timeout for database access , Not too long , Avoid causing the application thread to be full when the traffic is large .
• monitor & The alarm ： Log normalization , At the same time, it is connected to the company's log monitoring and alarm platform , Take the initiative to find problems and solve them in time .
• Fuse ： External interface access fuse , Prevent the system from being affected due to abnormal external interface .

3.2 High performance

Multi level cache

In order to improve the query speed , Reduce the pressure on the database , We use multi-level cache , Interface access hotspot cache component , Dynamic detection of hot spot data , If it is a hotspot, get it directly from the local , If it's not a hot spot, go directly from redis obtain .

Read / write separation

The database adopts read-write separation architecture , Update the master database , The slave library is responsible for query operations .

Interface current limiting

Access the current limiting component , The interface directly operating the database will limit the current , Prevent sudden traffic 、 Or nonstandard calls increase the pressure on the database , Affect other interfaces .

But I stepped on some pits in the early days ：

1、 Product list query redis key Too much , Lead to redis Risk of insufficient memory

Because it is a list query , The input parameters are cached hash, Get the only key, Due to the large number of participating Commodities , In some scenarios, input parameters change at any time , According to the arrangement , Basically, every request will go back to the source , Cache again , It may cause database denial of service or redis out of memory .

Scheme 1 ： Loop into the parameter list , Each time from redis get data , Then return ;

This solution solves key Excessive memory overflow problems , But obviously , It adds a lot of network interaction , If there are dozens key, As one can imagine , It will have a significant impact on performance , So what other way to reduce network interaction , Now let's look at scheme 2 .

Option two ： We pass on the original Redis Components are enhanced , because Redis Cluster mode does not support mget, So we use pipeline The way to achieve , First, according to key Calculate where it is slot, Then aggregate one-time submissions , In this way, each product data only needs to be cached once , Simultaneous adoption mget It also greatly improves the query speed .

This is the solution key Problems with too many values , It also solves the problem of multiple network interactions in solution 1 , After pressure measurement and comparison , The performance of scheme 2 is better than that of scheme 1 50% above ,key The more , The more obvious the effect .

2、 Hot data , Lead to redis Single machine bottleneck

The mall often has new product launches , After the press conference, it will directly jump to the new product supplier details page , At this time, the new product dealer's detailed page will have a particularly large and sudden flow 、 Single data , This leads to Redis Node load imbalance , There are some 10% Less than , Some reach 90% many , Some conventional capacity expansion is ineffective .

For hot issues, we have the following solutions ：

• key Hash of , take key Spread to different nodes
• Use local cache

At first, we adopted open source based Caffeine Complete local cache component , Automatically calculate the request volume locally , When a certain threshold is reached, the data is cached , Cache different times according to different business scenarios , Generally not more than 15 second , It mainly solves the problem of hot data .

Later, it was replaced by our own hotspot cache component , Support hot spot dynamic detection , Hot spot report , Cluster broadcasting and other functions .

3.3 Data consistency

1、 about Redis The data consistency of is easy to solve , use “Cache Aside Pattern”：

For read requests, read first cache , Hit direct return , Missed read database re cache . For write requests, first operate the database , Delete the cache .

2、 Due to the stripping of inventory , Maintain the entrance or in the commodity system , This leads to cross library operations , Ordinary single database transactions cannot be solved .

Let's start with exception capture , How local transactions are rolled back , The operation is a little troublesome , But it can also solve this problem .

Later, we adopted open source seata Complete the distributed transaction component , Introduce the company's basic components by rewriting the code , At present, it has been connected to .

Four 、 summary

This article mainly introduces how to split the commodity system of the mall 、 And slowly sink as the most basic system , Make their responsibilities more single , Able to provide high-performance goods and services , And share the technical problems and solutions encountered in this process , The evolution history of inventory system will follow 、 Distributed transaction related content , Coming soon .

author ：vivo Official website mall development team -Ju Changjiang