本文主要根據(jù)美團(tuán)的技術(shù)博客《常見性能優(yōu)化策略的總結(jié)》整理而來。
代碼
之所以把代碼放到第一位母债，是因?yàn)檫@一點(diǎn)最容易引起技術(shù)人員的忽視邪狞。很多技術(shù)人員拿到一個(gè)性能優(yōu)化的需求以后挖垛，言必稱緩存、異步婉支、JVM等增蹭。實(shí)際上，第一步就應(yīng)該是分析相關(guān)的代碼磅摹，找出相應(yīng)的瓶頸滋迈，再來考慮具體的優(yōu)化策略。有一些性能問題户誓，完全是由于代碼寫的不合理饼灿，通過直接修改一下代碼就能解決問題的表伦，比如for循環(huán)次數(shù)過多嗅定、作了很多無謂的條件判斷、相同邏輯重復(fù)多次等摸袁。
數(shù)據(jù)庫
數(shù)據(jù)庫的調(diào)優(yōu)悼潭，總的來說分為以下三部分：
SQL調(diào)優(yōu)
這是最常用庇忌、每一個(gè)技術(shù)人員都應(yīng)該掌握基本的SQL調(diào)優(yōu)手段（包括方法、工具舰褪、輔助系統(tǒng)等）皆疹。這里以MySQL為例，最常見的方式是占拍，由自帶的慢查詢?nèi)罩净蛘唛_源的慢查詢系統(tǒng)定位到具體的出問題的SQL略就，然后使用explain、profile等工具來逐步調(diào)優(yōu)晃酒，最后經(jīng)過測試達(dá)到效果后上線表牢。這方面的細(xì)節(jié)，可以參考MySQL索引原理及慢查詢優(yōu)化贝次。
架構(gòu)層面的調(diào)優(yōu)
這一類調(diào)優(yōu)包括讀寫分離崔兴、多從庫負(fù)載均衡、水平和垂直分庫分表等方面，一般需要的改動較大敲茄，但是頻率沒有SQL調(diào)優(yōu)高螺戳，而且一般需要DBA來配合參與。那么什么時(shí)候需要做這些事情折汞？我們可以通過內(nèi)部監(jiān)控報(bào)警系統(tǒng)（比如Zabbix）倔幼，定期跟蹤一些指標(biāo)數(shù)據(jù)是否達(dá)到瓶頸，一旦達(dá)到瓶頸或者警戒值爽待，就需要考慮這些事情损同。通常，DBA也會定期監(jiān)控這些指標(biāo)值鸟款。
連接池調(diào)優(yōu)
我們的應(yīng)用為了實(shí)現(xiàn)數(shù)據(jù)庫連接的高效獲取膏燃、對數(shù)據(jù)庫連接的限流等目的，通常會采用連接池類的方案何什，即每一個(gè)應(yīng)用節(jié)點(diǎn)都管理了一個(gè)到各個(gè)數(shù)據(jù)庫的連接池组哩。隨著業(yè)務(wù)訪問量或者數(shù)據(jù)量的增長，原有的連接池參數(shù)可能不能很好地滿足需求处渣，這個(gè)時(shí)候就需要結(jié)合當(dāng)前使用連接池的原理伶贰、具體的連接池監(jiān)控?cái)?shù)據(jù)和當(dāng)前的業(yè)務(wù)量作一個(gè)綜合的判斷，通過反復(fù)的幾次調(diào)試得到最終的調(diào)優(yōu)參數(shù)罐栈。
緩存
分類
本地緩存（HashMap/ConcurrentHashMap黍衙、Ehcache、Guava Cache等）荠诬，緩存服務(wù)（Redis/Tair/Memcache等）琅翻。
使用場景
什么情況適合用緩存？考慮以下兩種場景：
- 短時(shí)間內(nèi)相同數(shù)據(jù)重復(fù)查詢多次且數(shù)據(jù)更新不頻繁柑贞，這個(gè)時(shí)候可以選擇先從緩存查詢方椎，查詢不到再從數(shù)據(jù)庫加載并回設(shè)到緩存的方式。此種場景較適合用單機(jī)緩存钧嘶。
- 高并發(fā)查詢熱點(diǎn)數(shù)據(jù)棠众，后端數(shù)據(jù)庫不堪重負(fù)，可以用緩存來扛康辑。
選型考慮
- 如果數(shù)據(jù)量小摄欲，并且不會頻繁地增長又清空（這會導(dǎo)致頻繁地垃圾回收），那么可以選擇本地緩存疮薇。具體的話，如果需要一些策略的支持（比如緩存滿的逐出策略）我注，可以考慮Ehcache按咒；如不需要，可以考慮HashMap；如需要考慮多線程并發(fā)的場景励七，可以考慮ConcurentHashMap智袭。
- 其他情況，可以考慮緩存服務(wù)掠抬。目前從資源的投入度吼野、可運(yùn)維性、是否能動態(tài)擴(kuò)容以及配套設(shè)施來考慮两波，我們優(yōu)先考慮Tair瞳步。除非目前Tair還不能支持的場合（比如分布式鎖、Hash類型的value）腰奋，我們考慮用Redis单起。
設(shè)計(jì)關(guān)鍵點(diǎn)
什么時(shí)候更新緩存？如何保障更新的可靠性和實(shí)時(shí)性劣坊？
更新緩存的策略嘀倒，需要具體問題具體分析。這里以門店P(guān)OI的緩存數(shù)據(jù)為例局冰，來說明一下緩存服務(wù)型的緩存更新策略是怎樣的测蘑？目前約10萬個(gè)POI數(shù)據(jù)采用了Tair作為緩存服務(wù)，具體更新的策略有兩個(gè)：
- 接收門店變更的消息康二，準(zhǔn)實(shí)時(shí)更新帮寻。
- 給每一個(gè)POI緩存數(shù)據(jù)設(shè)置5分鐘的過期時(shí)間，過期后從DB加載再回設(shè)到DB赠摇。這個(gè)策略是對第一個(gè)策略的有力補(bǔ)充固逗，解決了手動變更DB不發(fā)消息、接消息更新程序臨時(shí)出錯(cuò)等問題導(dǎo)致的第一個(gè)策略失效的問題藕帜。通過這種雙保險(xiǎn)機(jī)制烫罩，有效地保證了POI緩存數(shù)據(jù)的可靠性和實(shí)時(shí)性。
緩存是否會滿洽故，緩存滿了怎么辦贝攒？
對于一個(gè)緩存服務(wù)，理論上來說时甚，隨著緩存數(shù)據(jù)的日益增多隘弊，在容量有限的情況下，緩存肯定有一天會滿的荒适。如何應(yīng)對梨熙？
① 給緩存服務(wù)，選擇合適的緩存逐出算法刀诬，比如最常見的LRU咽扇。
② 針對當(dāng)前設(shè)置的容量，設(shè)置適當(dāng)?shù)木渲担热?0G的緩存质欲，當(dāng)緩存數(shù)據(jù)達(dá)到8G的時(shí)候树埠，就開始發(fā)出報(bào)警，提前排查問題或者擴(kuò)容嘶伟。
③ 給一些沒有必要長期保存的key怎憋，盡量設(shè)置過期時(shí)間。
緩存是否允許丟失九昧？丟失了怎么辦绊袋？
根據(jù)業(yè)務(wù)場景判斷，是否允許丟失耽装。如果不允許愤炸，就需要帶持久化功能的緩存服務(wù)來支持，比如Redis或者Tair掉奄。更細(xì)節(jié)的話规个，可以根據(jù)業(yè)務(wù)對丟失時(shí)間的容忍度，還可以選擇更具體的持久化策略姓建，比如Redis的RDB或者AOF诞仓。
緩存被“擊穿”問題
對于一些設(shè)置了過期時(shí)間的key，如果這些key可能會在某些時(shí)間點(diǎn)被超高并發(fā)地訪問速兔，是一種非呈茫“熱點(diǎn)”的數(shù)據(jù)。這個(gè)時(shí)候涣狗，需要考慮另外一個(gè)問題：緩存被“擊穿”的問題谍婉。
概念：緩存在某個(gè)時(shí)間點(diǎn)過期的時(shí)候，恰好在這個(gè)時(shí)間點(diǎn)對這個(gè)Key有大量的并發(fā)請求過來镀钓，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB加載數(shù)據(jù)并回設(shè)到緩存穗熬，這個(gè)時(shí)候大并發(fā)的請求可能會瞬間把后端DB壓垮。
-
如何解決：業(yè)界比較常用的做法丁溅，是使用mutex唤蔗。簡單地來說，就是在緩存失效的時(shí)候（判斷拿出來的值為空）窟赏，不是立即去load db妓柜，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者M(jìn)emcache的ADD）去set一個(gè)mutex key，當(dāng)操作返回成功時(shí)涯穷，再進(jìn)行l(wèi)oad db的操作并回設(shè)緩存棍掐；否則，就重試整個(gè)get緩存的方法求豫。類似下面的代碼：
public String get(key) { String value = redis.get(key); if (value == null) { //代表緩存值過期 //設(shè)置3min的超時(shí)塌衰，防止del操作失敗的時(shí)候诉稍，下次緩存過期一直不能load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表設(shè)置成功 value = db.get(key); redis.set(key, value, expire_secs); redis.del(key_mutex); } else {//這個(gè)時(shí)候代表同時(shí)候的其他線程已經(jīng)load db并回設(shè)到緩存了蝠嘉，這時(shí)候重試獲取緩存值即可 sleep(50); get(key); //重試 } } else { return value; } }
異步
使用場景
針對某些客戶端的請求最疆，在服務(wù)端可能需要針對這些請求做一些附屬的事情，這些事情其實(shí)用戶并不關(guān)心或者用戶不需要立即拿到這些事情的處理結(jié)果蚤告，這種情況就比較適合用異步的方式處理這些事情努酸。
作用
- 縮短接口響應(yīng)時(shí)間，使用戶的請求快速返回杜恰，用戶體驗(yàn)更好获诈。
- 避免線程長時(shí)間處于運(yùn)行狀態(tài)，這樣會引起服務(wù)線程池的可用線程長時(shí)間不夠用心褐，進(jìn)而引起線程池任務(wù)隊(duì)列長度增大舔涎，從而阻塞更多請求任務(wù)，使得更多請求得不到技術(shù)處理逗爹。
- 線程長時(shí)間處于運(yùn)行狀態(tài)亡嫌，可能還會引起系統(tǒng)Load、CPU使用率掘而、機(jī)器整體性能下降等一系列問題挟冠，甚至引發(fā)雪崩。異步的思路可以在不增加機(jī)器數(shù)和CPU數(shù)的情況下袍睡，有效解決這個(gè)問題知染。
常見做法
一種做法，是額外開辟線程斑胜，這里可以采用額外開辟一個(gè)線程或者使用線程池的做法控淡，在IO線程（處理請求響應(yīng)）之外的線程來處理相應(yīng)的任務(wù)，在IO線程中讓response先返回止潘。
如果異步線程處理的任務(wù)設(shè)計(jì)的數(shù)據(jù)量非常巨大掺炭，那么可以引入阻塞隊(duì)列BlockingQueue作進(jìn)一步的優(yōu)化。具體做法是讓一批異步線程不斷地往阻塞隊(duì)列里扔數(shù)據(jù)覆山，然后額外起一個(gè)處理線程竹伸，循環(huán)批量從隊(duì)列里拿預(yù)設(shè)大小的一批數(shù)據(jù)，來進(jìn)行批處理（比如發(fā)一個(gè)批量的遠(yuǎn)程服務(wù)請求）簇宽，這樣進(jìn)一步提高了性能勋篓。
另一種做法，是使用消息隊(duì)列（MQ）中間件服務(wù)魏割，MQ天生就是異步的譬嚣。一些額外的任務(wù)，可能不需要我這個(gè)系統(tǒng)來處理钞它，但是需要其他系統(tǒng)來處理拜银。這個(gè)時(shí)候可以先把它封裝成一個(gè)消息殊鞭，扔到消息隊(duì)列里面，通過消息中間件的可靠性保證把消息投遞到關(guān)心它的系統(tǒng)尼桶，然后讓這個(gè)系統(tǒng)來做相應(yīng)的處理操灿。
比如C端在完成一個(gè)提單動作以后，可能需要其它端做一系列的事情泵督，但是這些事情的結(jié)果不會立刻對C端用戶產(chǎn)生影響趾盐，那么就可以先把C端下單的請求響應(yīng)先返回給用戶，返回之前往MQ中發(fā)一個(gè)消息即可小腊。而且這些事情理應(yīng)不是C端的負(fù)責(zé)范圍救鲤，所以這個(gè)時(shí)候用MQ的方式，來解決這個(gè)問題最合適秩冈。
NoSQL
和緩存的區(qū)別
先說明一下本缠，這里介紹的和緩存那一節(jié)不一樣，雖然可能會使用一樣的數(shù)據(jù)存儲方案（比如Redis或者Tair）入问，但是使用的方式不一樣丹锹，這一節(jié)介紹的是把它作為DB來用。如果當(dāng)作DB來用队他，需要有效保證數(shù)據(jù)存儲方案的可用性卷仑、可靠性。
使用場景
需要結(jié)合具體的業(yè)務(wù)場景麸折，看這塊業(yè)務(wù)涉及的數(shù)據(jù)是否適合用NoSQL來存儲锡凝，對數(shù)據(jù)的操作方式是否適合用NoSQL的方式來操作，或者是否需要用到NoSQL的一些額外特性（比如原子加減等）垢啼。
如果業(yè)務(wù)數(shù)據(jù)不需要和其他數(shù)據(jù)作關(guān)聯(lián)窜锯，不需要事務(wù)或者外鍵之類的支持，而且有可能寫入會異常頻繁芭析，這個(gè)時(shí)候就比較適合用NoSQL（比如HBase）锚扎。
比如，美團(tuán)點(diǎn)評內(nèi)部有一個(gè)對exception做的監(jiān)控系統(tǒng)馁启，如果在應(yīng)用系統(tǒng)發(fā)生嚴(yán)重故障的時(shí)候驾孔，可能會短時(shí)間產(chǎn)生大量exception數(shù)據(jù)，這個(gè)時(shí)候如果選用MySQL惯疙，會造成MySQL的瞬間寫壓力飆升翠勉，容易導(dǎo)致MySQL服務(wù)器的性能急劇惡化以及主從同步延遲之類的問題，這種場景就比較適合用Hbase類似的NoSQL來存儲霉颠。
JVM調(diào)優(yōu)
什么時(shí)候調(diào)对碌？
通過監(jiān)控系統(tǒng)（如沒有現(xiàn)成的系統(tǒng)，自己做一個(gè)簡單的上報(bào)監(jiān)控的系統(tǒng)也很容易）上對一些機(jī)器關(guān)鍵指標(biāo)（gc time蒿偎、gc count朽们、各個(gè)分代的內(nèi)存大小變化怀读、機(jī)器的Load值與CPU使用率、JVM的線程數(shù)等）的監(jiān)控報(bào)警骑脱，也可以看gc log和jstat等命令的輸出菜枷，再結(jié)合線上JVM進(jìn)程服務(wù)的一些關(guān)鍵接口的性能數(shù)據(jù)和請求體驗(yàn)，基本上就能定位出當(dāng)前的JVM是否有問題惜姐，以及是否需要調(diào)優(yōu)犁跪。
怎么調(diào)椿息？
- 如果發(fā)現(xiàn)高峰期CPU使用率與Load值偏大歹袁，這個(gè)時(shí)候可以觀察一些JVM的thread count以及gc count（可能主要是young gc count），如果這兩個(gè)值都比以往偏大（也可以和一個(gè)歷史經(jīng)驗(yàn)值作對比）寝优，基本上可以定位是young gc頻率過高導(dǎo)致条舔，這個(gè)時(shí)候可以通過適當(dāng)增大young區(qū)大小或者占比的方式來解決。
- 如果發(fā)現(xiàn)關(guān)鍵接口響應(yīng)時(shí)間很慢乏矾，可以結(jié)合gc time以及gc log中的stop the world的時(shí)間孟抗，看一下整個(gè)應(yīng)用的stop the world的時(shí)間是不是比較多。如果是钻心，可能需要減少總的gc time凄硼，具體可以從減小gc的次數(shù)和減小單次gc的時(shí)間這兩個(gè)維度來考慮，一般來說捷沸，這兩個(gè)因素是一對互斥因素摊沉，我們需要根據(jù)實(shí)際的監(jiān)控?cái)?shù)據(jù)來調(diào)整相應(yīng)的參數(shù)（比如新生代與老生代比值、eden與survivor比值痒给、MTT值说墨、觸發(fā)cms回收的old區(qū)比率閾值等）來達(dá)到一個(gè)最優(yōu)值。
- 如果發(fā)生full gc或者old cms gc非常頻繁苍柏，通常這種情況會誘發(fā)STW的時(shí)間相應(yīng)加長尼斧，從而也會導(dǎo)致接口響應(yīng)時(shí)間變慢。這種情況试吁，大概率是出現(xiàn)了“內(nèi)存泄露”棺棵，Java里的內(nèi)存泄露指的是一些應(yīng)該釋放的對象沒有被釋放掉（還有引用拉著它）。那么這些對象是如何產(chǎn)生的呢熄捍？為啥不會釋放呢烛恤？對應(yīng)的代碼是不是出問題了？問題的關(guān)鍵是搞明白這個(gè)治唤，找到相應(yīng)的代碼棒动，然后對癥下藥。所以問題的關(guān)鍵是轉(zhuǎn)化成尋找這些對象宾添。怎么找船惨？綜合使用jmap和MAT柜裸，基本就能定位到具體的代碼。
多線程與分布式
使用場景
離線任務(wù)粱锐、異步任務(wù)疙挺、大數(shù)據(jù)任務(wù)、耗時(shí)較長任務(wù)的運(yùn)行怜浅，適當(dāng)?shù)乩妙砣唬蛇_(dá)到加速的效果。
注意：線上對響應(yīng)時(shí)間要求較高的場合恶座，盡量少用多線程搀暑，尤其是服務(wù)線程需要等待任務(wù)線程的場合（很多重大事故就是和這個(gè)息息相關(guān)），如果一定要用跨琳，可以對服務(wù)線程設(shè)置一個(gè)最大等待時(shí)間自点。
常見做法
如果單機(jī)的處理能力可以滿足實(shí)際業(yè)務(wù)的需求，那么盡可能地使用單機(jī)多線程的處理方式脉让，減少復(fù)雜性桂敛；反之，則需要使用多機(jī)多線程的方式溅潜。
對于單機(jī)多線程术唬，可以引入線程池的機(jī)制，作用有二：
- 提高性能滚澜，節(jié)省線程創(chuàng)建和銷毀的開銷
- 限流粗仓，給線程池一個(gè)固定的容量，達(dá)到這個(gè)容量值后再有任務(wù)進(jìn)來博秫，就進(jìn)入隊(duì)列進(jìn)行排隊(duì)潦牛，保障機(jī)器極限壓力下的穩(wěn)定處理能力在使用JDK自帶的線程池時(shí)，一定要仔細(xì)理解構(gòu)造方法的各個(gè)參數(shù)的含義挡育，如core pool size巴碗、max pool size、keepAliveTime即寒、worker queue等橡淆，在理解的基礎(chǔ)上通過不斷地測試調(diào)整這些參數(shù)值達(dá)到最優(yōu)效果。
如果單機(jī)的處理能力不能滿足需求母赵，這個(gè)時(shí)候需要使用多機(jī)多線程的方式逸爵。這個(gè)時(shí)候就需要一些分布式系統(tǒng)的知識了。首先就必須引入一個(gè)單獨(dú)的節(jié)點(diǎn)凹嘲，作為調(diào)度器师倔，其他的機(jī)器節(jié)點(diǎn)都作為執(zhí)行器節(jié)點(diǎn)。調(diào)度器來負(fù)責(zé)拆分任務(wù)周蹭，和分發(fā)任務(wù)到合適的執(zhí)行器節(jié)點(diǎn)趋艘；執(zhí)行器節(jié)點(diǎn)按照多線程的方式（也可能是單線程）來執(zhí)行任務(wù)疲恢。這個(gè)時(shí)候，我們整個(gè)任務(wù)系統(tǒng)就由單擊演變成一個(gè)集群的系統(tǒng)瓷胧，而且不同的機(jī)器節(jié)點(diǎn)有不同的角色显拳，各司其職，各個(gè)節(jié)點(diǎn)之間還有交互搓萧。這個(gè)時(shí)候除了有多線程杂数、線程池等機(jī)制，像RPC瘸洛、心跳等網(wǎng)絡(luò)通信調(diào)用的機(jī)制也不可少揍移。后續(xù)我會出一個(gè)簡單的分布式調(diào)度運(yùn)行的框架。
度量系統(tǒng)（監(jiān)控货矮、報(bào)警羊精、服務(wù)依賴管理）
嚴(yán)格來說，度量系統(tǒng)不屬于性能優(yōu)化的范疇囚玫，但是這方面和性能優(yōu)化息息相關(guān)，可以說為性能優(yōu)化提供一個(gè)強(qiáng)有力的數(shù)據(jù)參考和支撐读规。沒有度量系統(tǒng)抓督，基本上就沒有辦法定位到系統(tǒng)的問題，也沒有辦法有效衡量優(yōu)化后的效果束亏。很多人不重視這方面铃在，但我認(rèn)為它是系統(tǒng)穩(wěn)定性和性能保障的基石。
關(guān)鍵流程
如果要設(shè)計(jì)這套系統(tǒng)碍遍，總體來說有哪些關(guān)鍵流程需要設(shè)計(jì)呢定铜？
① 確定指標(biāo)
② 采集數(shù)據(jù)
③ 計(jì)算數(shù)據(jù)，存儲結(jié)果
④ 展現(xiàn)和分析
需要監(jiān)控和報(bào)警哪些指標(biāo)數(shù)據(jù)怕敬？需要關(guān)注哪些揣炕？
按照需求出發(fā)，主要需要二方面的指標(biāo)：
- 接口性能相關(guān)东跪，包括單個(gè)接口和全部的QPS畸陡、響應(yīng)時(shí)間、調(diào)用量（統(tǒng)計(jì)時(shí)間維度越細(xì)越好虽填；最好是丁恭，既能以節(jié)點(diǎn)為維度，也可以以服務(wù)集群為維度斋日，來查看相關(guān)數(shù)據(jù)）牲览。其中還涉及到服務(wù)依賴關(guān)系的管理，這個(gè)時(shí)候需要用到服務(wù)依賴管理系統(tǒng)
- 單個(gè)機(jī)器節(jié)點(diǎn)相關(guān)恶守，包括CPU使用率第献、Load值跛蛋、內(nèi)存占用率、網(wǎng)卡流量等痊硕。如果節(jié)點(diǎn)是一些特殊類型的服務(wù)（比如MySQL赊级、Redis、Tair）岔绸，還可以監(jiān)控這些服務(wù)特有的一些關(guān)鍵指標(biāo)理逊。
數(shù)據(jù)采集方式
通常采用異步上報(bào)的方式，具體做法有兩種：第一種盒揉，發(fā)到本地的Flume端口晋被，由Flume進(jìn)程收集到遠(yuǎn)程的Hadoop集群或者Storm集群來進(jìn)行運(yùn)算；第二種刚盈，直接在本地運(yùn)算好以后羡洛，使用異步和本地隊(duì)列的方式，發(fā)送到監(jiān)控服務(wù)器藕漱。
數(shù)據(jù)計(jì)算
可以采用離線運(yùn)算（MapReduce/Hive）或者實(shí)時(shí)/準(zhǔn)實(shí)時(shí)運(yùn)算（Storm/Spark）的方式欲侮，運(yùn)算后的結(jié)果存入MySQL或者HBase；某些情況肋联，也可以不計(jì)算威蕉，直接采集發(fā)往監(jiān)控服務(wù)器。
展現(xiàn)和分析
提供統(tǒng)一的展現(xiàn)分析平臺橄仍，需要帶報(bào)表（列表/圖表）監(jiān)控和報(bào)警的功能韧涨。
