項(xiàng)目當(dāng)時(shí)就我們5個(gè)人在做，可以說(shuō)這5個(gè)人都是百里挑一的人選，但我們需要面對(duì)以下挑戰(zhàn)：
1、雖然都是搞J2EE的老手，都沒(méi)有接觸過(guò)Push Mail這樣的國(guó)外項(xiàng)目，所以對(duì)業(yè)務(wù)的精髓不能完全吃透，導(dǎo)致理解需求比較吃力。
2、在3個(gè)月內(nèi)完成演示版本，證明業(yè)務(wù)可行性；9個(gè)月內(nèi)構(gòu)建完全產(chǎn)品化的系統(tǒng)。
3、系統(tǒng)需要支持大并發(fā)，海量數(shù)據(jù)，系統(tǒng)必須達(dá)到很高性能指標(biāo)。
4、提供7X24及時(shí)服務(wù)，在第一時(shí)間解決任何技術(shù)問(wèn)題。(有時(shí)差，客戶在睡覺(jué)我們?cè)诠ぷ鳎蛻粼诠ぷ?，我們不能睡覺(jué)還在工作。)
5、對(duì)J2EE以外的技術(shù)只有1-2人了解。比如：分布式計(jì)算、應(yīng)用服務(wù)器,數(shù)據(jù)庫(kù)集群技術(shù) 和 大型系統(tǒng)的數(shù)據(jù)、文件 存儲(chǔ)方案。
但是再我們所有成員的不斷努力下，這些困難都被我們一一解決。
項(xiàng)目里面牽涉打了J2EE 領(lǐng)域多項(xiàng)技術(shù)，也算是一個(gè)難點(diǎn)吧，因?yàn)橄铝屑夹g(shù)跨度都比較大，例如：
1、Servlet (協(xié)議請(qǐng)求、回送)
2、XML (協(xié)議解析)
3、JavaMail (郵件收發(fā))
4、EJB (分布式計(jì)算)
5、ibatis(數(shù)據(jù)庫(kù)操作)
6、JMS/MDB (采用分布架構(gòu)中的內(nèi)部通訊方式)
7、多線程和線程池 (多任務(wù)提取郵件)
8、還有很多 J2EE規(guī)范以外的技術(shù)， 例如：httpclient 網(wǎng)頁(yè)抓取、html 解析、Office附件處理、圖片壓縮 、加密/解密 等等。
這個(gè) Push Mail 項(xiàng)目留給我最深的影響就是給我們團(tuán)隊(duì)來(lái)了豐厚的利潤(rùn)，客戶他是一個(gè)美籍印度佬，就是我們常說(shuō)的那種有錢人，做事爽快、干脆，也是全球移動(dòng)領(lǐng)域具有影響的專家，因此他要求我們提供的服務(wù)必須是具有一個(gè)國(guó)際化專業(yè)水準(zhǔn)的團(tuán)隊(duì)(International Corporate)。所謂專業(yè)化的主要需要體現(xiàn)在 1執(zhí)行規(guī)范、2執(zhí)行效率、3執(zhí)行細(xì)節(jié) 這3個(gè)重要的環(huán)節(jié)上。
在項(xiàng)目實(shí)施過(guò)程中除了搞J2EE 的開發(fā)者， TA、QA 、SA、DBA 一個(gè)也不能少。
1、TA 小組根據(jù)制定的項(xiàng)目執(zhí)行規(guī)范監(jiān)管我們每個(gè)開發(fā)成員 在每個(gè)stage和里程碑的執(zhí)行力，從需求分析的文檔編寫規(guī)范一直到最后的項(xiàng)目交付，他們才算結(jié)束使命。
2、QA 測(cè)試團(tuán)隊(duì)在我們需求和概要設(shè)計(jì) 就開始對(duì)jboss和mysql其他幾項(xiàng)技術(shù)學(xué)習(xí)，其中測(cè)試人員與我們一同參與需求分析，這樣將來(lái)他們才知道該如何配合我們做各種測(cè)試，進(jìn)行深入的測(cè)試，而不是我們?cè)谝龑?dǎo)他們?cè)跍y(cè)試，他們100%能知曉業(yè)務(wù) 并且制定出不同的測(cè)試計(jì)劃。并不是依靠我們自己測(cè)試或者我們?cè)谥笇?dǎo)他們測(cè)試，那樣運(yùn)動(dòng)員和裁判員都是同一人，那樣肯定出問(wèn)題。
3、SA 的壓力最大 需要對(duì)系統(tǒng)整體的架構(gòu)進(jìn)行設(shè)計(jì)這個(gè)都是分內(nèi)的事情，更重要的 在真實(shí)生產(chǎn)的環(huán)境遇到致命性錯(cuò)誤，可以回退或者拿出現(xiàn)成的備份方案，把問(wèn)題在短時(shí)間內(nèi)化解。
4、DBA 需要從高往低的系統(tǒng)架構(gòu)層次進(jìn)行對(duì)數(shù)據(jù)庫(kù)設(shè)計(jì)與整體規(guī)劃，必須根據(jù)客戶需求設(shè)計(jì)出具有遠(yuǎn)景的 方案，不是一成不變，更不是所謂“一步到位”的規(guī)劃設(shè)計(jì)，是根據(jù)預(yù)計(jì)的數(shù)據(jù)增長(zhǎng) 進(jìn)行實(shí)施規(guī)劃的不同方案。
5、開發(fā)者們需要對(duì)每個(gè)業(yè)務(wù)模塊都要詳細(xì)了解。因?yàn)槲覀冃枰档惋L(fēng)險(xiǎn) 開發(fā)者們?nèi)绻霈F(xiàn)有人家里有事或者生病 任何一個(gè)成員都可以替代，不會(huì)出現(xiàn)我今天不來(lái)上班，導(dǎo)致項(xiàng)目進(jìn)度拖慢一天的現(xiàn)象。
在產(chǎn)品在設(shè)計(jì)開發(fā)到發(fā)布的過(guò)程中，我們分為四個(gè)階段 prototype、demo、stage、producting。
prototype 是一個(gè)原型，主要完成核心的部分，完成核心的功能和業(yè)務(wù)邏輯，開發(fā)團(tuán)隊(duì)內(nèi)部評(píng)估使用。
demo 階段是將產(chǎn)品的主要部分演示給客戶看，讓客戶確認(rèn)主體的方向。
stage 根據(jù)項(xiàng)目計(jì)劃分為多個(gè)不同的stage版本，每個(gè)stage階段的版本都會(huì)在stage服務(wù)器上由我們 測(cè)試人員先測(cè)試5-7天，再發(fā)布到真實(shí)的生產(chǎn)環(huán)境中?？蛻魧?duì)這樣的流程要求的非常的嚴(yán)格。因此 stage 服務(wù)器的配置和數(shù)量與 producting 環(huán)境是100%相同的，沒(méi)有他們的郵件確認(rèn)我們是不能擅自發(fā)布到 producting 環(huán)境中的，如果 producting 環(huán)境出現(xiàn)問(wèn)題，必須在短時(shí)間內(nèi)能回歸到上一個(gè)穩(wěn)定版本的狀態(tài) 。 后期會(huì)在 stage 和 producting 服務(wù)器上輪回 ，fix –> testing —> release。
我們當(dāng)時(shí)使用SVN和Trac，值得一提的是Trac這個(gè)東西，客戶有任何需求變更 通過(guò) Trac 系統(tǒng) TA，QA，DBA，SA 統(tǒng)統(tǒng)都會(huì)知道，并且知道我們會(huì)在下個(gè)版本 什么時(shí)候 會(huì) 發(fā)布在stage 服務(wù)器上，我們也能在第一時(shí)間知道他們對(duì) 當(dāng)前版本的 性能情況，客戶也能看見但似乎他們并不在意這個(gè)結(jié)果，因?yàn)樗麄冃枰牢覀儺?dāng)前的執(zhí)行狀態(tài)是否符合計(jì)劃，其實(shí)TA的成員比他們更加關(guān)注我們的項(xiàng)目進(jìn)度，呵呵。因此，所有人的開發(fā)進(jìn)度執(zhí)行情況都在trac上進(jìn)行展現(xiàn)。客戶也可以看見，也可以回復(fù)，所有信息所有人同步。
呵呵，另外那三十幾臺(tái)需要發(fā)布應(yīng)用程序的機(jī)器，分別發(fā)布不同的應(yīng)用程序或者不同的版本不可能完全依靠人工完成，我們需要一個(gè)半自動(dòng)化的工具幫助我們完成，所以我們選擇了hudson和自己編寫的liunx腳本。這樣可以提供效率，并且大大減少了發(fā)布時(shí)出錯(cuò)的機(jī)率。
先寫這么多，有什么忘記的地方我回頭補(bǔ)上，下一篇將開始 講述 純 技術(shù)方面的那點(diǎn)事兒了。
通過(guò)這個(gè)項(xiàng)目讓我們充分的認(rèn)識(shí)到一個(gè)用戶的系統(tǒng) 例如：?jiǎn)斡脩舻?OutLook 和 一個(gè)百萬(wàn)級(jí)的系統(tǒng)的是截然不同的，系統(tǒng)中僅有100條數(shù)據(jù)和100w條數(shù)據(jù)的系統(tǒng)更是截然不同的，從100w條數(shù)據(jù)上升到上億條數(shù)據(jù)那樣的系統(tǒng)更會(huì)讓人感受到無(wú)論從代碼結(jié)構(gòu)、數(shù)據(jù)庫(kù)設(shè)計(jì)還是從系統(tǒng)架構(gòu)都是完全不同的設(shè)計(jì)。
客戶端環(huán)境
MKT SDK
C 語(yǔ)言開發(fā)環(huán)境
服務(wù)器端環(huán)境
Apache2 Web服務(wù)器
mod_proxy Web負(fù)載均衡模塊
HAProxy 前端、數(shù)據(jù)庫(kù)負(fù)載分載(后期使用)
Java EE1.5 語(yǔ)言開發(fā)環(huán)境
Jboss 4.0.5 GA 應(yīng)用服務(wù)器
Jboss MQ JMS服務(wù)器
MySQL 5.1.4 數(shù)據(jù)庫(kù)服務(wù)器
EJB 3.0 Java 開發(fā)API 工具
iBATIS Java 開發(fā)API 工具
OsCache 緩存組件
Gluster DFS 分布式文件系統(tǒng)
Nagios 系統(tǒng)監(jiān)控、報(bào)警工具
Qmail 1臺(tái)發(fā)送郵件服務(wù)器
壓力測(cè)試工具
Apache Jemter
Apache AB
當(dāng)前運(yùn)行狀態(tài)
每月大約有4000多新注冊(cè)用戶
當(dāng)前注冊(cè)大約用戶數(shù)量200-300w
每天大約有90-110w用戶登錄
每天大約接收500-700W 封郵件
每天大約接收附件3-5G，超過(guò)5M以上的附件將不接受
每天數(shù)據(jù)庫(kù)增加 2W條記錄
每天數(shù)據(jù)庫(kù)接受 700W 次請(qǐng)求
每秒并發(fā)最大18000個(gè)請(qǐng)求
整體架構(gòu)
概覽
總體上概括，系統(tǒng)分為 1客戶端，2服務(wù)器端，3SP Mail Server 端，4 CRM 端 下面將講述整個(gè)系統(tǒng)的概況。
后端發(fā)送郵件實(shí)現(xiàn)過(guò)程
1.手機(jī)客戶端通過(guò)http網(wǎng)絡(luò)協(xié)議發(fā)送XML數(shù)據(jù)到服務(wù)器端，
2.服務(wù)器端接收到xml數(shù)據(jù)進(jìn)行解析，服務(wù)器端傳輸層的web請(qǐng)求模塊將xml 協(xié)議解析，并且重新包裝成pojo 對(duì)象，
3.中間有一個(gè)業(yè)務(wù)模塊分發(fā)器將 獲得pojo對(duì)象交給不同的業(yè)務(wù)模塊進(jìn)行處理，如：DAL層、消息中間件，
4.將處理完成的業(yè)務(wù)通過(guò)業(yè)務(wù)模塊分發(fā)器包裝成xml報(bào)文回送給客戶端。
整個(gè)業(yè)務(wù)處理組成部分如圖所示：
內(nèi)部業(yè)務(wù)邏輯
1.定時(shí)器從數(shù)據(jù)庫(kù)裝載帳戶，采用多線程實(shí)現(xiàn)一個(gè)線程池，我們稱這個(gè)玩意兒叫做任務(wù)工廠，
2.定時(shí)向JMS服務(wù)器中不同的消息隊(duì)列發(fā)送消息 ，消息接收端收到消息后驅(qū)動(dòng)業(yè)務(wù)模塊去 SP Mail Server 收取郵件，
3.收郵件模塊 上SP Mail Server 獲取郵件列表頭信息，并且和數(shù)據(jù)庫(kù)中已存在的郵件列表頭信息進(jìn)行新郵件比對(duì)，
4.收取新郵件并且將郵件信息保存到數(shù)據(jù)庫(kù)或者緩存，當(dāng)用戶需要讀取的時(shí)候?qū)南到y(tǒng)的數(shù)據(jù)庫(kù)或者緩存中讀取，
5.保存完畢后，將通過(guò)IP Push 或者 SMS Push 技術(shù) 通知用戶上服務(wù)器獲得新郵件。
后端內(nèi)部架構(gòu)
Web層
用戶的所有請(qǐng)求都是從web層進(jìn)入，最上層是apache將請(qǐng)求分載到每臺(tái)AP 服務(wù)器 Jboss的web容器上，web容器請(qǐng)求處理用戶提交的各種xml請(qǐng)求協(xié)議，并且回送處理結(jié)果xml協(xié)議給客戶端，apache經(jīng)過(guò)幾次優(yōu)化并且開了20個(gè)進(jìn)程處理用戶所有請(qǐng)求分發(fā)，另一臺(tái)apache standby 通過(guò) heartbeat做備份，如果apache server1失效 將會(huì)自動(dòng)轉(zhuǎn)移到 apach server2上去。在項(xiàng)目后期我們采用HaProxy來(lái)替代了Apache的轉(zhuǎn)發(fā)工作，也許2者進(jìn)行優(yōu)化后的功效相差不了多少，但是我們認(rèn)為HaProxy安裝、移植、部署 比Apache更加方便，最高可以處理2.7W的并發(fā)請(qǐng)求處理，并且可以采用leastconn 負(fù)載均衡算法，將當(dāng)前連接請(qǐng)求數(shù)量最小的服務(wù)器進(jìn)行命中。
任務(wù)調(diào)度
檢測(cè)用戶的新郵件功能依賴系統(tǒng)中的任務(wù)調(diào)度模塊，我們管這個(gè)模塊叫做任務(wù)工廠，他先從數(shù)據(jù)庫(kù)中裝載賬戶，再放入緩存中，每3分鐘裝載所有賬戶一次，向JMS服務(wù)器發(fā)送消息請(qǐng)求新郵件檢查。
從緩存中讀取是為了降低數(shù)據(jù)庫(kù)的壓力， 因?yàn)檫@樣的操作太頻繁了而且數(shù)據(jù)量越來(lái)越大，會(huì)導(dǎo)致數(shù)據(jù)的壓力增大。任務(wù)工廠是系統(tǒng)中非常重要的模組，如果任務(wù)工廠停止工作將不能檢測(cè)到所有用戶的新郵件， 整個(gè)Push Mail系統(tǒng)將會(huì)癱瘓，所以必須能支持壓力分載和失效轉(zhuǎn)發(fā)的功能。
BTW：任務(wù)工廠模塊最開始在demo的時(shí)候采用Quartz 放入Spring微容器中進(jìn)行集群，因?yàn)椴荒軓木彺嬷兄苯幼x取，將來(lái)系統(tǒng)賬戶會(huì)越來(lái)越多，導(dǎo)致數(shù)據(jù)庫(kù)那邊的壓力越來(lái)越大，所以后期我們用 線程池+oscache集群技術(shù) 自己開發(fā)了一套類似 Quartz+spring集群的方案。另外，這個(gè)項(xiàng)目發(fā)生在沒(méi)有Memcached的年代，如果當(dāng)時(shí)使用Memcached也許設(shè)計(jì)上會(huì)更加完美些。
分布式應(yīng)用
國(guó)外用戶使用郵箱賬號(hào)多數(shù)都是以 Gmail、AOL、Hotmail、Yahoo 4大郵箱為主，所以我們將處理郵件具體操作的機(jī)器分為4組，每組機(jī)器處理具體不同的郵箱賬號(hào)的郵件存取，將整個(gè)業(yè)務(wù)中負(fù)荷最大的部分進(jìn)行分散，獨(dú)立計(jì)算, 每組中的服務(wù)器都支持 失效轉(zhuǎn)發(fā)和壓力分載。
EJB消息驅(qū)動(dòng)Bean /JMS 消息系統(tǒng)
系統(tǒng)多線程的定時(shí)器，將系統(tǒng)中所有用戶賬號(hào)裝載后由多個(gè)JMS發(fā)送端發(fā)送Queue消息到不同的消息隊(duì)列，例如：Gmail消息隊(duì)列、AOL消息隊(duì)列、Hotmail消息隊(duì)列、Yahoo消息隊(duì)列，然后接收端將接收不同的消息隊(duì)列發(fā)送過(guò)來(lái)的消息，通常我們每組消息隊(duì)列使用一個(gè)發(fā)送端對(duì)應(yīng)多個(gè)接收端，每組接收端，例如：接收到一批Yahoo賬號(hào)的JMS消息，將會(huì)由多個(gè)接收端，例如：接收到一批Yahoo賬號(hào)的JMS消息，接收端將通過(guò)消息分發(fā)給不同的計(jì)算機(jī)組，JMS服務(wù)器端采用集群技術(shù)，2臺(tái)JMS服務(wù)器上建有4個(gè)消息隊(duì)列，不僅可以進(jìn)行壓力分載，還可以進(jìn)行失效轉(zhuǎn)發(fā)。將4大郵箱分為4個(gè)業(yè)務(wù)群組，每分組各4臺(tái)消息接收端，一共16臺(tái)，加上JMS MOM 消息中間件服務(wù)器一共18臺(tái)，在得到上層模組傳送過(guò)來(lái)的指令后，16臺(tái)專門進(jìn)行用戶郵件解析、發(fā)送的操作。
數(shù)據(jù)庫(kù)
8臺(tái) 16 GB內(nèi)存 、4個(gè)CPU 的機(jī)器作為 我們使用的MySQL數(shù)據(jù)庫(kù)，每臺(tái)MySQL數(shù)據(jù)庫(kù)都安裝了XtraDB MySQL插件，主要提高M(jìn)ySQL innodb引擎的讀寫性能，對(duì)于MySQL的整體性能我們主要還是通過(guò)調(diào)整MySQL的內(nèi)部參數(shù)來(lái)進(jìn)行優(yōu)化。MySQL原本算使用 NDB引擎來(lái)做數(shù)據(jù)同步和單點(diǎn)失效的，經(jīng)過(guò)實(shí)際情況我們反復(fù)比對(duì)還是使用傳統(tǒng)MySQL數(shù)據(jù)同步來(lái)完成我們預(yù)想的效果，因?yàn)镸ySQL的集群在我們當(dāng)時(shí)還不算很成熟，而且這玩兒比較消耗內(nèi)存。
分片(sharding)
每個(gè)用戶的請(qǐng)求都包含一個(gè)用戶的ID，我們將判斷不同的用戶ID到不同的數(shù)據(jù)上進(jìn)行操作，當(dāng)然我們也不是每張表都做拆分，由于用戶越來(lái)越多我們只把郵件相關(guān)的表進(jìn)行拆分，例如：郵件列表、郵件內(nèi)容、郵件附件表 3張表近拆分。每張表中都有用戶ID這個(gè)字段，DAL層根據(jù)用戶 ID 進(jìn)行判斷 數(shù)據(jù)的路由規(guī)則到具體對(duì)應(yīng)范圍的數(shù)據(jù)庫(kù)進(jìn)行存取數(shù)據(jù)，比如ID在1-10000之間的用戶對(duì)應(yīng)到數(shù)據(jù)庫(kù)1， ID在10001-20000范圍對(duì)應(yīng)到數(shù)據(jù)庫(kù)2，以此類推,但是不能在不停機(jī)的狀態(tài)下動(dòng)態(tài)添加數(shù)據(jù)庫(kù)服務(wù)器節(jié)點(diǎn)，后來(lái)我們想了一個(gè)辦法，添加節(jié)點(diǎn)的時(shí)候通過(guò)JMS消息通知每個(gè)機(jī)器上的DAL層重新讀取數(shù)據(jù)路由配置一次，系統(tǒng)中的數(shù)據(jù)需要和系統(tǒng)中的CRM系統(tǒng)相結(jié)合，后期我們又建立了一個(gè)全局?jǐn)?shù)據(jù)庫(kù)(global)，這個(gè)全局?jǐn)?shù)據(jù)庫(kù)只作為數(shù)據(jù)索引，為了將所有數(shù)據(jù)同步，操作所有數(shù)據(jù)庫(kù)的記錄通過(guò)JMS消息定時(shí)向全局?jǐn)?shù)據(jù)庫(kù)(global)進(jìn)行批量操作，如果每筆執(zhí)行同步操作，將會(huì)降低系統(tǒng)性能。
分布式文件系統(tǒng)(DFS)
用戶郵件的所以郵件附件都保存在 分布文件系統(tǒng) 前期我們采用Gluster，后期我們采用了MooseFs搭建 使用分布式文件系統(tǒng)是為了能滿足我們2點(diǎn)需求 1、由于系統(tǒng)用戶不斷的增多，導(dǎo)致我們需要保存的郵件附件不斷增長(zhǎng)，我們需要可以做到當(dāng)磁盤容量不足時(shí)在不停機(jī)的情況下無(wú)限的添加存儲(chǔ)的容量，并且操作方便。2、對(duì)于保存的數(shù)據(jù)可以實(shí)時(shí)同步，防止單點(diǎn)失效，數(shù)據(jù)丟失。
JavaMail
我們將Sun JavaMail 的源代碼進(jìn)行改寫，提高收郵件的效率，這樣我們?cè)诖a中向POP3郵件服務(wù)器發(fā)送一個(gè)命令，立刻在瞬間可以獲得上千份郵件的MessageID的頭信息。可參見 《修改源碼提高JavaMail比較新郵件效率》一文中提到的具體技術(shù)。發(fā)送郵件采用的是Apache 的 Commons email來(lái)簡(jiǎn)化發(fā)送郵件的操作。
經(jīng)驗(yàn)與教訓(xùn)
1.HAProxy的擴(kuò)展使用，不僅僅可以使用在Web方面，還可以使用到其他應(yīng)用層，進(jìn)行壓力分鐘， 例如，可以應(yīng)用到 數(shù)據(jù)MySQL?？梢詤⒖歼@篇文章，http://www.alexwilliams.ca/blog/2009/08/10/using-haproxy-for-mysql-failover-and-redundancy
2.JVM的優(yōu)化是任何大型J2EE項(xiàng)目中必不可少的話題，當(dāng)然并不是你把JVM的內(nèi)存使用空間設(shè)置的越大越好，SUN的官方網(wǎng)站已經(jīng)指出，不同的操作系統(tǒng)，不同的應(yīng)用，建議你的JVM內(nèi)存分配大小是不同的。另外，對(duì)與不同的JVM也有不同的參數(shù)配置，通常的JVM配置參數(shù)可以參見這里，http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
3.Linux系統(tǒng)上的swap 空間，4G和4G內(nèi)存 以內(nèi)的機(jī)器還是非常有必要使用swap空間的，有一次有一個(gè)應(yīng)用服務(wù)器系統(tǒng)down機(jī)，花了很久的時(shí)間才發(fā)現(xiàn)，居然是忘記建立Swap空間，多么簡(jiǎn)單的問(wèn)題啊，可是把我們折磨了3個(gè)星期，3個(gè)星期里被老板和客戶罵的慘不忍睹，血的教訓(xùn)，讓我們?cè)僖膊粫?huì)忘記小內(nèi)存機(jī)器建立swap空間了。
4.Jboss MQ的抱怨，首先聲明我不是在給Apache 的JMS做廣告，因?yàn)镴bossMQ實(shí)在是不好用，而且性能也不咋地，我看見有一篇文章說(shuō)到JbossMQ的性能在同類產(chǎn)品中是最好的，不知道結(jié)果是怎么來(lái)的，還是建議大家還是使用Apache的JMS，文檔全面啊，不懂就可以找到很全面的資料，jboss MQ 資料的支持不多。
5.MySQL的優(yōu)化，MySQL的一些參數(shù)調(diào)優(yōu)就不說(shuō)了，但使用MySQL 插件以后給我們帶來(lái)了不少性能上的提升，特別是在數(shù)據(jù)查詢上的瓶頸可以得到不少緩解。
6.MySQL集群，這玩意兒是個(gè)不錯(cuò)的解決方案，可是沒(méi)有足夠的內(nèi)存是玩不起的，因?yàn)镸ySQL的集群因?yàn)橥耆蕾噧?nèi)存，另外對(duì)表的字段也有特別的限制，用起來(lái)有點(diǎn)不太自然，不支持所有大字段的類型。如果是老系統(tǒng)遷移過(guò)來(lái)，估計(jì)要折騰一段時(shí)間才能合用。
7.JMS 消息的使用，不需要放入數(shù)據(jù)庫(kù)，將消息內(nèi)存當(dāng)中，并且對(duì)JVM運(yùn)行參數(shù)進(jìn)行優(yōu)化 ，對(duì)與客戶端的代碼也需要進(jìn)行優(yōu)化，關(guān)閉消息id (setDisableMessageID),減少消息的大小并且 省去了創(chuàng)建唯一ID的時(shí)間。關(guān)閉消息的時(shí)間戳。如果不需要時(shí)間戳，用MessageProducer的setDisableMessageTimeStamp()方法將其關(guān)閉。避免使用AUTO_ACKNOWLEDGE。 AUTO_ACKNOWLEDGE 使得每收到一個(gè)消息就要向服務(wù)器發(fā)送一個(gè)通知－－這樣增加的網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)。如果可能，盡量使用 DUPS_OK_ACKNOWLEDGE或者CLIENT_ACKNOWLEDGE?；蛘呤褂檬聞?wù)性會(huì)話，將通知在提交時(shí)批量完成。
聯(lián)系客服
