一、背景：

临近双11大促，为避免流量峰值较高，电商公司都会对系统进行压测。一直做实时数据计算，应用是基于Flink做的，接收kafka消息，进行数据统计，包括：pv、uv、dau、单量、成交额等等。

为了保证应用在大促期间不出问题，需要进行实时计算程序进行压测。由于统计的数据分为两类(流量数据、订单数据)，对这两类数据进行不同方式的压测。

 

二、压测准备

(1)压测时间选择：一般选择在凌晨，对业务影响最小

(2)集群准备：搭建主备集群，将kafka集群、Flink集群、redis集群，分别搭建两套，在资源有充裕的情况下。（主备集群既能够做到容灾、高可用，也能在压测过程，轻松实现压测）

(3)如果资源有限，不能搭建主备集群，也能进行压测，但是在灾备和高可用方面就没办法保证了

 

三、压测实践

情况一：有主备集群的情况下(压测比较简单)

(1)通知下游，将查询的数据切换另外一套集群上(不进行压测的集群)

(2)将kafka消息位点进行调整，将消息挤压量调整至去年大促的峰值的几倍左右

(3)重启Flink应用

(4)查看监控：kafka监控、Flink监控

                                                                               kafka消息挤压监控

                                                                                Flink数据处理监控

情况二：没有主备集群的情况下(由于没有主备集群，压测可能会对下游统计数据存在影响，需要通知下游)

1.流量数据压测(由于数据量较大不好做幂等处理，对下游影响较大)

(1)通知下游，将压测安排在凌晨进行

(2)停止Flink应用，造成消息挤压，达到挤压数量

(3)启动Flink应用，开始消费，查看各项监控指标

注：没有采用回置kafka消息位点，而是进行憋数，只造成短时间下游数据指标短时间不可用，整体影响不大

2.订单数据压测

• 没有幂等处理，同样可以采用流量的方法进行压测
• 有幂等处理

(1)通知下游，进行压测

(2)回置kafka消息位点

(3)重启Flink应用，开始消费，查看各项监控指标

注：由于幂等处理，回置位点，不会对下游统计数据造成影响

 

四、压测总结

压测过程中可能会出现的问题：

(1)Flink会出现背压

(2)可能出现redis热key，如果单一维度指标key修改比较频繁

(3)....

对于上述出现的问题，进行解决即可。

 

由于在大促活动中的流量出现高峰，压测是为大促保障之前做的非常重要的一个环节，上述讲述了如果在大促之前对Flink实时计算程序进行压测，让我们开发的程序能够平稳地渡过大促。