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

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带宽

转载于:https://www.cnblogs.com/ChouYarn/p/11283369.html