1.配置项
每日统计的sql脚本. 基于每月统计之上月统计脚本,基于月之上的年统计脚本.
订阅哪张表的mq消息,触发grovvy的执行.返回对应的值. 但不一定能反向找到对应的实体.例如driverId,passengerId
方案:
年统计+月统计+当月日统计+当日binlog统计.
这样就不用为统计专门提供mq.
功能性业务:
统计某个key的时时数据.
非功能性考虑:
大数据定时任务很可能延迟
mq很可能重复或者丢失.
sql可能多条.
sql可能会变更.
设计:
静态: 数据中心,各种源的topic,业务方.
动态: 业务入口. 时时mq, 获取key时时统计值.
表结构设计:
amount表:
id:
key:
amount:
end_date 统计到哪天为止.
date_amount表: 非功能性考虑
id:
key:
date_amount: 某日统计值
amount: 累积统计值
redis设计:
key_date : amount : 每日时时统计值. 非功能性考虑
key_date_统计来源id: 表示是否已统计过. 幂等性控制. 非功能性考虑
key: amount: 性能考虑
逻辑设计,表的增删改查:
Amount表: 每日定时任务,修改数据上的amount和end_date
Date_amount表: 每日定时任务时,Amount表的end_date开始算起. 从修改数据上的amount和end_date;
redis: 每次mq时,不仅累加单日统计,还删除累加值(或者时时累加,对性能更好).
getAmount()= 获取缓存值,获取不到( 历史汇总数据+ date之后的时时日数据. )
上线单日的amount是不准的. 但第二天就准了.废弃了redis时时日统计值.当日数据不给用户展现,后台先上线
可配置化:
业务方:
配置,
1. 使用哪个消息源的哪个topic.
2. 使用topic里的哪个字段作为唯一性id.
3. key的命名.
4. 该key统计的起始日期.
每日统计sql:
1. 配置sql,可能是几条sql. 这个配置好后,通过大数据统计计算. 也可是是基于mysql计算.
业务方统计代码(两种选择: 选择duubo调用,还是 动态代码计算):
通过mq查询对应数据库代码. 通过autowired指定的jdbctemplate, 执行对应select操作. 也可以搞对应的integration,但陈本比较高.
返回累加amount;
这个代码部分可以是配置的在统计中心后台页. 也可以学习任务调度中心. 调度和执行解耦.. 各业务部署各mq执行模块. 通过rpc调用返回结果.
非功能性异常case分析:
1. sql变更
某订单的分润结果,没有复制对应的订单风控类型. 现在产品需要保存统计非风控订单的司机收入.
原sql非常复杂,需要跨多张表格. 业务系统会在保存分润结果的时候保存订单风控结果. 这样sql执行就不需要跨库了.
主要系统:
1. 大数据统计平台.
1.1 sql自管理和提交到大数据统计平台
1.2 或者让大数据那边管理,统计好导入到业务系统这边.
2. 数据中心调度和统计结果存储平台.
3. 业务统计平台.
当选择rpc dubbo调用执行时.