<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • 請求一下子太多了,數據庫危

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

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

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

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

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

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

    1. 什么是請求合并

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

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

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

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

    2. 業務背景

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

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

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

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

    3. 優化實現

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

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

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

    存數據的話,是不是就可以用數據庫、緩存、隊列了。如下圖:

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

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

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

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

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

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

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

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

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

    4. 適用場景

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

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

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

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

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

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

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

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

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

    posted @ 2022-06-27 13:31  七淅在學Java  閱讀(1881)  評論(12編輯  收藏  舉報
    国产美女a做受大片观看