关键点设计.docxVIP

关键点设计数据字典1.1用户行为采用日志文件存储，后续采用统一日志分析工具进行统计和展示。所有行为日志由统计模块采用log4j本地存储。日志文件采用大小加日期滚动产生：即用户每天产生一批日志文件，当大小达到1G时再滚动产生新的文件。日志每天凌晨3点定时清理并入库。命名规则如下：active_年月日.log，例如：activelog。日志格式如下：create_ime#imei#net_type#device_type#wifi_mac#residence#partnerId#uid#appid#active_type#active_time，各字段说明如下：字段名称字段类型default必填字段说明imeiVARCHAR(32)Y机器imeipartnerIdVARCHAR(32)Y商户idnet_TypeTINYINTY联网属性，wifi还是联通3gdevice_typeY机型wifi_macVARCHAR(32)NWifi mac地址residenceVARCHAR (255)N小区信息uidVARCHAR(32)Y用户idappidVARCHAR(32)Y应用idactive_typeTINYINTY活动类型:1：点击游戏（游戏启动次数）2：点击登录（登录请求次数）3：登录成功（登录成功次数）4：登录失败（登录失败次数）5：点击取消登录（取消登录次数）6：点击退出登录（退出登录次数）7：点击购买，创建订单（扣费数）8：订单创建成功返回到客户端（预扣费订单数）9：点击支付（确定扣费数）10：点击跳转充值（跳转充值数）11：第三方支付返回（支付成功数）active_timeDATETIMEY行为时间create_timeDATETIMEY日志采集时间Order id生成Order id采用数字，采用如下规则生成：年后2位+2位月+2位日+每天的自增量（固定长度9位）。如：140324000000001由order id生成模块创建一个自增表，每天清空一次自增表，并从头开始计数。所有需要order id的系统均从此模块获取order id.前端调度模块的同步机制由于前置和外部一些系统必须采用同步方式实现，而前置模块对游戏中心的服务采用QPID，为了保证前置的同步，现有2种方式可供选择：采用QPID本身的Requester/response机制：类似访问网页的通信方式，客户端发请求并等待，服务端回复该请求（这种方式最简单）；采用异步servlet，此方式可利用QPID的异步消息模式。（这种方式必须对响应详细进行分区，并且需要实现异步servlet）.消息队列设计4.1消息队列名生成规则：公司名.系统名.模块名.队列名.队列类型（请求：req,响应：res）消息队列名称说明meizu.game.order.gen.req生成订单的请求队列meizu.game.order.gen.res生成订单的响应队列meizu.game.order.query.req查询订单的请求队列meizu.game.order.query.res查询订单的响应队列meizu.game.stat.collect.req统计信息的请求队列meizu.game.stat.collect.res统计信息的响应队列4.2消息规则说明请求消息按如下规则：{//请求体，填充请求参数“参数”：”值”}响应消息按如下规则：{????code:,? //必选????message:, //可选，返回消息，网页端接口出现错误时使用此消息展示给用户，value:{} //必选，返回结果}消息定义：消息名请求 or 响应消息创建订单请求{“partnerId”, “appId”:””,“uid”:””,“cp_orderId”:””,“productId”:””,“product_name”:””,“product_subject”:””,“product_body”:””,“product_unit”:””,“buy_amount”:””,“product_per_price”:””,“total_price”:””,“trade_status”:””,“create_time”:””,“pay_time”:””}响应{????code:,? //必选????message:, //可选，返回消息，网页端接口出现错误时使用此消息展示给用户，value:{“orderId”,“partnerId”, “appId”:””,“uid”:””,“cp_orderId”:””,“productId”:””,“product_name”:””,“product_subject”:””,“product_body”:””,“product_unit”:””,“