系統(tǒng)部署方案與優(yōu)化

1、系統(tǒng)部署方案與優(yōu)化方案背景：目前部署在阿里云上的系統(tǒng)存在內(nèi)存不夠用，不定期的應(yīng)用假死 問(wèn)題。為了解決這些問(wèn)題并能夠很好的對(duì)系統(tǒng)的擴(kuò)展性和可用性進(jìn)行 配置。系統(tǒng)需要進(jìn)行部署改造。為此提出改造方案。支付客戶端 1支付客戶端 N1、發(fā)送請(qǐng)求4、返回結(jié)果支付網(wǎng)關(guān)2、處理后發(fā)送3、處理后返回5、異步回調(diào)圖：通訊過(guò)程Tomcat應(yīng)用6、發(fā)送ActiveMQ消息服務(wù)器回調(diào)消息服務(wù)器數(shù)據(jù)庫(kù)7、消息發(fā)送其中通訊虛線標(biāo)識(shí)是一次連接， 但該連接為用完即關(guān)閉， 特點(diǎn)為連接目前的通訊過(guò)程主要有 2 中構(gòu)成，分別如下表：序號(hào)通訊路徑備注11234生成訂單、主動(dòng)查詢、退款、取消訂單2567付款通知詳細(xì)的通訊過(guò)程如下圖：時(shí)間

2、比較短。 圖中實(shí)線標(biāo)識(shí)該為一個(gè)連接， 但該連接具有連接時(shí)間長(zhǎng) 的特點(diǎn)，一般是系統(tǒng)起來(lái)后進(jìn)行連接，系統(tǒng)主要注銷后關(guān)閉。其中步 驟 6 采用的連接池技術(shù)。從圖中可以看出目前主要的瓶頸分別內(nèi)存、 硬盤(pán)速度和大小、帶寬（目前較好） 。分別討論如下： 目前的內(nèi)存的主要消耗對(duì)象為：內(nèi)存消耗對(duì)象分析序號(hào)系統(tǒng)主要對(duì)象建議內(nèi)存1Tomcat 應(yīng)用服 務(wù)器目前沒(méi)有使用緩存技術(shù)，主要是線程占用數(shù)和連接數(shù)占用相關(guān)的內(nèi)存4G2ActiveX 消息服 務(wù)器主要是連接數(shù)和消息的存儲(chǔ)（自帶數(shù)據(jù)庫(kù)存儲(chǔ)引擎）4G3Mysql查詢緩存4G4操作系統(tǒng)進(jìn)程管理、調(diào)度10%4預(yù)留應(yīng)急和升級(jí)20%結(jié)論：建議采用 16G 內(nèi)存。因虛擬機(jī)內(nèi)存

3、可以調(diào)整，在開(kāi)始階段可 以采用 8G 的內(nèi)存（節(jié)省開(kāi)支），支撐的數(shù)量高了調(diào)整為 16G. 關(guān)于 CPU,建議 4 核心 CPU 及以上。主要用來(lái)給 Mysql、java 使用 數(shù)據(jù)量來(lái)后，可以將 mysql 單獨(dú)部署到獨(dú)立的虛機(jī)上。 如果部署 mysql，建議硬盤(pán) 100G。不部署 mysql50G 即可。 本部署方案為遷移的方案，為計(jì)算優(yōu)化需要的各個(gè)參數(shù)。優(yōu)化方案系統(tǒng)的特點(diǎn)：數(shù)據(jù)增長(zhǎng)量非?？?，并且有在一定時(shí)間段比較集中 的特點(diǎn)。但是查詢的量是比較少的，所有的操作基本上是以 32 位的 訂單編號(hào)進(jìn)行查詢和修改。 下圖為系統(tǒng)運(yùn)行一段時(shí)間的后數(shù)據(jù)的冷熱程度， 橫軸為總量。 系統(tǒng)中 經(jīng)常操作的數(shù)據(jù)往

4、往最新添加的數(shù)據(jù)從比例上可以看出占到的數(shù)據(jù) 量是比較小的。類似預(yù)授權(quán)的退款操作 熱點(diǎn)數(shù)據(jù) 不建議采用分庫(kù)分表的方案， 建議采用 noSql 中的 redis 技術(shù)和 mysql 共同處理。其中 Redis 采用 redis-storage技術(shù)，可以實(shí)現(xiàn)數(shù)據(jù)的快速 訪問(wèn)。redis-storage采用 google的 Leveldb 存儲(chǔ)引擎，以下為 Leveldb 的相關(guān)情況： Leveldb 是一個(gè) google 實(shí)現(xiàn)的非常高效的 kv 數(shù)據(jù)庫(kù)， 目前的版本 1.2 能夠支持十億級(jí)別的數(shù)據(jù)量了。 在這個(gè)數(shù)量級(jí)別下 還有著非常高的性能，主要?dú)w功于它的良好的設(shè)計(jì)。特別是 LSM 算 法。 Lev

5、elDB 是單進(jìn)程的服務(wù)，性能非常之高，在一臺(tái) 4 個(gè) Q6600 的 CPU 機(jī)器上，每秒鐘寫(xiě)數(shù)據(jù)超過(guò) 40w，而隨機(jī)讀的性能每秒鐘超 過(guò) 10w 。 實(shí)際使用情況：目前了解到國(guó)內(nèi)某快遞公司的核心骨干系統(tǒng)采用 redis-storage 進(jìn)行查詢和存儲(chǔ)，日均處理單量大于 500 萬(wàn)（均為不同 的單號(hào)，平均 600 萬(wàn)），自上線后，運(yùn)行較為穩(wěn)定（ 1 年左右，總單量超過(guò) 20 億條）。建議采用 Redis-storage技術(shù)，同時(shí)結(jié)合 mysql 做支付數(shù)據(jù)的離線分析 和備份。更改的結(jié)果為如下圖，即增加一個(gè) Redis-stroage的 nosql 數(shù)據(jù)庫(kù)。利 用內(nèi)存來(lái)進(jìn)行加速。支付客戶端 1支付客戶端 N6、消息發(fā)送1、發(fā)送請(qǐng)求4、返回結(jié)果分離數(shù)據(jù)庫(kù)1分離數(shù)據(jù)庫(kù)2分離數(shù)據(jù)庫(kù)N分支系統(tǒng)本方案的優(yōu)點(diǎn)：性能上非常高， Redis-storage 非常適合該系統(tǒng)的特征，系統(tǒng)在單 量超高 10 億單后，依然能夠具有較