Overview
I have dealt with a shopping cart failure before and I think it is quite classic. I will share it with you here. This failure directly leads to failures in the front-end operations such as adding shopping carts, obtaining user shopping cart lists. The shopping cart is the entrance, and once there is a problem, the impact will be extremely serious.
Temporary processing
All interfaces of the shopping cart service have printing response time, and it is found that it is much slower than usual. Since the situation is already in a hurry, I can only restart the shopping cart first, buffer it, and then use this buffering time to quickly locate the problem.
Problem positioning
Previously, the shopping cart application was based onSpring CloudThe microservices have been in operation for several months and it has been under pressure before going online, so the interface performance is fine. Why is there a problem suddenly? According to past experience, most of the failures areSQLcaused by statements, so first export all slow databaseSQL(Tencent Cloud has a tool to export slow SQL) statement, and found that most slow queries are from inventory queriesSQLSome statements are even executed in 10 seconds.
Later, after a closer look, the inventory slow query statement was that there were much more products to query the inventory than usual. If there are fewer products, this statement is still very fast, and once there are too many, it will start to slow down.
Solution
Due to the historical reasons of the inventory calculation system, thisSQLIt is difficult to optimize. The situation is urgent again, and the boss kept asking what was going on. Therefore, change the code temporarily and store the product inRedisCache. For shopping cart services, inventory data is allowed to be in real time, because subsequent settlement and payment will calculate inventory in real time, and users will be prompted when the inventory is insufficient.
Notice:
- Since the shopping cart is an entrance, the traffic is very large, and from the shopping cart to the settlement page and then to payment, there is an operation step, the traffic of the settlement page and payment page is not as large as the shopping cart;
- Some users have a lot of product data on their shopping carts, but they may not necessarily buy them. Users can also check the products they want to buy and then place an order;
- Some users do not have the habit of cleaning out invalid items in shopping carts, which leads to a lot of items on the shopping carts.
The ultimate solution
Independently place inventory services, place product inventory data into the cache, and introduce a mechanism to refresh the inventory data in the cache in real time, so that the data in the cache should be as fresh as possible. In this way, most of the inventory can be retrieved from the cache and will not penetrate into the database.
Replenish
When we conduct pressure measurement on the interface, in some scenarios, we need to consider the number of parameters. We cannot simply use a few data pressure measurements. If we think the performance is OK, we will ignore it.
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for your study or work. Thank you for your support. If you want to know more about it, please see the following links