系統(tǒng)部署方案與優(yōu)化_第1頁
系統(tǒng)部署方案與優(yōu)化_第2頁
系統(tǒng)部署方案與優(yōu)化_第3頁
系統(tǒng)部署方案與優(yōu)化_第4頁
系統(tǒng)部署方案與優(yōu)化_第5頁
已閱讀5頁,還剩2頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

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

2、比較短。 圖中實線標識該為一個連接, 但該連接具有連接時間長 的特點,一般是系統(tǒng)起來后進行連接,系統(tǒng)主要注銷后關閉。其中步 驟 6 采用的連接池技術。從圖中可以看出目前主要的瓶頸分別內(nèi)存、 硬盤速度和大小、帶寬(目前較好) 。分別討論如下: 目前的內(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)存

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

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

5、elDB 是單進程的服務,性能非常之高,在一臺 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)存來進行加速。支付客戶端 1支付客戶端 N6、消息發(fā)送1、發(fā)送請求4、返回結果分離數(shù)據(jù)庫1分離數(shù)據(jù)庫2分離數(shù)據(jù)庫N分支系統(tǒng)本方案的優(yōu)點:性能上非常高, Redis-storage 非常適合該系統(tǒng)的特征,系統(tǒng)在單 量超高 10 億單后,依然能夠具有較

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論