storm-关于Tick的坑

2023-10-29 18:48

文章标签 tick storm

本文主要是介绍storm-关于Tick的坑，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

问题场景

优化storm下的一个bolt任务，测试时注释掉了一段关于Tick代码（为了不影响客户数据一致性），部署到测试环境报了个类型转换的错误。

现象

用了以下代码，是一个bolt部分代码

测试环境启动后stormUI中的bolt作业报错 java.lang.RuntimeException: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String

	@Overridepublic Map<String, Object> getComponentConfiguration() {Config conf = new Config();conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 300);return conf;}@Overridepublic void execute(Tuple tuple, BasicOutputCollector basicOutputCollector) {if (tuple == null) {return;}/*if (TupleUtils.isTick(tuple)) {// 处理逻辑return;}*/String json = tuple.getString(0); // 此处报类型转换错误，java.lang.RuntimeException: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String // 处理逻辑}

分析

跟踪tuple.getString(0)至storm内部代码如下：

1	String getString(int var1);  // 接口里的方法定义2   public String getString(int i) {	// TupleImpl里的实现return (String)this.values.get(i);}3   private List<Object> values;	// TupleImpl里的集合定义

上述步骤1没啥说的，直接看接口方法实现2，发现storm在处理tuple时是把数据加载到了values列表对象，values里的类型是Object，好嘛这时候强制转换就会有类型转换出错的风险，不知道为啥storm源码这么写。
有了这个风险再结合打印出的tuple源日志信息，发现报错时这个tuple为{“rate_secs”: 300}, 看为啥是300，代码里这个bolt把tuple类型设置成TOPOLOGY_TICK_TUPLE_FREQ_SECS了，tickTuple是Storm中引入的一种定时机制，利用tickTuple能够实现间隔一段时间进行某种处理的逻辑，当到了处理时返回的tuple就为{“rate_secs”: 300}，而测试环境把处理逻辑注释了，直接走到了tuple.getString(0)，接着storm坑爹的用了强制转换为String，于是报错。

日志截图：
在这里插入图片描述

处理

找到原因就好办了，把代码放开且注释内部处理逻辑即可。

正确代码

	@Overridepublic Map<String, Object> getComponentConfiguration() {Config conf = new Config();conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 300);return conf;}@Overridepublic void execute(Tuple tuple, BasicOutputCollector basicOutputCollector) {if (tuple == null) {return;}if (TupleUtils.isTick(tuple)) {/*// 处理逻辑*/return;}String json = tuple.getString(0); // 当tuple类型为tick时无法到达此处// 处理逻辑}