当前位置：网站首页>Redis usage scenario sharing (project practice)

Redis usage scenario sharing (project practice)

2022-06-22 21:34:00 【Chen Xi should work hard】

【 Chen Xi has to work hard 】：hello Hello, I'm Chen Xi , I'm glad you came to read , Nickname is the hope that you can constantly improve , Moving forward to good programmers ！

The blog comes from the project and the summary of the problems encountered in programming , Occasionally there are books to share , I'll keep updating Java front end 、 backstage 、 database 、 Project cases and other related knowledge points summary , Thank you for your reading and attention , I hope my blog can help more people , Share and gain new knowledge , Make progress together !

We quarryers , The heart of a cathedral , May we go in our own love …

One 、 Application scenarios

Redis The use of is to ease the high and send MySQL The pressure ！
Insert picture description here

quote Redis after , The first query MySQL, Store data synchronization in Redis in , Subsequent queries can directly query the cache
Insert picture description here

I share my B Application scenarios in end products ！

For example, a merchant inquires about the sales volume of its own store , sales volumes , Customer unit price , Gross profit margin and other data ！

Base date data ： Like today 2022-06-10 So the benchmark time is 2022-06-09（ The day before ）
Underlying data logic ： The underlying data is not simply queried , For example, sales volume involves function calculation , Gross profit margin is calculated in the business code

Insert picture description here

After querying the corresponding data, store it in Redis in , Follow up directly from Redis Take it

About Redis and MySQL Analysis of data consistency in this scenario

Real business scenarios ： Before today's Day , For example, before eight o'clock , The sales data of the previous day will be synchronized to our database table , And it won't change ！ At the same time, the deadline for sales data that can be queried today is the previous day （ Financial day ）. So no matter how many times MySQL and Redis The data are the same ！（ because MySQL Business data will not change ）; Introduce... Here Redis The interface speed is greatly optimized ！

Two 、 Application effect

Original logic ： service layer Encapsulation method 1,2,3 return result Cache database not used
Present logic ： service layer Check cache , There are direct returns in the cache （ Only the first time you need to query MySQL） Use the cache database
Insert picture description here

Graphic, ： introduce Redis After caching, it is obvious that the execution logic of the corresponding interface is shortened , And greatly shorten
Insert picture description here

Real business sharing

What we're doing right now B End business , A one-time query may involve more than a dozen fields , Add the year-on-year and month on month calculations , The access request of an interface may be about 2-3S; If the cache database is used, it can be directly optimized to 0.1-0.2S;

B End products +C End products

What we're doing right now B The end product mainly means that the merchant can see the sales data , Focus on querying specific data , Businesses are more concerned about whether the data queried is correct , Therefore, there are many query fields in business , Interface access is slow , At present, the average number of first-time queries is 2-3S, But such a scenario is understandable for businesses ！

B End products , Also called To B（To Business） product , That is, enterprise level products for enterprises or specific user groups ;
C End products , Also called To C（To Customer） product , That is, products for ordinary consumers .
B Focus on function ,C Focus on experience .