請求一下子太多了,資料庫危

七淅在學Java 發表於 2022-06-27
資料庫

大家好,我是七淅(xī)。

如標題所說,和大家分享一個我曾優化過的業務場景。

當然,具體業務細節不重要,重要的是優化的思路。如果大家以後有遇到類似特點的場景,能夠想到七淅這篇優化文章,那我就覺得很值了。

接下來我就直接進入主題,要分享得優化思路就是請求合併

弱弱說一句,由於優化效果特別明顯,這一優化我直接寫到簡歷上了。

之前面試有不少面試官都會來問我是怎麼做的,你看這不就給我機會發揮了嗎?所以大家懂的,有合適場景記得用起來,以後面試也和麵試官談笑風生。

1. 什麼是請求合併

首先說明一下,這並不是什麼高階的優化方式,不難,樸實無華,但有用。

如字面意思,就是(把多個)請求合併(成一個請求去處理)。

現在含義你知道了,現在我們看下文章標題:「請求一下子太多了,資料庫危」

聰明的你是不是已經猜到七淅要怎麼優化了?

2. 業務背景

我有一個推送業務,會把每次推送記錄都存到 MongoDB 中。

PS:不用在意是 MongoDB 哈,可能有的讀者可能沒接觸過,沒關係。反正它也是一個資料庫,就算換成 MySQL,優化一樣適用哈

而推送業務一個非常常見的場景就是定時傳送訊息給使用者,所以到點之後對應的每秒寫請求就特別高。

當初我這邊是有 8000 的每秒寫入量,後面通過請求合併優化到每秒寫 500。

3. 優化實現

現在問題來了,具體怎麼實現的呢?

理清有 3 個小點就好了,我們順著思路理一下:

1、首先,既然我們需要把多個請求合成一個,是不是需要有一個地方把這多個請求給存起來?

存資料的話,是不是就可以用資料庫、快取、佇列了。如下圖:

請求一下子太多了,資料庫危

好了,現在資料存起來了,不可能一直存著吧,一直存著不處理,豈不是就是不處理請求了,那這肯定不對。

2、所以我們是不是就需要知道,什麼時候要處理存起來的資料?

「什麼時候」—— 用定時任務每隔多久取出來處理是不是就可以,或者當存夠多少資料量的時候,我們就集中處理。

我這裡的業務是用的定時任務來做的,那關於定時任務的實現也有多種方式。

我這裡是用的定時執行緒池,每隔 xx 秒,取 500 個請求進行處理。這裡你發現沒有,優化後的效果就是每秒寫 500,這個 500 就是這裡每次取得請求量來的。

所以說,優化效果要多少的處理量都是我們自己決定的。當然了,因為請求總量是不變得,所以每秒處理量越少,對應處理時間就越長。具體是什麼數字,這個就看具體業務啦

3、最後一點,多個請求存起來了,也知道什麼時機去處理,那這個「處理」是怎麼處理呢?

答案很簡單,把多個單次操作換成批量操作。比如資料庫批量插入,redis 的 mset。

以上 3 點,給大家整理個流程圖:

請求一下子太多了,資料庫危

4. 適用場景

最後,上面得優化姿勢學廢后,那什麼業務場景可以用呢?

其實這個你想想,請求合併後的效果是怎樣的,差不多也就知道了。

一開始說含義:(把多個)請求合併(成一個請求去處理)

這樣的效果說明業務允許請求可以不用馬上處理,高階用語就是資料實時性要求不高 —— 這是第一個業務場景特點

第二個特點:「請求合併」,業務得有一定的併發場景才有機會給你合併呀。不然你說每分鐘才幾個請求,那這不是合了個寂寞嗎?(狗頭)

5. 文末休息區(求關注)

其實很多優化方式都是樸實無華的,第一次聽說時候可能會覺得牛蛙牛蛙,但實際接觸瞭解後,會發現其實也沒多高階。

不過,高階的優化方式肯定也是有的。就像我也很好奇,阿里京東這種億級秒殺,微博的粉絲關係,抖音的推薦等等是怎麼實現的。
倘若哪天真的有實際參與的大佬和我說,無非就是堆機器,沒什麼特別的,那我真的會尬住,哈哈哈哈。

如果覺得文章不錯,歡迎關注我的公眾號:七淅在學Java

請求一下子太多了,資料庫危

相關文章