storm-关于Tick的坑

本文详细分析了一个在Storm环境下优化Bolt任务时遇到的类型转换错误。问题源于在测试环境中注释掉了处理Tick Tuple的代码,导致Tick Tuple被误处理,引发`java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String`。解决方案是恢复Tick Tuple的处理逻辑或在执行前检查tuple类型。

问题场景

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

现象

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

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

	@Override
    public Map<String, Object> getComponentConfiguration() {
        Config conf = new Config();
        conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 300);
        return conf;
    }
    
    @Override
    public 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. 上述步骤1没啥说的,直接看接口方法实现2,发现storm在处理tuple时是把数据加载到了values列表对象,values里的类型是Object,好嘛 这时候强制转换就会有类型转换出错的风险,不知道为啥storm源码这么写。

  2. 有了这个风险再结合打印出的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,于是报错。

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

处理

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

正确代码

	@Override
    public Map<String, Object> getComponentConfiguration() {
        Config conf = new Config();
        conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 300);
        return conf;
    }
    
    @Override
    public void execute(Tuple tuple, BasicOutputCollector basicOutputCollector) {
        if (tuple == null) {
            return;
        }
        
        if (TupleUtils.isTick(tuple)) {
            /*// 处理逻辑*/
            return;
        }

        String json = tuple.getString(0); // 当tuple类型为tick时无法到达此处
        // 处理逻辑
    }
在 Cisco 交换机上配置 `storm-control` 命令可以有效防止广播、组播或未知单播流量引发的网络风暴,从而提升网络的稳定性。要限制广播流量并设置阻塞(block)动作为响应,需在接口配置模式下进行以下操作。 配置接口的广播流量限制为接口带宽的 50%,并在流量超过该阈值时启用阻塞动作,命令如下: ```bash switch(config)# interface gigabitethernet 1/0/1 switch(config-if)# storm-control broadcast level 50 switch(config-if)# storm-control action block ``` 其中,`storm-control broadcast level 50` 表示将广播流量限制为接口带宽的 50%;`storm-control action block` 表示当广播流量超过设定阈值时,接口将进入阻塞状态,停止转发数据包,直到风暴消失[^1]。 此外,还可以为组播和未知单播流量配置类似的限制。例如: ```bash switch(config-if)# storm-control multicast level pps 50k switch(config-if)# storm-control unicast level 20 10 ``` 上述配置中,`storm-control multicast level pps 50k` 表示组播流量限制为每秒 50,000 个数据包;`storm-control unicast level 20 10` 表示未知单播流量的上下限分别为接口带宽的 20% 和 10%[^2]。 若希望在风暴结束后自动恢复接口状态,可结合 `errdisable recovery` 功能进行配置: ```bash switch(config-if)# storm-control action shutdown switch(config)# errdisable recovery cause storm-control-action switch(config)# errdisable recovery interval 30 ``` 该配置表示在风暴发生时关闭接口,并在 30 秒后自动恢复接口状态[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值