這周主要處理了MessageHandler項目和MongoDB的測試使用。
I. MessageHandler項目根據(jù)之前CEP項目的設(shè)計郑气，適當(dāng)分離了error信息所在的queue听系，分離了log信息所在的queue。
當(dāng)前項目會針對click,event,postback的error成玫，log獨立使用queue和接收的process骇两。這樣會便于以后錯誤信息和日志信息的管理（Gems直接查看）速种。
注：周六晚上發(fā)現(xiàn)八點后的日志沒有刷出來，原因是rename key后每十分鐘刷日志的list沒有被使用并刪除低千，導(dǎo)致下一個十分鐘renameex函數(shù)報錯并且一直持續(xù)報錯（因為該命令要求必須不存在rename完的key）配阵。
受用redis-cli手動rename clickLogList_del后，每十分鐘刷日志的定時器開始工作示血。
那么為何上述定時器失敗了我們卻沒有收到郵件呢闸餐？這一直是讓我迷惑不解的地方。
最后一直測試才發(fā)現(xiàn)所有的消息都被Get JMS Message給吃掉了矾芙，而且是有多少吃多少舍沙，甚至連郵件都不會發(fā)出來（因為它一直在那不結(jié)束）。
那么后續(xù)新架構(gòu)中消息處理得好好考慮了剔宪，也許我們直接存在redis或者mongodb里而不是使用ems了拂铡。
II. MessageHandler項目基本完成。同時對比CEP項目優(yōu)化了schema設(shè)計葱绒。這一點后續(xù)確認(rèn)完全的schema時應(yīng)當(dāng)繼續(xù)優(yōu)化感帅，以期存入mongodb的數(shù)據(jù)格式最優(yōu)化，為后續(xù)管理和使用mongodb的日志打下良好基礎(chǔ)地淀。
RecordClick process需要完善下失球。
III. 學(xué)習(xí)，嘗試運行了主要的Mongodb的函數(shù)帮毁，思考有哪些會幫助我們完成一個好的設(shè)計实苞。比如$inc 增長一個值,$slice 類似于linux的head，tail命令烈疚，skip(),limit()分頁黔牵，rename一個字段（考慮我們是否需要rename一個集合，比如redis當(dāng)時刷小時日志）爷肝，每天日志存儲我們打算使用capped collection(性能好且已插入順序為順序) ---- 那么默認(rèn)大小至少給15G ---- 3月15號的一天日志大小,希望它沒用完的話會不占用沒用到空間.
使用了mongodb官方的cloud mongo（mongo altas）服務(wù)猾浦，方便入手測試陆错。
每天的點擊日志，轉(zhuǎn)化日志各作為一個capped集合金赦。（點擊日志按小時分貌似沒什么意義音瓷，所以暫時不想了）
透傳的時候直接使用mongodb的日志。先判斷日期夹抗，然后找到對應(yīng)按天的集合绳慎，把透傳的字段名和值傳進去，去日志中找內(nèi)容兔朦。這一部分的優(yōu)化比較重要偷线。因為點擊日志比較大而且使用capped集合磨确，內(nèi)部數(shù)據(jù)順序是插入數(shù)據(jù)的時間戳沽甥。記日志和透傳時最好使用時間戳作為標(biāo)記，優(yōu)化查詢效率乏奥。
Capped Collection 具有以下特性摆舟，在使用的時候需要注意：
1 不可以對 Capped Collection 進行分片。
2 在 2.2 版本以后邓了，創(chuàng)建的Capped Collection 默認(rèn)在 _id 字段上創(chuàng)建索引恨诱，而在 2.2 版本或以前沒有。
3 在 Capped Collection 插入文檔后可以進行更新(update)操作骗炉，當(dāng)更新不能導(dǎo)致原來文檔占用
空間增長照宝，否則更新失敗。
4 不可以對 capped collection 執(zhí)行刪除文檔操作句葵，但可以刪除整個集合厕鹃。
IV. 剩下的內(nèi)容就是把用到的項目好好精細(xì)化打磨，為測試做好準(zhǔn)備乍丈。需要細(xì)化的地方包括mongodb的存取和查詢剂碴，message項目對消息的處理----檢查使用ems是否可行，不行則改成使用redis或者mongodb轻专，然后就是聯(lián)合檢查CEP和MessageHandler項目忆矛，有些地方還需要討論并最終確定下來，更新到文檔请垛。
