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

1、系統(tǒng)部署方案與優(yōu)化方案背景：目前部署在阿里云上的系統(tǒng)存在內(nèi)存不夠用，不定期的應用假死問題。為了解決這些問題并能夠很好的對系統(tǒng)的擴展性和可用性進行配置。系統(tǒng)需要進行部署改造。為此提出改造方案。目前的通訊過程主要有2中構成，分別如下表：序號通訊路徑備注1 生成訂單、主動查詢、退款、取消訂單2 付款通知詳細的通訊過程如下圖：圖：通訊過程其中通訊虛線標識是一次連接，但該連接為用完即關閉，特點為連接時間比較短。圖中實線標識該為一個連接，但該連接具有連接時間長的特點，一般是系統(tǒng)起來后進行連接，系統(tǒng)主要注銷后關閉。其中步驟6采用的連接池技術。從圖中可以看出目前主要的瓶頸分別內(nèi)存、硬盤速度和大小、帶寬（目前較

2、好）。分別討論如下：目前的內(nèi)存的主要消耗對象為：內(nèi)存消耗對象分析序號系統(tǒng)主要對象建議內(nèi)存1Tomcat應用服務器目前沒有使用緩存技術，主要是線程占用數(shù)和連接數(shù)占用相關的內(nèi)存4G2ActiveX消息服務器主要是連接數(shù)和消息的存儲（自帶數(shù)據(jù)庫存儲引擎）4G3Mysql查詢緩存4G4操作系統(tǒng)進程管理、調(diào)度10%4預留應急和升級20%結論：建議采用16G內(nèi)存。因虛擬機內(nèi)存可以調(diào)整，在開始階段可以采用8G的內(nèi)存（節(jié)省開支），支撐的數(shù)量高了調(diào)整為16G.關于CPU,建議4核心CPU及以上。主要用來給Mysql、java使用。數(shù)據(jù)量來后，可以將mysql單獨部署到獨立的虛機上。如果部署mysql，建議硬盤1

3、00G。不部署mysql50G即可。本部署方案為遷移的方案，為計算優(yōu)化需要的各個參數(shù)。優(yōu)化方案系統(tǒng)的特點：數(shù)據(jù)增長量非?？欤⑶矣性谝欢〞r間段比較集中的特點。但是查詢的量是比較少的，所有的操作基本上是以32位的訂單編號進行查詢和修改。下圖為系統(tǒng)運行一段時間的后數(shù)據(jù)的冷熱程度，橫軸為總量。系統(tǒng)中經(jīng)常操作的數(shù)據(jù)往往最新添加的數(shù)據(jù)從比例上可以看出占到的數(shù)據(jù)量是比較小的。不建議采用分庫分表的方案，建議采用noSql中的redis技術和mysql共同處理。其中Redis采用redis-storage技術，可以實現(xiàn)數(shù)據(jù)的快速訪問。redis-storage采用google的Leveldb存儲引擎，以下為L

4、eveldb的相關情況： Leveldb是一個google實現(xiàn)的非常高效的kv數(shù)據(jù)庫，目前的版本1.2能夠支持十億級別的數(shù)據(jù)量了。 在這個數(shù)量級別下還有著非常高的性能，主要歸功于它的良好的設計。特別是LSM算法。LevelDB 是單進程的服務，性能非常之高，在一臺4個Q6600的CPU機器上，每秒鐘寫數(shù)據(jù)超過40w，而隨機讀的性能每秒鐘超過10w。實際使用情況：目前了解到國內(nèi)某快遞公司的核心骨干系統(tǒng)采用redis-storage進行查詢和存儲，日均處理單量大于500萬（均為不同的單號，平均600萬），自上線后，運行較為穩(wěn)定（1年左右，總單量超過20億條）。建議采用Redis-storage技術，同時結合mysql做支付數(shù)據(jù)的離線分析和備份。更改的結果為如下圖，即增加一個Redis-stroage的nosql數(shù)據(jù)庫。利用內(nèi)存來進行加速。本方案的優(yōu)點：性能上非常高，Redis-storage非常適合該系統(tǒng)的特征，系統(tǒng)在單量超高10億單后，依然能夠具有較好的性能。工程上的好處