線上項目優(yōu)化記錄

業(yè)務(wù)場景:

最近幾個月都在做項目接口優(yōu)化，壓測等工作。
目前項目緩存主要用的redis和spring的cache以及Ibatis的cache美旧。但絕大部分還是用的redis.
基本步驟:先去緩存查,有就直接返回,沒有就去查數(shù)據(jù)庫,然后加失效時間,存緩存,然后返回,但是這中間有個問題,像那種業(yè)務(wù)邏輯比較多的，雖說緩存的那幾秒速度快了，TPS上不去,緩存的失效時間到了,還是會把壓力透傳到db上化借。之前用戶量少,隨隨便便就可以撐住,隨著用戶增長,手機小屏用戶變多,機頂盒用戶變多,現(xiàn)在用戶在700萬＋,而且為了做推廣,做了開戶抽獎活動,并發(fā),性能問題越來越嚴重。

起初優(yōu)化

起初想到的就是優(yōu)化代碼及業(yè)務(wù)邏輯,我們?nèi)齻€人,便開始擼代碼之旅

代碼包括

使用多線程,線程池去做處理
梳理邏輯去掉冗余代碼
使用jmap,jstack去查看耗時的堆棧信息
JProfiler 優(yōu)化接口
Jmeter壓測接口
其他

其中db包括

加索引
改sql查詢邏輯
分庫用的mycat
分表用的簡單的%32,算hash
盡量不在for內(nèi)查詢
小米的soar(http://www.reibang.com/p/2c3bd3a7714e)
其他

等這些都做完,出包放到線上,效果還是不好,并不能滿足領(lǐng)導(dǎo)性能的要求及想要的TPS

繼續(xù)優(yōu)化

然后又是開會討論討論研究研究...,最后定了做一個CacheManager(緩存系統(tǒng)),最終達到領(lǐng)導(dǎo)想要的TPS及指標(biāo)蓖康。
這里簡單說一下cm一條線路,還有幾條線路就不說了,Metadata和API通過MQ做消息傳輸,消息隊列之前用的ActiveMQ,然后改為RabbitMQ,好處網(wǎng)上有一堆,在Metadata側(cè)發(fā)數(shù)據(jù)給API側(cè)時,將數(shù)據(jù)同時傳到cm側(cè)做處理,主要是緩存.以此來減少接口對數(shù)據(jù)庫的壓力铐炫。

此方案的缺點

覺得MongDB,屬于雞肋
理由,redis已經(jīng)有持久化了,如果只做展示,運維,加入mongo在這個場景下,會占用很多的空間,各有利弊吧

數(shù)據(jù)一致性的問題
因為以后基本不過db,直接去緩存取,雖然redis有持久化,但是我們還是引進了MongDB,存redis時順帶存mongo,使用vue寫了個簡單頁面,然后cm提供一組供運維頁面使用的接口,在頁面做簡單請求實現(xiàn),以此來解決數(shù)據(jù)一致性的問題(其中包括查問題數(shù)據(jù)重新刷到redis)

redis相關(guān)的問題
壓力全部轉(zhuǎn)移到redis,如果redis出現(xiàn)問題,將是致命的,細的我也沒怎么看,說幾個我知道的

網(wǎng)絡(luò)延時導(dǎo)致阻塞
阻塞通過查看慢查詢?nèi)罩?找病因
redis模式的合理選擇
最主要的加機器,機器,機器,重要事說三遍

總結(jié)

此方案或許有很多漏洞,不恰當(dāng)之處請包涵,但整體效果是達到了領(lǐng)導(dǎo)的要求,中間我們就討論過數(shù)據(jù)一致性問題,為啥不用binlog去做數(shù)據(jù)恢復(fù),為啥非得加mongo,畫頁面等,我當(dāng)時提的建議是,對于數(shù)據(jù)一致性修復(fù),咱們得弄可視化讓運維去做處理,總不能每次都提供腳本吧蒜焊。

對于redis模式的選擇,推薦使用集群,理由如下

單實例
對于單實例,學(xué)習(xí)使用就行,在項目中基本不會使用此模式.單實例除小系統(tǒng)外,撐不起整個服務(wù)倒信。

主從模式
數(shù)據(jù)會通過主同步到從,但是受限于單臺機器的性能泳梆。

哨兵模式
項目之前用的哨兵模式
優(yōu)點:雖說哨兵有主寫從讀鳖悠、主從復(fù)制,故障自動轉(zhuǎn)移,通過選舉做的.。
缺點:還是受限于單臺機器性能,而且數(shù)據(jù)上去后,每臺機器都保存著全量的緩存數(shù)據(jù),如果還做持久化了(RDB,AOF),那占用的資源會更大优妙。

集群模式
項目現(xiàn)在用的模式
優(yōu)點:主從復(fù)制,高可用,通過16384個槽,均勻分配到不同的主節(jié)點,key通過crc16算槽,壓力分配到每臺機器上,支持動態(tài)加減節(jié)點,擴容及收縮,故障自動轉(zhuǎn)移等
缺點:耗機器,需要多臺機器