您的位置:首页 > 其它

实时计算-多级订单金额,及下级人数

2019-08-01 16:23 706 查看

1 系统概述

人物关系为代理模式,一级代理包含二级代理,二级代理包含三级代理。

需求为实时计算每个用户的订单金额,并取出金额的TOP100。

并实时计算当天下级人数。

1.1 指标使用方式
  • 单用户订单列表查询:查询订单表,不限定日期。
  • 当天订单额top100:查询指标表对金额排序取前100,限定日期当天。
  • 当天下级人数:根据用户id查询级别表统计行数,限定日期为当天。
1.2 系统概述

系统离线和实时合二为一,实时只需限定日期为当天,即为实时数据;离线数据只需指定日期即可。

1.3 性能概述
  • 计算引擎,Flink是纯流式架构,可保证数据的低延迟处理。
  • 存储:此套系统采用HBase+Phoenix作为存储,适当设计好索引可将查询延迟控制在2秒以内,tps数量和RegionServer数量呈正相关,此套系统可满足当前需求。

2 系统目标

1.1 容错性

对于当天的实时报表,容错能力详见处理逻辑。

1.2 可扩展性

此系统增加hbase RegionServer服务器数量对代码无影响。

1.3 健壮性

此套系统配置,随着订单量增加,HBase可支持的数据量可达亿级别。若业务暴增,系统磁盘受限,tps到达瓶颈,可适当增加机器节点,同样对业务代码无影响。

1.4 吞吐量

月增订单量大概在500W,单日增量20万左右,此系统设计至少满足于1年需求,实际的吞吐量根据集群而定,按照我的设计,集群平均tps在2500左右,目前能满足该需求。

1.5 数据倾斜

为防止数据倾斜,建表是可对Phoenix进行加盐或者指定split key。

1.6 一致性

HBase为强一致性,所以不存在并发修改问题。

1.6 高可用性

HBase为集群,基于Hadoop的HDFS,可设置副本集为3,此系统为3台节点,允许宕机一台,若要求高可用级别很高,则需相应增加机器。

3 业务流程

 

4 系统总体设计

4.1 架构

 

4.2 表设计

用户表

  • 主键:USERID,AGENTID

订单表

  • 主键:ORDERID,ordertime
  • 二级索引:USERID、shopid、status、totalFee

级别表

  • 主键:USERID,PT
  • 二级索引:childId

指标表

  • 主键:userid,pt
  • 二级索引:totalfee

5 系统功能设计

5.1 数据源

Kafka采用2.X版本,通过参数设置保证消息发送零丢失,但是本系统未涉及kafka相关。

5.2 计算引擎
5.2.1 消息零丢失

Flink checkpoint采用exactly once语义,保证消息只被消费一次,即使Flink意外宕机,也可从检查点恢复工作。

5.2.2 高可用性

Flink采用Standalone HA安装模式,可配置多个JobManager,保证Flink集群高可用性。

5.2.3 计算逻辑
  • 用户数据计算逻辑,涉及指标:下级用户数

 

  • 订单数据计算逻辑,设计指标:订单总金额
 

 

5.3 存储

HBase2.0.5采用HA安装,保证高可用,Phoenix5.0采用全局索引,保证读写的速率。

5.4 RESTful

接口使用Spring Boot 2.x编程。

6 硬件配置

HBase

  • RegionServer:3台32核128G,
  • Master:2台8核32G

Flink

  • JobManager:与HBase Master共用机器
  • executor:与HBase RegionServer共用机器

磁盘

  • 每台机器挂载4*1T硬盘

带宽

  • 至少1G带宽
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: