这周主要处理了MessageHandler项目和MongoDB的测试使用。
I. MessageHandler项目根据之前CEP项目的设计，适当分离了error信息所在的queue，分离了log信息所在的queue。
当前项目会针对click,event,postback的error，log独立使用queue和接收的process。这样会便于以后错误信息和日志信息的管理（Gems直接查看）。
注：周六晚上发现八点后的日志没有刷出来，原因是rename key后每十分钟刷日志的list没有被使用并删除，导致下一个十分钟renameex函数报错并且一直持续报错（因为该命令要求必须不存在rename完的key）。
受用redis-cli手动rename clickLogList_del后，每十分钟刷日志的定时器开始工作。
那么为何上述定时器失败了我们却没有收到邮件呢？这一直是让我迷惑不解的地方。
最后一直测试才发现所有的消息都被Get JMS Message给吃掉了，而且是有多少吃多少，甚至连邮件都不会发出来（因为它一直在那不结束）。
那么后续新架构中消息处理得好好考虑了，也许我们直接存在redis或者mongodb里而不是使用ems了。
II. MessageHandler项目基本完成。同时对比CEP项目优化了schema设计。这一点后续确认完全的schema时应当继续优化，以期存入mongodb的数据格式最优化，为后续管理和使用mongodb的日志打下良好基础。
RecordClick process需要完善下。
III. 学习，尝试运行了主要的Mongodb的函数，思考有哪些会帮助我们完成一个好的设计。比如$inc 增长一个值,$slice 类似于linux的head，tail命令，skip(),limit()分页，rename一个字段（考虑我们是否需要rename一个集合，比如redis当时刷小时日志），每天日志存储我们打算使用capped collection(性能好且已插入顺序为顺序) ---- 那么默认大小至少给15G ---- 3月15号的一天日志大小,希望它没用完的话会不占用没用到空间.
使用了mongodb官方的cloud mongo（mongo altas）服务，方便入手测试。
每天的点击日志，转化日志各作为一个capped集合。（点击日志按小时分貌似没什么意义，所以暂时不想了）
透传的时候直接使用mongodb的日志。先判断日期，然后找到对应按天的集合，把透传的字段名和值传进去，去日志中找内容。这一部分的优化比较重要。因为点击日志比较大而且使用capped集合，内部数据顺序是插入数据的时间戳。记日志和透传时最好使用时间戳作为标记，优化查询效率。
Capped Collection 具有以下特性，在使用的时候需要注意：
1 不可以对 Capped Collection 进行分片。
2 在 2.2 版本以后，创建的Capped Collection 默认在 _id 字段上创建索引，而在 2.2 版本或以前没有。
3 在 Capped Collection 插入文档后可以进行更新(update)操作，当更新不能导致原来文档占用
空间增长，否则更新失败。
4 不可以对 capped collection 执行删除文档操作，但可以删除整个集合。
IV. 剩下的内容就是把用到的项目好好精细化打磨，为测试做好准备。需要细化的地方包括mongodb的存取和查询，message项目对消息的处理----检查使用ems是否可行，不行则改成使用redis或者mongodb，然后就是联合检查CEP和MessageHandler项目，有些地方还需要讨论并最终确定下来，更新到文档。
