1、業務背景

目前，**東商家有30W+，為了盡可能的更新上架新商品，這些商家會進行頻繁頁面操作，經統計，在所有的頁面操作中，定時發布（立即發布）是深受商家喜愛的經典操作，特別是大促一結束，商家會進行高并發的發布操作，如在2020.11.12的0點，大量的商家就迫不及待的開始下架活動頁面，并更新為常規頁，這一波騷操作QPS竟高達2W，

2、面臨的問題

由于頁面發布關聯的資料庫之多，頻繁的寫庫對資料庫造成了非常大的壓力，同時，呼叫上游介面也會相關的多，在大促期間，各兄弟部門穩字當頭，一般也會對自己的介面進行自動限流，當超過一定的閾值時，就會限流甚至降級，從而導致發布失敗，當然這也不是我們所期望的，

目前，30W+的商家的頻繁操作已經讓主庫的CPU消耗疲于奔命，那接下來隨著業務的擴展，商家資料將會呈現指數級增長，200W，2000W更不在話下，那么在如此高的并發下，如何讓發布操作更加優雅，CPU利用率并不會因商家數量的增長而線性增長，滿足商家騷操作『又快又穩』，這是值得思考的一個話題，

3、解決之道

下面給出兩種已經落地的解決方案，并且都取得了一定的成效，

3.1 定時發布提交發布

定時發布，就是在指定的未來時間點進行發布，這一場景處理邏輯是比較簡單的，即讓定時任務提前執行，到點了僅僅執行輕量級的操作，

優點：操作簡單，無需考慮過多的復雜場景，如資料同步，

缺點：其實缺點也是挺明顯的，其一是資料庫的輕量級操作，雖然輕量，但達到一定的量級，對資料庫也是有傷害的，其二：當定時任務的TPS達到一定的量級，雖然是提前執行，但在執行階段，同樣會有大量的寫操作，資料庫也會有頻繁的IO操作，其三：需要額外的存盤空間，畢竟同一個商家的同一個頁面可以設定多個定時點，

3.2 立即發布優先記憶體處理

立即發布，所謂立即發布，即是秒級甚至毫秒級的范圍內看到效果，為了滿足高并發的寫操作，顯然不能直接操作mysql等資料庫，最直觀的感受就是找一個替代品（即寫的tps高一點的中件間），redis當仁不讓，

下面是redis與mysql在性能測驗，

redis的set操作

mysql的update操作

https://redis.io/topics/benchmarks

如上圖可知，redis的寫性能是mysql的10倍左右，可以說性能虐爆mysql，方案其實也挺簡單，相關的操作優先于redis操作，然后根據資料同步策略到mysql（此操作也是一個輕量級操作，基于一定的同步策略執行即可），通過最終一致性策略保證寫入成功，

優點：按照一定的同步策略，可以級訓mysql的寫壓力，避免頻繁的操作mysql庫，

缺點：缺點主要有兩個：一是增加了資料同步策略，二是當同步策略不當時，有可能也會導致對mysql頻繁的輕量級操作，

3.3 平滑執行

上面兩種解決方案，最終都需要落實到資料庫的操作，無論是多么輕量級的資料操作，當TPS超過了資料庫的更新極限，無論是操作本身還是資料庫都些許有些壓力，為了徹底解決此問題，需要對任務的執行進行平滑處理——通俗的描述：以資料庫能承載的能力執行CURD，任務的平滑執行可以借助很多中間件，如kafka的主動拉取broker資料進行消費，在些就不在累述，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/245652.html

標籤：其他

上一篇：阿里二面，原來我對自動化測驗的理解太淺了