Upop总体设计
模块名称 | UPA |
所属系统 | UPOP |
模块负责人 |
|
项目负责人 |
|
文档提交日期 |
|
文档更新日期 |
|
文档历史
程序版本 | 修订版本 | 修订内容 | 修订人 | 修订日期 | 内容简介 |
1.0.0 |
|
| 刘勇 | 2012/07/05 | 全文 |
|
|
|
|
|
|
|
|
|
|
|
|
1 背景
2 名词解释
3 设计考虑
UPA主要实现以下功能:
1. 记录用户支付行为
2. 获取客服端支付静态(软件)信息
提高服务性能,UPA一致采用全异步方式采集客户端信息并分析处理.
4 性能与内存消耗
对于性能方面,主要关注点如下:
1、 检索性能为>1000次/s;
2、单台服务器内存占用控制在2G以内;
3、实际线上运营将提供至少2台服务器同时提供服务,每个服务提供不少于50个线程。具体线程数将依据性能要求的标准来调整;
5 UPA系统设计
5.1 系统架构
1:总体框架
数据分析系统主要分为3大模块
A:采集模块。部署于需要分析的网站。通过ajax方式向服务器传递采集信息。
B:数据处理模块。主要用于处理采集模块的数据。
C:统计模块。根据采集的数据,分析用户的行为,以多种形式展现给网站分析者。
2:对应到java项目
采集模块:UPASampler工程
数据处理模块和统计模块:UPAConsole工程
数据处理模块采取UPAConsole项目启动,自动运行定时任务。
UPASampler和UPAConsole 依赖于UPACore工程
UPA系统由两大子系统组成:一是UPASample,该模块是UPA系统的核心部分,主要负责采集客服端用户信息并以文件或数据库形式来存储;二是UPAConsole,该模块主要负责对采集后的信息加以分析、处理,以图表的形式呈现客户端信息;另外还有UPACore和UPAETL为辅助系统。Upop的个子系统以及与外系统的说明见下表:
系统说明 | |
UPAETL | 负责数据导入,将文件形式的数据导入到数据库 |
UPACore | 此工程下包含了各个系统的公共代码,如:线程池,jdbc连接池,DB序列生成器,File序列生成器等等! |
|
|
5.2 技术体系
UPAConsole为后台统计可视化系统,其使用的技术体系如下表所示:
UPASample | |
语言 | Java (SUN JDK 1.6), Jsp, Html , Javascript |
web容器 | Apache Tomcat 6.0 |
操作系统 | RedHat Linux 9.0 |
数据库 | Mysql5.0 |
UPASample为前台异步采集系统,为提升系统的性能,采集信息存储的方式主要以文件的格式批量存储,但文件系统出问题时也可以切换至数据库的形式存储,其使用的技术体系如下表所示:
Upserver | |
语言 | Java,Javascript |
操作系统 | RedHat Linux 9.0 |
数据库 | File,Mysql5.0 |
5.3 设备需求
生产环境设备需求如下表:
应用系统 | 硬件规格 | 数量 | 到位时间 |
UPAConsole | 待续 |
|
|
PASample | 待续 |
|
|
5.4 网络部署
待续
5.5 流程图及说明
5.5.4 UPAConsole
UPAConsole在线支付统计系统,即将采集信息分析处理,以图表信息呈现客户支付行为,为提升统计性能,系统采用基层分表形式统计。主要提供功能列表如下:
服务名 | 命令号 | 说明 |
统计 | Analytics | 没天晚上负责统计前天的采集数据,将统计后的结果插入数据库静态信息表中! |
统计查询 | query | 将统计结果表中的数据以可视化的效果展示在客户面前! |
报表管理 | Report | 将统计结果信息以报表形式供操作员下载! |
权限管理 | Security | 配置登陆用户能看到的信息 |
数据导入 | Import | 规划统计流程!每天晚上建立明天的统计基表,然后导入数据,最后统计导入数据! |
|
|
|
5.5.4.1 统计
一、统计概况图表
二、
二、统计表说明
字段名 | 字段类型 | 长度 | 说明 | 备注 |
BATCH_CTRL_ID | int | 11 | 自增长id | 0 |
SITE_ID | int | 11 | 商户id | 0 |
BASE_INFO_ID | int | 11 |
| 0 |
CURR_START_TIME | timestamp | 0 | 当前统计开始时间 | 0 |
CURR_TIME_BUCKET | int | 11 | 当前统计时间间隔 | 0 |
PRE_START_TIME | timestamp | 0 | 上一次统计开始时间 | 0 |
PRE_TIME_BUCKET | int | 11 | 上一次统计时间间隔 | 0 |
NEXT_START_TIME | timestamp | 0 | 下一次统计开始时间 | 0 |
STAUTE | varchar | 2 | 统计状态:00为待处理,01为处理中,02为处理失败,04为处理成功. | 0 |
EXECUTE_STRATEGY | varchar | 10 | 统计执行策略,DAY表示1天单位执行策略,HOUR表示以1小时为单位执行策略 | -1 |
UPA_ITEMS | varchar | 50 | 统计项01_02_03_04_05,其中01表示静态信息,02表示站点来源,03页面统计04表示独立信息,05表示用户行为. | 0 |
UPA_RESULT | varchar | 50 | 统计结果00000表示全部成功统计.01000表示第2个统计任务失败了 | 0 |
ERROR_MESSAGE | varchar | 255 | 错误信息 | -1 |
rec_crt_ts | timestamp | 0 | 0 | 0 |
rec_upd_ts | timestamp | 0 | 0 | 0 |
三:类图详细设计
统计框架类图大体结构如下
UPA统计系统类图详细设计请参考doc目录下的统计框架详细类图.oom
统计框架用例图如下:
四:统计类图详细讲解
执行所有添加的统计命令(invoke.executeCommand(filter, upaResultVo)) |
(A)多线程处理每个统计任务(doUpaJob(UpaBatchCtrlVo upaBatchCtrlVo)) |
将统计任务抛进线程池(GatherThreadProceeTool.wqs.addWorkJobToQueue(utw);) |
批量插入需要执行的统计任务(systemDao.insertUpaBatchCtrl(insertList);) |
五:统计项详细说明
1:静态信息统计
2:来源统计
3:独立PV、IP
4:页面统计
页面统计用来统计页面在指定的时间段里背点击的次数:统计数据来源自TBL_UPA_LOG_LINK_VISIT表,为灵活控制,统计采用配置表的方式来进行,将所有需要统计的页面的action存至表TBL_UPA_LINK_VISIT_RULE,后台统计会读取该表的缓存信息,接着便利每条信息执行统计;
TBL_UPA_LINK_VISIT_RULE表中GATHER_REF字段主要用来区别前后台统计来源,01表示前台,02表示后台,TYPE_ID表示组类型。
5:用户行为统计
5.5.4.2 页面查询视图设计
UPA统计视图查询采用采用动态图表的形式显示,所使用的技术为fusioncharts!开发人员可在网上搜索学习这方面的技术,视图设计分两种,一种是静态视图查询,动态视图配置查询!静态视图配置查询主要有:系统环境,订单来源,独立访客及ip,用户行为分析!动态视图配置查询主要为银联支付网关各个页面的统计以及各种比例(支付成功率等等)的查询!静态视图配置查询相对简单,这里主要讲解一下动态视图配置查询!
动态视图配置查询以时间为坐标,可以查询以小时,天和月三种单位的视图结果!前台页面输入查询时间段,后台判断时间段的跨度来自动判断页面将要以何种单位来显示结果!如:页面数据2012-02-12 00:00:00 和2012-02-12 05:00:00,很明显时间跨度为5个小时,小于24个小时,页面视图将以小时为单位显示结果!后台查询逻辑具体为,根据前台传入的公式参数,到数据库匹配具体的公式,在根据公式计算出需要统计的action,在查询action具体的统计数量,在将这些个值替换成公式中具体的值,最终计算出结果!如此循环,直至所有时间段都计算出结果为止!需要注意的是:如果统计只是单个action的话,统计公式将会报错,此错误为正常错误,因为四则混合运算器无法对单个值进行运算处理!
5.5.4.3 异步报表平台配置
1:处理流程
用户选择报表生成条件,点击下载按钮(选择生成报表类型),后台将用户生成的报表条件插入报表队列表中,在由定时器每隔一定得时间遍历任务表,每次查到所有待处理的报表生成任务,即将其扔进报表处理线程池中(默认开启十个线程)生成相应的报表.
2:report配置范例(Report.xml):
<report id="1"defimit="report001">
<!—报表查询的sql语句-->
<sql>webInfoSearch.selectAnalyicsGroupDataAsBrowserIgnoreVersion</sql>
<!--生成报表的字段的表头-->
<head>浏览器名称,浏览器访问量</head>
<!--生成报表的条件-->
<conditionclass="com.unionpay.upa.view.analytics.vo.StaticInfoVO">
<list>
<value>siteId</value>
<value>anaStartTime</value>
<value>anaEndTime</value>
</list>
</condition>
<!--生成报表的字段-->
<resultclass="com.unionpay.upa.view.analytics.vo.StaticInfoVO">
<list>
<value>infoPropertyValue</value>
<value>infoPropertyNum</value>
</list>
</result>
</report>
3:参数注册
com.unionpay.upa.view.service.impl.ReportServiceImpl.java
private List<Object>packageCondtion(ReportTaskVO reportTaskVO)
注意:
1:list中的添加参数的顺序必须和报表配置文件中生成报表的条件的配置顺序一致
2:生成报表的字段必须和查询语句和报表头的字段一致
5.5.5 UPASample
5.5.5.1 客户端解决草案
5.5.5.1.1 需收集的信息
1、 用户唯一标识:采用两个域来确定一个唯一用户。每个域是最长长度为10位的数字,第一个域采用一个随机数作为id,第二个域为时间戳;
2、 浏览记录:浏览记录包括当前页面地址和页面来源地址;
3、 访问时间:包括首次访问时间,上次访问时间,当前访问时间;
4、 访问次数
5、 用户信息:包括屏幕高度和宽度、屏幕颜色、浏览器语言、浏览器是否开启java,浏览器编码方式
5.5.5.1.2 解决方案
1、 采用cookies把用户的一些访问信息进行存储。暂定五个cookies,如下:
a) upaa:记录用首次户访问时间(时间戳)、上次访问时间、当前访问时间、访问次数、哈希域、id。
功能:存储访问时间和次数。
有效期:1年
格式:哈希域.id.首次访问时间.上次访问时间.当前访问时间.访问次数
说明:此cookies所有信息都将发送给服务器
b) upab:记录哈希域、当前访问时间、本次访问页面数。
功能:与upac共同决定一个session
有效期:30分钟
格式:哈希域. 本次访问页面数.当前访问时间
c) upac:记录哈希域
功能:与upab共同决定一个session
有效期:关闭
格式:哈希域
d) upad:记录哈希域、当前访问时间、页面来源、来源地址,页面参数
功能:存储页面来源和地址
有效期:1年
格式:哈希域.当前访问时间.source=页面来源|surl=来源地址|parames=页面参数
说明:此cookies所有信息都将发送给服务器
页面来源分为三种,分别为:1.直接输入direct;2.搜索引擎organic;3.推介网站referral
来源地址仅为host
页面参数仅当来源为搜索引擎时存在,其值为关键字
e) upae:记录哈希域、用户账户信息
功能:存储一些用户账户信息
有效期:1年
格式:哈希域.用户账户信息
注:根据id和时间戳来确定用户的唯一性,id为随机生成,为避免重复,id采用长度为10的随机数。当超过30分钟,upad失效,刷新页面即是新的一个访问。不同来源数记录网站不同来源的数量,若是此次访问的来源不同于上次,则此数量加一。
2、 与服务器的通信
a) 连接方式:
当需要传的参数小于2k时,采用get方式传参,通过构建一个image对象;当参数大于2k小于8k时采用post方式,通过window.XDomainRequest或window.XMLHttpRequest。
参数:
参数如下:
1. upah,哈希域
2. upai,id
3. upats,时间戳
4. upav,版本号
5. upawh,长宽
6. upacd,颜色
7. upala,语言
8. upacs,编码方式
9. upaij,是否开启java,1为开启,0为关闭
10. upaswf,swf版本号
11. upau,用户账户
12. upaa,名为upaa的cookies值
13. upad,名为upad的cookies值
14. upab,名为upab的cookies值
15. upacsu,当前页面的地址,不带参数
16. uparfu,页面来源地址,不带参数,若无来源则为/
17. upacsp,当前页面参数,需页面设置,若无设置,则为空,多个参数用|连接
18. upadm,网站域名
b) 返回
返回为一个1*1的图片。
一、问题
a) Cookies删除,cookies删除后则认为此用户为第一次访问,带来了数据的误差;
b) 停留时间,最后一个页面无法获得停留时间。暂时没有找到解决方法。心跳方法不合适,即使心跳的时间间隔为1分钟,那么每个用户只要访问就会产生心跳,这是个很大数量的请求,而且是一直持续不断的。
c) 多浏览器的问题,cookies与浏览器的关系更紧密一些,不同浏览器的cookies有不同的地方。带来的问题就是,一个用户在一台机器上用两个浏览器访问,这样为两个唯一用户;同样的,两个用户在一台机器上用一个浏览器访问,这样为一个唯一用户。
5.5.5.2 服务器端解决草案
服务器端接收客户端Ajax发来的请求,并解析其中的信息,然后对其进行那个处理,并添加到数据库。
客户端发来的请求可以分为两类:访问请求(visit)和心跳请求(heartbeat)。本草案就一次为依据,来描述不同请求的处理方式。下文为流程的总体描述:
图1:总体流程框架
一、收到请求后,先解析器reqType参数
1.若为heartbeat,则提取hash值,id,时间戳,进入访问模块子流程
2.若为visit,则取出相应信息,初始化VisitDetail对象,进入heartbeat子流程。
图2:请求处理子流程
二、进入请求处理子流程。
1.在VisitDetail中使用hash,id,时间戳后十位,计算一个新的hash值,对其取N的模后放入相应的线程池。N会在配置文件中定义。
2.进入VisitDetail处理子流程。
图3:VisitDetail处理子流程
三、VisitDetail处理子流程
1.根据VisitDetail对象中的信息查询,计算出Cookieid,计算方法为hash+id+时间戳长整形后十位。查询log_visit表,判断与之对应的记录是否存在。
2.记录存在,则更新piwik_log_link_visit_action中相应信息,同事更新log_visit表。
3.记录不存在,则在log_visit表中插入相应记录,同时在log_action和piwik_log_link_visit_action中插入相应的记录。
图4:心跳处理子流程
四、心跳模块子流程
1.取出Request中的hash,id,和时间戳,计算出该请求在心跳缓存池中对应的键值。
2.查询该键值,若已经存在,则更新定时器,若不存在,新建记录,并将其插入心跳缓存池。
3.在定时器被触发后,根据其hash,id,时间戳,在piwik_log_link_visit_action表中更新相应的记录。
附录:部分重要数据结构定义。
VisitDetail的定义:
HeartBeatPool:
{
pool: ConcurrentHashMap<String,TimeOutTrigger>
}
TimeOutTrigger
{
Hash: String
Id: String
Timestamp: Date
}