資訊專欄INFORMATION COLUMN
摘要：引子最近負(fù)責(zé)的一個消息推送系統(tǒng)要上線了，性能方便要滿足兩個要求對外提供的接口能達(dá)到條的。計劃，優(yōu)點是使用做緩存層，再通過計劃任務(wù)從中取數(shù)據(jù)進(jìn)行批量入庫，接口只操作，性能沒問題，批量入庫大大減輕了數(shù)據(jù)庫壓力。
引子
最近負(fù)責(zé)的一個消息推送系統(tǒng)要上線了，性能方便要滿足兩個要求
1、對外提供的接口能達(dá)到5w條/s的tps。
2、查詢功能和統(tǒng)計報表在數(shù)據(jù)量大的情況下要保證速度。
項目環(huán)境：
linux+tomcat8+mysql8+redis+rocketmq
1、接口優(yōu)化
接口狀況：http接口，接收到短信數(shù)據(jù)庫后，先進(jìn)行用戶身份、用戶余額、黑名單、敏感詞等校驗，校驗完成后，插入到mysql數(shù)據(jù)庫。然后通過計劃任務(wù)從數(shù)據(jù)庫中查詢出待發(fā)送的短信數(shù)據(jù)，推送到mq,發(fā)送子系統(tǒng)負(fù)責(zé)從mq中消費短信數(shù)據(jù)發(fā)送到運營商網(wǎng)關(guān)。
壓測的時候發(fā)現(xiàn)，只能達(dá)到15條/s的tps，離5w這個目標(biāo)差十萬八千里。
問題分析：
校驗的時候都是從redis里面取的數(shù)據(jù)，問題應(yīng)該不大，那就剩下一個插入數(shù)據(jù)的操作了，剛好測試那邊也反饋了數(shù)據(jù)庫cpu占用100%，那么基本確定性能瓶頸就在插入數(shù)據(jù)庫這里。
<<優(yōu)化思路>>
當(dāng)時想到兩個解決辦法：
a、接口接收到數(shù)據(jù)后，校驗通過，直接發(fā)送mq，消息推送系統(tǒng)和發(fā)送子系統(tǒng)同時去消費，一邊入庫一邊發(fā)到運營商網(wǎng)關(guān)。
b、接口接收到數(shù)據(jù)后，校驗通過，先保存到redis中，再用一個計劃任務(wù)輪詢redis去批量入庫。
批量入庫參考：https://www.cnblogs.com/caica...
a計劃，優(yōu)點是短信數(shù)據(jù)很快的就發(fā)送到運營商網(wǎng)關(guān)，用戶能夠很快的收到。缺點就是，第一如果發(fā)送子系統(tǒng)已發(fā)送完畢，狀態(tài)報告返回時，短信數(shù)據(jù)還沒入庫，這時候就比較蛋疼了。第二數(shù)據(jù)入庫還是單條，數(shù)據(jù)庫壓力仍然很大，影響其他功能的使用。
b計劃，優(yōu)點是使用redis做緩存層，再通過計劃任務(wù)從redis中取數(shù)據(jù)進(jìn)行批量入庫，接口只操作redis，性能沒問題，批量入庫大大減輕了數(shù)據(jù)庫壓力。缺點是數(shù)據(jù)入庫到發(fā)送到運營商網(wǎng)關(guān)會有幾秒的延遲，還有就是批量入庫失敗，數(shù)據(jù)有丟失風(fēng)險。
2、查詢優(yōu)化
短信查詢功能，需要根據(jù)一些查詢條件去查詢短信的數(shù)據(jù)（分頁查詢），需要根據(jù)發(fā)送時間降序排列，還需要根據(jù)用戶權(quán)限過濾，關(guān)聯(lián)表有4張左右。600萬條數(shù)據(jù)，需要幾十秒的查詢時間，崩潰。
<<優(yōu)化思路>>
在查詢條件字段和排序字段加上索引，減少幾張關(guān)聯(lián)表（數(shù)據(jù)量很少幾十條的樣子，如果關(guān)聯(lián)進(jìn)去是用來做查詢條件，可以用exists來替代，如果是用來查詢某個字段的，可以在取到結(jié)果集后，再去多帶帶查一下這個字段），優(yōu)化后，0.004秒搞定。然后又發(fā)現(xiàn)翻頁的時候，查詢總數(shù)速度慢、還有查詢頁數(shù)越大越慢的問題。
總數(shù)慢的問題解決：count(1),count(*),count(字段)這幾種方式都試了，沒用啊，后面發(fā)現(xiàn)單表count快，多表就慢，于是只count一張表，其他表主要是做查詢條件的，使用exists的方式改寫，問題解決。
翻頁慢的問題解決：越往后面翻頁就越慢，最后一頁要80多秒，使用的limit m,n來分頁的，幸好有大神詳細(xì)分析了這個問題，博客地址：https://www.cnblogs.com/genin...
后記1、單機壓測最終能達(dá)到5000條/s的tps，離目標(biāo)5w/s的距離仍有一定距離，但是可以通過集群部署的方式來彌補。后續(xù)優(yōu)化方向，增加nginx配置長連接、使用undertow服務(wù)器替換tomcat服務(wù)器，使用netty重新開發(fā)短信發(fā)送接口等。
2、查詢慢的問題基本解決，后續(xù)再根據(jù)實際情況看是否需要繼續(xù)優(yōu)化，優(yōu)化方向：表分區(qū)、分庫分表。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/76945.html
摘要：由于不是線程安全的，故在方法上增加了同步操作，造成競爭等待。至此，整個多線程調(diào)優(yōu)結(jié)束，通過充分優(yōu)化同步競爭的方式，最終使得分線程記錄日志的性能比最原始的多線程寫同一文件提高了倍去鎖提高到倍，替換提高倍 背景 ??在一次項目的性能調(diào)優(yōu)中，發(fā)現(xiàn)出現(xiàn)競爭瓶頸，導(dǎo)致在資源未使用滿的情況下，TPS已經(jīng)無法提升。祭起JMC（JAVA MISSON CONTROL）飛行記錄器大法后，發(fā)現(xiàn)線程集中等待...
摘要：相對于電子書，我更喜歡紙質(zhì)版的書籍。過去的年一共閱讀過本技術(shù)書，下面對這些書做一個小結(jié)。源碼深度解析這本書是年購買的，年是第四次閱讀。必知必會數(shù)據(jù)庫的復(fù)習(xí)書籍，內(nèi)容淺顯易懂。 相對于電子書，我更喜歡紙質(zhì)版的書籍。我喜歡在拿到新書時記錄購買時間、地點、開始閱讀的時間、第一次看完的時間，算是一種學(xué)習(xí)的記錄。過去的2016年一共閱讀過15本技術(shù)書，下面對這些書做一個小結(jié)。 《深入理解Java...
摘要：前言這篇文章的主題是記錄一次程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。因為我們的連接數(shù)只有，一旦請求過多，勢必會導(dǎo)致數(shù)據(jù)庫瓶頸。我們再次壓測，結(jié)果顯示萬，服務(wù)器數(shù)據(jù)庫連接正常，連接正常，響應(yīng)時間平均為，錯誤率為。 前言 這篇文章的主題是記錄一次Python程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。為大家提供一個優(yōu)化的思路，首先要聲明的一點是，我的方式...
摘要：而在新一線城市序列，個新一線城市的排名依次是成都杭州重慶武漢蘇州西安天津南京鄭州長沙沈陽青島寧波東莞和無錫。 showImg(https://segmentfault.com/img/remote/1460000018784418?w=640&h=419); IT行業(yè)的技術(shù)者，時常被我們戲稱為「IT民工」，雖然行業(yè)內(nèi)巨大的人才需求和相對容易得到的高薪在源源不斷的吸引各路人馬加入，但它依...
閱讀 1392·2021-09-22 10:02
閱讀 1922·2021-09-08 09:35
閱讀 4067·2021-08-12 13:29
閱讀 2612·2019-08-30 15:55
閱讀 2267·2019-08-30 15:53
閱讀 2307·2019-08-29 17:13
閱讀 2766·2019-08-29 16:31
閱讀 2958·2019-08-29 12:24
