快被系統(tǒng)性能逼瘋了？你需要這份性能優(yōu)化策略

作者：dbaplus社群 2019-01-04 13:30:58

由于系統(tǒng)已經(jīng)開發(fā)完成，根據(jù)性能優(yōu)化修改范圍盡可能小且不引入更多問(wèn)題的原則，本文將只討論對(duì)系統(tǒng)進(jìn)行局部?jī)?yōu)化的方法，而系統(tǒng)初始設(shè)計(jì)時(shí)為了提高性能而進(jìn)行的設(shè)計(jì)不在討論范圍之內(nèi)。

作者介紹

劉迪偉，就職于世界五***銀行。負(fù)責(zé)公司網(wǎng)銀業(yè)務(wù)系統(tǒng)的設(shè)計(jì)和交付，擅長(zhǎng)并持續(xù)關(guān)注Java性能優(yōu)化、DevOps等領(lǐng)域。

XX銀行網(wǎng)銀系統(tǒng)是一套全新的對(duì)公業(yè)務(wù)渠道類系統(tǒng)，經(jīng)過(guò)兩年的建設(shè)，將逐步對(duì)外提供服務(wù)。

該系統(tǒng)融合了原來(lái)多個(gè)對(duì)公渠道系統(tǒng)，并發(fā)量是以前多個(gè)系統(tǒng)之和，吞吐量要求將大幅上升。為了使廣大對(duì)公客戶使用系統(tǒng)時(shí)獲得更快的響應(yīng)時(shí)間體驗(yàn)，項(xiàng)目組對(duì)系統(tǒng)進(jìn)行了持續(xù)的性能測(cè)試和優(yōu)化。這一過(guò)程中，形成了一套針對(duì)新建系統(tǒng)進(jìn)行性能測(cè)試和優(yōu)化的方法論。

該方法論包括測(cè)試環(huán)境準(zhǔn)備、測(cè)試功能優(yōu)先級(jí)、性能優(yōu)化原則、常用性能指標(biāo)及工具、工具使用方法、常見性能問(wèn)題原因和優(yōu)化方法，以及典型案例和進(jìn)一步優(yōu)化方法的討論。

我們使用Linux操作系統(tǒng)，壓測(cè)工具為loadrunner，中間件版本包括IHS8.5.5.9、WAS8.5、IBMJDK1.7（IBM J9VM）、DB2V10、Redis3.2.3。

一、應(yīng)用系統(tǒng)性能評(píng)價(jià)指標(biāo)

響應(yīng)時(shí)間：盡快的給用戶返回響應(yīng)，體現(xiàn)系統(tǒng)處理請(qǐng)求的速度；
吞吐量TPS：每秒完成的事務(wù)數(shù)，體現(xiàn)系統(tǒng)處理能力；
并發(fā)性：業(yè)務(wù)請(qǐng)求高并發(fā)時(shí)，系統(tǒng)能否穩(wěn)定運(yùn)行；
擴(kuò)展性：單機(jī)處理能力不足時(shí)，系統(tǒng)能否橫向擴(kuò)展。

TPS = 并發(fā)用戶數(shù) / 響應(yīng)時(shí)間

二、常見性能監(jiān)控指標(biāo)及工具

1、操作系統(tǒng)監(jiān)控指標(biāo)及工具

主要監(jiān)控指標(biāo)：CPU、系統(tǒng)CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)IO、請(qǐng)求耗時(shí)。

常用命令：

top –H –p pid：cpu負(fù)載監(jiān)控，實(shí)時(shí)查看占用cpu高的線程；
vmstat：系統(tǒng)負(fù)載監(jiān)控；
pidstat：cpu讓步式上下文切換監(jiān)控，監(jiān)控鎖競(jìng)爭(zhēng)；
iostat：磁盤利用率監(jiān)控；
nmon：監(jiān)控cpu、內(nèi)存、io使用率 ./nmon -f -t -s 2 -c 100 每2秒采集一次，共100次；
netstat -anp|grep端口或IP|grep ESTABLISHED|wc -l：服務(wù)器連接數(shù)監(jiān)控。

2、JVM監(jiān)控指標(biāo)及工具

Jconsole，監(jiān)控cpu、內(nèi)存垃圾回收。

JVM啟動(dòng)參數(shù)中增加：

-Dcom.sun.management.jmxremote.port=1088

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

jvisualvm，cpu采樣、java方法耗時(shí)分析、jvm線程棧快照、監(jiān)控cpu、內(nèi)存垃圾回收。

CPU抽樣：

線程快照：

jca457.jar，ibm javacore線程快照分析：

ga456.jar，ibmjvm垃圾回收gc分析：

ha456.jar，ibmjvm內(nèi)存，heapdump分析，內(nèi)存溢出時(shí)使用；
TProfiler，cpu采樣、java方法cpu耗時(shí)分析，cpu高，響應(yīng)慢時(shí)使用；
JProfiler，cpu采樣、java方法cpu耗時(shí)分析，cpu高，響應(yīng)慢時(shí)使用；
OracleDeveloperStudio12.6-linux-x86，cpu采樣、java方法cpu耗時(shí)分析，cpu高，響應(yīng)慢時(shí)使用。

三、性能測(cè)試前置條件

1、數(shù)據(jù)庫(kù)表數(shù)據(jù)量準(zhǔn)確

要和生產(chǎn)數(shù)據(jù)量保持一致，至少一個(gè)數(shù)量級(jí)。數(shù)據(jù)分布盡量均勻。

2、測(cè)試環(huán)境和生產(chǎn)一致

測(cè)試環(huán)境機(jī)器配置、參數(shù)、代碼盡可能和生產(chǎn)保持一致（數(shù)據(jù)庫(kù)服務(wù)器硬件除外）。

3、合理確定并發(fā)用戶量

系統(tǒng)并發(fā)用戶量有多種算法可以估算：

平均并發(fā)用戶數(shù)：

C=nL/T(n是考察時(shí)間內(nèi)用戶登錄數(shù)，L是用戶平均在線時(shí)間長(zhǎng)度，T是考察值時(shí)間長(zhǎng)度)

并發(fā)用戶數(shù)峰值：C’=C + 3*根號(hào)C
用戶總量/統(tǒng)計(jì)時(shí)間*影響因子：

網(wǎng)銀用戶量100萬(wàn)，根據(jù)2/8原則， 80%用戶在上午9點(diǎn)到11點(diǎn)，下午2點(diǎn)到4點(diǎn)之間登錄系統(tǒng)，每次登錄耗時(shí)1到1.5秒。則并發(fā)用戶為：

1000000*0.8/4/3600*1.5=82.5，

1000000*0.8/4/3600*1=55
根據(jù)系統(tǒng)用戶數(shù)計(jì)算：

并發(fā)用戶數(shù)=系統(tǒng)***在線用戶數(shù)的8%到12%
根據(jù)TPS估計(jì)：

C=（Think Time + 1）* TPS，

網(wǎng)銀用戶思考時(shí)間10s，

C=（10+1）* 3=33。

4、預(yù)估各功能交易量，確定壓測(cè)功能優(yōu)先級(jí)

根據(jù)交易量從大到小排名，排名靠前的優(yōu)先壓測(cè)。

5、設(shè)置性能問(wèn)題認(rèn)定標(biāo)準(zhǔn)

比如響應(yīng)時(shí)間超過(guò)3s、TPS低于10、服務(wù)器cpu占用率超過(guò)70%、jvm堆內(nèi)存使用100%、垃圾回收頻繁、網(wǎng)絡(luò)IO或磁盤IO達(dá)到瓶頸等……都可能是性能問(wèn)題。

四、性能優(yōu)化一般思路

1、找到性能瓶頸

性能瓶頸定義：導(dǎo)致系統(tǒng)TPS低、響應(yīng)時(shí)間長(zhǎng)、資源（CPU、內(nèi)存、網(wǎng)絡(luò)）占用高等問(wèn)題的關(guān)鍵程序模塊。提升該程序模塊的性能，可以大幅度改善性能。

常見的性能瓶頸原因包括：數(shù)據(jù)庫(kù)慢查詢SQL、日志打印、xml大報(bào)文解析和格式轉(zhuǎn)換、復(fù)雜業(yè)務(wù)邏輯、鎖競(jìng)爭(zhēng)等。

2、如何找到性能瓶頸

使用LoadRunner給每個(gè)接口的增加事務(wù)，記錄其響應(yīng)時(shí)間和TPS，最慢的那個(gè)接口往往是瓶頸；
分析慢交易的日志，查看是哪個(gè)操作耗時(shí)最長(zhǎng)；
分析數(shù)據(jù)庫(kù)快照，看是否有執(zhí)行較慢或者全表掃描的SQL；
通過(guò)Javacore查看線程正在執(zhí)行的代碼，是大部分阻塞在IO上，還是大部分在進(jìn)行計(jì)算。針對(duì)不同的問(wèn)題，使用不同的分析工具。詳細(xì)內(nèi)容可以看下一章節(jié)。

3、針對(duì)性能瓶頸進(jìn)行合理優(yōu)化

性能優(yōu)化原則：

先優(yōu)化瓶頸問(wèn)題；
方案簡(jiǎn)單，盡量不引入更多復(fù)雜性，盡量不降低業(yè)務(wù)體驗(yàn)；
滿足系統(tǒng)性能要求即可，不引入新的bug。

五、常見問(wèn)題及優(yōu)化方法

1、SQL執(zhí)行時(shí)間長(zhǎng)

問(wèn)題現(xiàn)象：系統(tǒng)響應(yīng)時(shí)間長(zhǎng)、數(shù)據(jù)庫(kù)cpu高。

問(wèn)題原因：全表掃描、索引低效、排序溢出。

解決方法：

通過(guò)DB2數(shù)據(jù)庫(kù)快照查看執(zhí)行時(shí)間長(zhǎng)的SQL，查看該SQL執(zhí)行計(jì)劃，在cost比較高的SQL上增加合適索引。要求所有大表SQL執(zhí)行計(jì)劃的cost低于100，超過(guò)100的SQL要評(píng)審。對(duì)于排序溢出、可參考數(shù)據(jù)中心規(guī)范設(shè)置排序堆大小，規(guī)范中排序堆設(shè)置為AUTOMATIC。
制定數(shù)據(jù)庫(kù)表清理策略。根據(jù)數(shù)據(jù)的生命周期要求，對(duì)流水類的數(shù)據(jù)定期進(jìn)行清理備份，不再長(zhǎng)期保留。定期對(duì)全庫(kù)的表結(jié)構(gòu)進(jìn)行reorg、runstats操作，以提高索引效率。

排查方法：

獲得數(shù)據(jù)庫(kù)快照：db2 get snapshot for all on corpdb >gswyzfzzshpl1207.log
從快照中提取慢SQL，Toad查看SQL執(zhí)行計(jì)劃
Db2命令方式查看SQL執(zhí)行計(jì)劃：db2expln -d corpdb -t -g -q "SQL語(yǔ)句"
執(zhí)行計(jì)劃查看方法：自上而下查看cost***的分支，找到未走索引或索引使用不當(dāng)?shù)谋?/p>

2、數(shù)據(jù)庫(kù)出現(xiàn)死鎖

問(wèn)題現(xiàn)象：數(shù)據(jù)庫(kù)快照檢測(cè)到存在數(shù)據(jù)庫(kù)死鎖，或通過(guò)db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt生成死鎖監(jiān)控文件，快照或監(jiān)控文件中存在deadlock的情況。

問(wèn)題原因：全表掃描、大事務(wù)、更新相同表記錄的SQL執(zhí)行順序交叉等。

解決方法：縮短事務(wù)路徑長(zhǎng)度，避免全表掃描。如果必須存在大事務(wù)，則更新相同表的SQL執(zhí)行順序一致，并且堅(jiān)決避免全表掃描。網(wǎng)銀系統(tǒng)指令發(fā)送功能全表掃描+全局大事務(wù)，導(dǎo)致數(shù)據(jù)庫(kù)死鎖。

排查方法：根據(jù)死鎖監(jiān)控文件dlock.txt找到導(dǎo)致死鎖的SQL，以及該SQL持有的鎖，分析該SQL可能存在的問(wèn)題。

3、線程阻塞在日志記錄上

問(wèn)題現(xiàn)象：系統(tǒng)響應(yīng)時(shí)間長(zhǎng)、通過(guò)javacore查看很多線程阻塞在打印日志上。

問(wèn)題原因：log4j1.x版本較低，性能較差；大報(bào)文日志多次輸出。

解決方法：

減少無(wú)效日志、刪除無(wú)用日志，減少大日志輸出。
升級(jí)log4j組件到log4j2，參考log4j2官方文檔，配置合理的日志緩沖區(qū)，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用異步日志。因?yàn)榫W(wǎng)銀系統(tǒng)日志量較大，異步日志隊(duì)列很快就滿了，如果單條日志存在大報(bào)文，還有可能導(dǎo)致內(nèi)存溢出，因此不適合采用異步日志。如果日志量少（壓測(cè)產(chǎn)生日志的速度，低于日志寫入文件的速度），則可以使用異步日志，大幅提高性能。如果日志量較大，則不建議使用異步日志。

排查方法：

JVM啟動(dòng)參數(shù)中增加-XX:+HeapDumpOnCtrlBreak，壓測(cè)進(jìn)行時(shí)，kill -3 pid 殺幾個(gè)javacore，使用jca457.jar工具打開并分析。推薦使用該工具，因?yàn)樵摴ぞ呖梢詫?duì)所有線程狀態(tài)進(jìn)行統(tǒng)計(jì)，并生成餅狀圖，方便查看。
壓測(cè)進(jìn)行時(shí)，使用jvisualvm獲取jvm快照，分析線程堆棧。

4、多線程并發(fā)問(wèn)題

問(wèn)題現(xiàn)象：采用合理的并發(fā)數(shù)壓測(cè)，系統(tǒng)出現(xiàn)邏輯錯(cuò)誤、交易失敗或異常報(bào)錯(cuò)。經(jīng)查是由于對(duì)象中變量被異常修改導(dǎo)致。

問(wèn)題原因：系統(tǒng)中全局對(duì)象中的類變量或全局對(duì)象，被多個(gè)線程修改。

解決方法：排查系統(tǒng)中所有持有全局對(duì)象或類變量的代碼，檢查其全局變量是否可能被多個(gè)線程并行修改。

修改方法：

將全局變量轉(zhuǎn)成方法內(nèi)的局部變量；
對(duì)全局變量進(jìn)行同步控制比如syncronized代碼塊，或者java.util.concurrent鎖。

排查方法：并發(fā)問(wèn)題很可能是由全局變量或者對(duì)象導(dǎo)致，準(zhǔn)確識(shí)別全局變量，通過(guò)閱讀代碼找問(wèn)題。建議應(yīng)用梳理所有可能存放全局對(duì)象的代碼，統(tǒng)一管控，或者把所有全局對(duì)象放到一個(gè)類中，方便管理。

5、打開了太多文件

問(wèn)題現(xiàn)象：采用合理的并發(fā)數(shù)壓測(cè)，交易失敗，或后臺(tái)日志報(bào)錯(cuò)：To many open files。

問(wèn)題原因：

讀取配置文件或者業(yè)務(wù)數(shù)據(jù)文件后，未關(guān)閉文件流；
/etc/security/limits.conf中***打開文件數(shù)配置過(guò)小。

解決方法：

使用lsof –p pid 命令查看進(jìn)程打開的文件，如果大部分文件都是同一類型的文件，說(shuō)明可能未關(guān)閉文件流。找到打開文件的代碼，關(guān)閉文件流即可。
如果不存在未關(guān)閉文件流的問(wèn)題，且業(yè)務(wù)本身就需要處理大量文件，則修改/etc/security/limits.conf文件如下內(nèi)容：

* hard nproc 10240

* soft nproc 10240

6、內(nèi)存泄漏

問(wèn)題現(xiàn)象：JVM內(nèi)存耗盡，后臺(tái)日志拋出OutOfMemeryError異常；

問(wèn)題原因：內(nèi)存溢出問(wèn)題可能的原因比較多，可能是全局的List、Map等對(duì)象不斷被擴(kuò)大，也可能是程序不慎將大量數(shù)據(jù)讀到內(nèi)存里；可能是循環(huán)操作導(dǎo)致，也可能后臺(tái)線程定時(shí)觸發(fā)加載數(shù)據(jù)導(dǎo)致。

解決方法：對(duì)于ibmjdk純java應(yīng)用，在jvm啟動(dòng)時(shí)設(shè)置-XX:+HeapDumpOnOutOfMemory Error參數(shù)，會(huì)在內(nèi)存溢出時(shí)生成heapdump文件。使用ha456.jar工具打開heapdump文件，分析大對(duì)象是如何產(chǎn)生的。

當(dāng)然，在heapdump中對(duì)象類型可能只是List這種結(jié)構(gòu)，看不出具體哪個(gè)業(yè)務(wù)代碼創(chuàng)建的對(duì)象。此時(shí)要分析所有的全局對(duì)象，列出可疑的List或Map對(duì)象，排查其溢出原因。

全局對(duì)象、引用的初始化、修改要慎重。建議應(yīng)用梳理所有可能存放全局對(duì)象的代碼，統(tǒng)一管控。

7、JVM垃圾回收頻繁

問(wèn)題現(xiàn)象：top –H –p pid命令查看，GC Slave線程CPU占用排名始終為前三名，同時(shí)Jconsole查看jvm內(nèi)存占用較高，垃圾回收頻繁。使用ga456.jar分析gc日志，查看gc頻率、時(shí)長(zhǎng)。

打印gc日志的方法：在jvm啟動(dòng)參數(shù)里增加-verbose:gc -Xverbosegclog:/usr/ebank/ logs/cobp/gcdetail.log

問(wèn)題原因：高并發(fā)下，內(nèi)存對(duì)象較多，jvm堆內(nèi)存不夠用。

解決方法：擴(kuò)大堆內(nèi)存大小–Xmx2048m –Xms2048m。

8、CPU高

問(wèn)題現(xiàn)象：50并發(fā)壓測(cè)，監(jiān)控工具顯示bp、前置CPU占用90%以上。

問(wèn)題原因：業(yè)務(wù)處理中存在大量CPU計(jì)算操作。

解決方法：采用更高效的算法、數(shù)據(jù)結(jié)構(gòu)替換原來(lái)消耗CPU的代碼，或者采用新的設(shè)計(jì)繞過(guò)瓶頸代碼，比如查找數(shù)據(jù)的邏輯，可以把List改為Map，以空間換時(shí)間；比如用Json報(bào)文替換XML報(bào)文，提高傳輸、解析和打印日志的效率。

導(dǎo)致Cpu計(jì)算資源高消耗的代碼：報(bào)文格式轉(zhuǎn)換、加解密、正則表達(dá)式、低效的循環(huán)、低效的正則表達(dá)式。

排查方法：

壓測(cè)進(jìn)行時(shí)，使用jvisualvm工具遠(yuǎn)程連接應(yīng)用，點(diǎn)抽樣器àCPU，點(diǎn)快照生成線程快照。采樣一段時(shí)間后，抽樣器會(huì)顯示各個(gè)方法占用cpu時(shí)間，可以針對(duì)CPU時(shí)間占用高的方法進(jìn)行優(yōu)化。
使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分別分析消耗CPU時(shí)間長(zhǎng)的方法，以上工具分析結(jié)果可能有些差別。針對(duì)CPU計(jì)算耗時(shí)最長(zhǎng)的方法進(jìn)行優(yōu)化。

9、批處理時(shí)間長(zhǎng)、數(shù)據(jù)庫(kù)逐筆插入緩慢

問(wèn)題現(xiàn)象：大批量數(shù)據(jù)（10萬(wàn)條以上）更新或插入數(shù)據(jù)庫(kù)，耗時(shí)較長(zhǎng)。

問(wèn)題原因：批量數(shù)據(jù)處理時(shí)，如果逐條更新數(shù)據(jù)庫(kù)，則會(huì)存在大量網(wǎng)絡(luò)io、磁盤io，耗時(shí)較長(zhǎng)，而且對(duì)數(shù)據(jù)庫(kù)資源消耗較大。

解決方法：

采用java提供的batchUpdate方法批量更新數(shù)據(jù)庫(kù)，每1000條commit一次，可大幅提高數(shù)據(jù)更新效率。
單線程改成線程池，并行處理，充分利用多核CPU，通過(guò)數(shù)據(jù)庫(kù)或者其他同步鎖控制并行性；增加緩沖池，降低數(shù)據(jù)庫(kù)或磁盤IO訪問(wèn)頻次。

10、數(shù)據(jù)庫(kù)CPU高

問(wèn)題現(xiàn)象：后臺(tái)指令發(fā)送滿負(fù)荷工作時(shí)，數(shù)據(jù)庫(kù)CPU高。

問(wèn)題原因：后臺(tái)指令發(fā)送線程每次對(duì)全量查詢結(jié)果排序，結(jié)果集很大，然后取一條記錄；索引區(qū)分度不高，滿負(fù)荷執(zhí)行時(shí)；查詢頻率很高；壓測(cè)顯示，并行發(fā)送指令的后臺(tái)線程越多，數(shù)據(jù)庫(kù)CPU越高，效率越低。

解決方法：

去掉ORDER BY，增加索引后，效果不明顯。因?yàn)榻Y(jié)果集大和查詢頻繁兩個(gè)問(wèn)題沒有解決，因此考慮使用設(shè)計(jì)新的方案。
新方案：設(shè)計(jì)指令發(fā)送線程池，生產(chǎn)者線程每臺(tái)任務(wù)服務(wù)器只有一個(gè)線程，負(fù)責(zé)查詢待發(fā)送指令，每次查詢50條指令。每條指令包裝成一個(gè)Runnable對(duì)象，放進(jìn)ThreadPoolExecutor線程池，線程池大小參數(shù)設(shè)置為100或200。每當(dāng)線程池滿時(shí)，生產(chǎn)者停止生產(chǎn)指令，休息15秒后繼續(xù)。消費(fèi)者線程即線程池里的線程，參數(shù)設(shè)置為4，8或12（和不同指令類型的指令數(shù)據(jù)量成正比）。

改進(jìn)后的方案，數(shù)據(jù)庫(kù)CPU降到10%一下，發(fā)送效率單機(jī)提升6倍，且可線性擴(kuò)展任務(wù)服務(wù)器。

11、壓測(cè)TPS曲線劇烈下降或抖動(dòng)

問(wèn)題現(xiàn)象：50并發(fā)壓測(cè)，TPS曲線正常應(yīng)該是平緩的，波動(dòng)不大，如果突然出現(xiàn)劇烈下降，并且短時(shí)間內(nèi)無(wú)法恢復(fù)，則可能存在問(wèn)題。

問(wèn)題原因：一般是由于前置或bp的jvm進(jìn)行垃圾回收，或者日志記錄磁盤滿導(dǎo)致的。

解決方法：如果不是特別劇烈的波動(dòng)或者TPS曲線下降后長(zhǎng)時(shí)間不反彈，則可以忽略該問(wèn)題。否則，需要分析曲線下降的時(shí)刻，系統(tǒng)當(dāng)時(shí)正在發(fā)生的事情。可以通過(guò)top命令監(jiān)控當(dāng)時(shí)CPU占用比價(jià)高的線程，也可以kill -3 pid殺javacore來(lái)查看線程堆棧。

六、優(yōu)化案例

1、網(wǎng)銀系統(tǒng)基本情況

1）壓測(cè)環(huán)境系統(tǒng)架構(gòu)

壓測(cè)環(huán)境不包括F5，只有1臺(tái)WEB、1臺(tái)前置（應(yīng)用服務(wù)器）、1臺(tái)BP（業(yè)務(wù)處理服務(wù)器）、1臺(tái)DB、1臺(tái)Redis服務(wù)器。

2）客戶請(qǐng)求鏈路：

客戶端壓力機(jī)-〉Web-〉PRE-〉BP-〉DB2 ；

客戶端壓力機(jī)-〉Web-〉PRE-〉BP-〉擋板服務(wù)器（模擬后端服務(wù)方）。

3）系統(tǒng)特點(diǎn)：

用戶、賬號(hào)權(quán)限校驗(yàn)較多。

對(duì)公業(yè)務(wù)典型場(chǎng)景：經(jīng)辦、審核、查詢、下載、批量。用戶權(quán)限通過(guò)業(yè)務(wù)鏈控制。
接口調(diào)用較多，且由前端組合調(diào)用接口。

前后端分離，前端通過(guò)調(diào)用一個(gè)個(gè)接口來(lái)完成業(yè)務(wù)。接口粒度較細(xì)。登陸、支付轉(zhuǎn)賬經(jīng)辦需要15~19個(gè)接口完成一次交易。
強(qiáng)一致性、高可用性。

資金交易系統(tǒng)，一致性需要通過(guò)數(shù)據(jù)庫(kù)來(lái)保證。

4）網(wǎng)銀登錄壓測(cè)曲線

2、數(shù)據(jù)庫(kù)消息隊(duì)列案例（指令發(fā)送隊(duì)列）

需求是：對(duì)于需要異步處理的交易指令，需要設(shè)計(jì)一個(gè)基于數(shù)據(jù)庫(kù)的消息隊(duì)列，我們稱之為指令發(fā)送隊(duì)列。該隊(duì)列既要滿足服務(wù)器的性能約束，又要滿足每日處理交易量的要求。

1）優(yōu)化前處理過(guò)程

后臺(tái)任務(wù)每次從數(shù)據(jù)庫(kù)指令表中排序并取最早的一條指令，獲取該指令的詳細(xì)交易信息，組裝成報(bào)文并調(diào)用接口發(fā)送后臺(tái)核心系統(tǒng)。

在壓測(cè)環(huán)境下，該方案如果配置一個(gè)后臺(tái)任務(wù)，無(wú)法達(dá)到系統(tǒng)設(shè)計(jì)的指令處理速度；如果配置多個(gè)后臺(tái)任務(wù)，則會(huì)導(dǎo)致數(shù)據(jù)庫(kù)CPU占用較高，影響其他聯(lián)機(jī)業(yè)務(wù)的開展。

2）優(yōu)化后處理過(guò)程

每臺(tái)后臺(tái)任務(wù)服務(wù)器配置一個(gè)生產(chǎn)者任務(wù)，20個(gè)消費(fèi)者任務(wù)。

生產(chǎn)者任務(wù)一次取100個(gè)（可配置）指令，依次分配給20個(gè)消費(fèi)者任務(wù)中空閑的任務(wù)，消費(fèi)者任務(wù)獲取指令詳細(xì)信息，并組裝報(bào)文后發(fā)送后臺(tái)核心系統(tǒng)；生產(chǎn)者任務(wù)如果發(fā)現(xiàn)無(wú)空閑消費(fèi)者任務(wù)，則等待15s后重新判斷。

此方案顯著降低了數(shù)據(jù)庫(kù)CPU負(fù)載，合理利用了應(yīng)用服務(wù)器的并發(fā)能力，處理效率大為提高，以上線程數(shù)和每次獲取的指令數(shù)可以配置。

指令發(fā)送線程池模型圖：

3、數(shù)據(jù)庫(kù)死鎖案例

1）死鎖問(wèn)題現(xiàn)象

當(dāng)多臺(tái)任務(wù)服務(wù)器同時(shí)運(yùn)行大額指令發(fā)送后臺(tái)線程，即多個(gè)生產(chǎn)者線程并行更新數(shù)據(jù)庫(kù)指令表時(shí)，數(shù)據(jù)庫(kù)快照檢測(cè)到存在數(shù)據(jù)庫(kù)死鎖，或通過(guò)db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt 生成死鎖監(jiān)控文件，快照或監(jiān)控文件中存在deadlock的情況。

DB2數(shù)據(jù)庫(kù)有自動(dòng)解除死鎖功能，死鎖超時(shí)時(shí)間默認(rèn)為10s，數(shù)據(jù)庫(kù)會(huì)隨機(jī)選擇一個(gè)死鎖事務(wù)kill掉。本案例由于是后臺(tái)任務(wù)，所以用戶感覺不到死鎖；如果是聯(lián)機(jī)交易，一個(gè)用戶會(huì)發(fā)現(xiàn)交易失敗，另一個(gè)用戶交易成功，但是會(huì)感覺交易變慢。指令發(fā)送后臺(tái)任務(wù)模型詳見下一章節(jié)內(nèi)容。

2）數(shù)據(jù)庫(kù)死鎖發(fā)生原理

兩個(gè)不同的數(shù)據(jù)庫(kù)事務(wù)使用排它鎖鎖住了同一張表的不同行記錄，并且互相等待讀取對(duì)方鎖住的行記錄。

3）導(dǎo)致死鎖的可能原因

全表掃描、大事務(wù)、事務(wù)之間對(duì)死鎖訪問(wèn)順序交叉等。

4）死鎖問(wèn)題排查過(guò)程

Step1：分析數(shù)據(jù)庫(kù)快照和死鎖監(jiān)控日志，查看導(dǎo)致死鎖的SQL，定位問(wèn)題SQL。

Step2：問(wèn)題SQL不存在事務(wù)之間對(duì)死鎖訪問(wèn)順序交叉的情況，當(dāng)時(shí)尚不清楚程序中的全表掃描、大事務(wù)可能會(huì)導(dǎo)致死鎖，因此做了以下實(shí)驗(yàn)：

模擬問(wèn)題SQL在兩個(gè)不同的數(shù)據(jù)庫(kù)客戶端執(zhí)行SQL，查看數(shù)據(jù)是否更新成功。
完全按照源程序的SQL邏輯執(zhí)行驗(yàn)證：

UPDATE ( SELECT BP_SRVR_IP FROM ${tableName} WHERE TSK_STAT='TODO' AND ( BP_SRVR_IP IS OR BP_SRVR_IP='') AND PRTY =? AND eff_tm <= CURRENT TIMESTAMP FETCH FIRST 50 ROWS ONLY WITH RS) t SET BP_SRVR_IP=?

不加索引，A事務(wù)在R上加了X鎖，B事務(wù)無(wú)法在任何記錄上加X鎖，B事務(wù)會(huì)等待A事務(wù)提交后再加鎖。
增加索引，A事務(wù)在R記錄加了X鎖，B事務(wù)在S記錄加X鎖，互不沖突。

Step3：實(shí)驗(yàn)發(fā)現(xiàn)查詢SQL增加with RS隔離級(jí)別，查詢效率會(huì)更高。當(dāng)A事務(wù)已對(duì)記錄R加X鎖，B事務(wù)掃描到R記錄時(shí)，如果是CS隔離級(jí)別，B事務(wù)會(huì)自動(dòng)退出，返回空結(jié)果集；如果是RS隔離級(jí)別，B事務(wù)會(huì)等待A事務(wù)完成后，跳過(guò)R記錄，對(duì)符合條件的R+1記錄加X鎖。

Step4：PRTY字段增加索引，沒有出現(xiàn)死鎖問(wèn)題；或者不加索引，維持全表掃描不變，大事務(wù)改成小事務(wù)后，也沒有出現(xiàn)死鎖問(wèn)題。

5）兩點(diǎn)經(jīng)驗(yàn)

需要提前熟悉DB2鎖的種類和作用，隔離級(jí)別的種類和作用，表鎖和行鎖發(fā)生的條件。比如，全表掃描時(shí)，DB2會(huì)在整個(gè)表上加表級(jí)鎖；如果是增刪改操作，會(huì)加表級(jí)排他鎖。
在不清楚死鎖原因時(shí)，或者不了解鎖的機(jī)制和隔離級(jí)別機(jī)制時(shí)，不同隔離級(jí)別下SQL的影響范圍，可以在數(shù)據(jù)庫(kù)客戶端工具上進(jìn)行手工小實(shí)驗(yàn)，驗(yàn)證數(shù)據(jù)庫(kù)機(jī)制以及猜想。

七、后續(xù)提升網(wǎng)銀系統(tǒng)性能備選方法

1、增加緩存的使用