With the enrichment of JD shopping cart application scenarios and the diversification of shopping channels, the product capacity of JD shopping cart has been gradually increasing since 2015.
- In 2015, the Jingdong shopping cart expanded from 80 items to 120 items;
- Expand from 120 to 150 in 2018;
- Expand from 150 to 180 in 2020;
- In 2021, the number of JD PLUS members will be expanded to 220.
Continuous expansion has brought huge load pressure to our back-end services, because the increase in the number of items in the user's shopping cart corresponds to a linear increase in back-end computing resources. How to save resources to the maximum and ensure The business and user experience will not be affected. How to comprehensively consider the technical and business aspects to provide the underlying support for the gradually expanding shopping cart demands has always been a pain point and challenge in front of us.
First describe the characteristics of the Jingdong shopping cart :
After the user finishes operating the items in the shopping cart, the current operating status of the user will be recorded, such as checking, unchecking, switching promotional product promotion information, etc. When the user enters the shopping cart again, all the items in the shopping cart will be fully obtained , calculate the price of the product in real time according to the check status of the product, promotion, etc., and display it to the user. Every time the shopping cart is refreshed or modified, the full amount of data is sent. Continuous expansion will inevitably continue to increase the pressure on back-end services. At the same time, operations such as layout calculation and rendering of the shopping cart page not only make users wait longer for the page to refresh, but also occupy a large amount of memory resources, causing mobile phones to freeze.
In order to improve the user experience, JD.com’s shopping cart retains the calculation logic of a series of car dimensions such as the total amount of products to be checked, preferential promotions, and shipping costs. As a result, it is currently impossible to realize the pagination of the main products in the shopping cart in one step. During the period, we also did a full research on the mainstream e-commerce apps in the industry. Most of the apps did not do shopping cart paging and the upper limit of the shopping cart capacity was mostly controlled below 120. The apps that did paging were also checked and reserved. Some simplifications and downgrades have been made in the calculation of global discounts, so we decided to explore and make breakthroughs from another direction, that is, the sub-information paging of products, and temporarily avoid the main data paging that will affect the calculation of global discounts, business gameplay, and traffic conversion. .
What is the basic information and subsidiary information of commodities?
The division of commodity basic information and commodity auxiliary information is mainly distinguished from the upstream interface level. Commodity basic information is the commodity information directly obtained from the shopping cart platform, such as commodity pictures, commodity names, commodity prices, commodity types, etc.; based on basic information, Ancillary information of commodities obtained in batches through the asynchronous parallel framework, such as coupons, estimated hands-on prices, commodity inventory, event tags, services, flash sales, and so on.
Figure 1 Example of product information
02 target
Understand, first of all, MCube will judge whether it needs to obtain the latest template from the network according to the status of the template cache. After the template is obtained, the template will be loaded. During the loading phase, the product will be converted into a view tree structure. After the conversion is completed, the expression engine will be used to parse the expression and Obtain the correct value, parse the user-defined event through the event parsing engine and complete the binding of the event, complete the parsing assignment and event binding to render the view, and finally display the target page on the screen
-
Improve user experience, solve product experience problems caused by the upstream service interface’s inability to support concurrent access to a large number of items in the shopping cart, and ensure that users do not perceive page-by-page loading of item auxiliary information during the sliding process of the shopping cart without compromising user experience;
-
Reduce machine costs, reduce unnecessary upstream interface requests, and reduce back-end server load;
03Technical solution
Understand, first of all, MCube will judge whether it needs to obtain the latest template from the network according to the status of the template cache. After the template is obtained, the template will be loaded. During the loading phase, the product will be converted into a view tree structure. After the conversion is completed, the expression engine will be used to parse the expression and Get the correct value, parse the user-defined event through the event parsing engine and complete the binding of the event, complete the parsing assignment and event binding to render the view, and finally display the target page to the screen. Starting from the design draft, to improve the efficiency of page construction, the core issues that need to be solved urgently are:
1) Value analysis of product subsidiary information page loading
According to the data analysis results of different dimensions of the online shopping cart, the number of requests for products in the Jingdong shopping cart in the range of 20-220 accounts for more than half of the total number of requests, and the average number of products displayed on one screen does not exceed 3. The average exposure depth of product browsing is 6 to 7, and it is analyzed that most of the upstream interface calls save a lot of space. Through the analysis and estimation of front-end online simulated paging buried points, the way of paging call of commodity auxiliary information can reduce the upstream asynchronous interface calls by 30+%, so as to reduce the peak value of interface calls and reduce the performance pressure of the interface without compromising the user experience. and machine resource consumption.
2) Product subsidiary information page loading
The difference in interface interaction before and after product subsidiary information paging is clearly marked in the figure below, which is mainly reflected in two aspects: page refresh and page sliding.
Figure 2 Asynchronous request paging scheme
Product subsidiary information loading scheme without paging: The client triggers a refresh operation and needs to obtain all product information from each upstream interface, assemble and integrate it and send it to the client for display at one time. No interface request is involved in the page sliding process. There are three main ways to call the upstream interface:
- One-time acquisition of ancillary information for all products: that is, the client calls the upstream interface only once after obtaining the basic information of the product, and the upstream interface returns a certain auxiliary information of all products at one time. In this way, the frequency of interface calls is low and avoids the experience problem of missing accessory information of some products. However, as the number of products in the shopping cart increases, performance challenges such as the response time of the interface become greater.
- One-time access to some auxiliary information of some products: that is, the client only calls the upstream interface once after obtaining the basic information of the products, but only obtains the auxiliary information of the first few products, and the auxiliary information of other products will be missing. This method reduces the calling frequency of the upstream interface, but sacrifices part of the user experience (usually because the upstream interface does not support frequent calls and the single calculation logic is complicated);
- Obtain ancillary information of all products in batches: that is, the client calls the upstream interface in batches after obtaining the basic information of the products, so as to obtain a certain auxiliary information of all products. This method avoids the experience problem of lack of auxiliary information of some products, but the high-frequency calls of the upstream interface bring great challenges to the upstream. As the number of products in the shopping cart increases, the consumption of machine resources will also increase. .
Advantages: For the client, the interaction is simple, you only need to care about data refresh/change operations (such as pulling to refresh the shopping cart, checking and deselecting, etc.), and after obtaining all the product information in the shopping cart at one time, refresh the page as a whole, without analyzing user sliding behavior , does not need to process the assembly and integration of commodity data, and the logic is simple and lightweight.
Disadvantages: Every time the client triggers a data refresh/change operation, in addition to obtaining the basic information of all the products in the shopping cart from the backend, it also needs to request the auxiliary information of all the products in batches through the asynchronous and concurrent framework, which directly doubles the overall traffic of the shopping cart. Increase machine resource cost.
Product subsidiary information paging loading scheme: After the client obtains the basic information of the product from the backend, it divides the product into pages, and then synchronously requests the product subsidiary information from the first page to the screen to browse the current page, assembles and integrates it and sends it to the client for display ; The product subsidiary information of other page numbers is preloaded by the client page by page during the list sliding process, and the returned product subsidiary information of the page is assembled and integrated with the product basic information and displayed. The following figure clearly illustrates the overall interaction process of the shopping cart client and each upstream interface in the product subsidiary information paging loading solution. The overall detailed steps are as follows:
- When calling the query interface, the pageSize of the page number where the main product is located is passed to the server, and the server sends the auxiliary information of the main product of the page where the pageSize is located, and the client renders
- Encapsulate all the auxiliary information of the product into an independent interface
- Stamp on the main product to mark the request timing of preloading. The stamp mark here is the pre-loading mark obtained based on the buried point data and user tracking, which can not only ensure that the independent auxiliary information interface will not have a large amount of invalid loading, but also ensure that the data of the auxiliary information interface is updated to the page in time , to ensure that the user experience
Advantages: The pagination loading scheme of product subsidiary information subdivides the user's refresh/change operation and sliding operation into behavioral differences. By post-posting the auxiliary information of each page of products to the sliding process, it greatly relieves the traffic performance pressure caused by the centralized batch call of the upstream interface in a single refresh/change operation, and plays the role of daily traffic peak shaving, while saving The asynchronous interface call (30+%) of the auxiliary information of unbrowsed products is eliminated, which saves the cost of machine resources corresponding to the traffic.
Disadvantages: For the client, the interaction is complicated, not only need to pay attention to the refresh/change of the shopping cart products, but also need to pay attention to whether the auxiliary information of the previous page/next page/current page is complete during the sliding process, for products with missing auxiliary information Timely preloading and assembly and integration of shopping cart master data.
Figure 3 Pagination loading scheme of product subsidiary information
04Technical difficulties and solutions
Understand, first of all, MCube will judge whether it needs to obtain the latest template from the network according to the status of the template cache. After the template is obtained, the template will be loaded. During the loading phase, the product will be converted into a view tree structure. After the conversion is completed, the expression engine will be used to parse the expression and Get the correct value, parse the user-defined event through the event parsing engine and complete the binding of the event, complete the parsing assignment and event binding to render the view, and finally display the target page to the screen.
1) The dynamics of the shopping cart and the multi-dimensional heap rules are moved up
Currently, the backend of the shopping cart sorts, stacks, and displays master data in different dimensions. Among them, the back-end service first performs store grouping, promotion grouping, and time sorting on the main data of the shopping cart, and the client performs business refinement screening, grouping, and sorting on the main data of the shopping cart (involving 30-day car addition, price reduction, regular 10+ business scenarios such as shopping, cross-store full discount, classification, etc.). The client needs to perform unified closing processing on product screening, stacking, and sorting logic, and then paginate the main data of the shopping cart on this basis.
2 ) Paging strategy selection
Commodity pagination: Pagination is performed from the commodity dimension, and n commodities are one page. Due to the complex hierarchical structure of the shopping cart (store-promotion-set/set-commodity), pagination from the product dimension will result in the splitting of stores, promotions, and sets, which will affect the integrity of the business logic of stores, promotions, and sets in the shopping cart , cannot satisfy the complex hierarchical structure and business scenarios of the shopping cart.
Store pagination: paginate from the store dimension, n stores are one page. Due to the large difference in the number of products under a single store, paging from the store dimension will lead to a large difference in the number of products on each page, while the upstream asynchronous interface is called in batches from the product dimension, and the main data page and the upstream asynchronous interface are divided Inconsistencies in the batch caliber will greatly reduce the effect of reducing upstream interface calls through paging.
Commodity + store pagination: Pagination is performed from the dimension of the product, n products are one page, but the store is not split, and the products of the same store are classified into the same page. This paging strategy perfectly solves the problems caused by the above two paging methods. It can not only avoid the impact on the store, promotion, and package dimension auxiliary information business scenarios due to the split of stores, promotions, and packages, but also flexibly adjust the page size and The caliber of upstream interface batch calls is agreed, and then combined with user browsing behavior, the value of reducing upstream interface calls through paging is maximized.
3 ) Analysis of preloading scheme
Pagination in the traditional sense is usually to paginate the main data, there is no incomplete data, and only the next page of data needs to be loaded during the sliding process. The pagination here is to load the auxiliary information in paging when the main data is complete. It may happen that the main data display is incomplete during the list sliding process. etc.) may result in incomplete commodity information on the current page or the previous pages, so it is necessary to consider the interactive scenarios of preloading the previous page, the next page, and the current page at the same time.
If you don’t consider the preloading solution, slide to the current page and then load the product’s auxiliary information on the current page, after the paging asynchronous interface returns, there will be an operation of reorganizing the information and re-refreshing the page, resulting in page flickering and affecting the user experience.
However, if the timing of preloading is too advanced, although most of the page flickering problems will be solved, it will request more asynchronous interfaces of the previous page/next page to a certain extent, reducing the value of reducing upstream interface calls through paging loading.
In order to solve the above two problems, a preloading timing configuration scheme is designed here. The server distributes the preloading timing configuration of the previous page/next page, and flexibly configures and optimizes online to achieve the best balance between user experience and reducing upstream asynchronous interface calls, thereby maximizing the value of paging.
4) Efficient call of paging interface
When a user swipes on a page, there are many situations. When the user slides quickly, in fact, he doesn't care about the content during the sliding process, but only cares about the content at the end of the scrolling, so the content that the user does not care about can not be loaded; when the user slides slowly, there is no need to advance the content too early Preloading. For different sliding scenarios, how can we reasonably call the paging auxiliary information interface under the premise of ensuring user experience?
First, we selectively load the paged auxiliary information interface according to the user's sliding speed, and do not request and render the interface when the user slides too fast. Second, choose a smaller preload threshold when the user swipes slowly.
5) Dirty data processing of the paging interface
Imagine that during the asynchronous loading of the paging interface, the basic data on the page has changed, and all operations at this time are futile. This kind of situation will not only seriously affect the performance, but also lead to errors in the data displayed on the page. How to deal with dirty data?
When it comes to dirty data processing on the client side, many people may think of locks and semaphores. However, locks and semaphores are not suitable for this scenario. Here we will introduce a more lightweight implementation. First, record a time stamp after the current main data request, obtain the time stamp of the main data before each asynchronous interface request, and compare the time stamp before the interface request with the time stamp of the main data after the interface returns, if inconsistent , then the data this time is dirty data, and it is discarded to prevent dirty data problems.
05 income
Understand, first of all, MCube will judge whether it needs to obtain the latest template from the network according to the status of the template cache. After the template is obtained, the template will be loaded. During the loading phase, the product will be converted into a view tree structure. After the conversion is completed, the expression engine will be used to parse the expression and Get the correct value, parse the user-defined event through the event parsing engine and complete the binding of the event, complete the parsing assignment and event binding to render the view, and finally display the target page to the screen.
Figure 4 Pagination revenue measurement scheme
The overall asynchronous paging solution for the auxiliary information of the shopping cart has been put into operation, and the impact and benefits after the implementation of the solution have also been measured in multiple dimensions. The overall solution has also met our expectations for the solution, and it has been completed without user experience. Full-link traffic savings and more flexible support for business development; after the paging transformation, compared with the single interface before the transformation, about 30% of the calls are saved. According to the calculation of the big promotion scenario, which is dozens of times the peak traffic of the daily scenario, the traffic in the large The saving of resource costs at the time of promotion is much greater than the daily benefits, and the implementation of asynchronous paging exploration on the end also provides a set of reusable and low-cost support solutions for the subsequent gradually superimposed subsidiary businesses, so that there is no need to re-use Abandoning or downgrading the shopping cart because of its large capacity consumes resources, and it can also drive some logic that does not require pre-calculation to be separated from the heavy logic of historical full-cart calculations into asynchronous paging, so as to achieve the fine-grained calculation effect of how much to render and how much to calculate. Minimize the resource occupation of the shopping cart in the transaction link, so that the Jingdong shopping cart can operate more carbon-free.
Can the Jingdong shopping cart complete pagination from the source of the master data? Can it be smoothly supported when the business has a larger demand for the shopping cart? Is it possible to avoid increasing resource costs due to capacity expansion on the overall link? In the future, we will do more experiments and measurements from the perspectives of business transformation, user experience, and resource costs, and fully combine technology with business to explore the optimal solution for cost, business support, and user experience.
Authors: Jingdong Retail Gold, Xu Xiaoqing, Huang Jingjing
Source: JD Cloud Developer Community