一 环境与部署
1. 环境变量
由于是分布式环境，对于java单机的 -Djvm参数不适用，在storm中处理环境变量是通过org.apache.storm.Config，在提交任务创建Topology时设置Config，在Spout和Bolt中通过open方法中的config参数读取
2. 部署
storm集群重启时会有短暂时间的不可用，解决这种方式可以通过部署两个功能完全相同的集群，在提交任务的时候传入集群名，就好像同样的服务部署在多个机器上，但是这种方式对于按照字段分组的场景可能产生并发问题
以下为启动代码示例：
public class TestTopology { private static final Logger logger = LoggerFactory.getLogger(TestTopology.class); protected static String topologyIndex = ""; // 区分A,B集群 protected String testTopology = "test-topology"; public static void main(String args[]) { topologyIndex = args[0]; if (args.length > 1) { System.setProperty("env", args[1]); // 接收环境变量 System.out.println("init env is " + args[1]); } if (StringUtils.isEmpty(topologyIndex)) { logger.error("topology index error"); System.exit(0); } new TestTopology().build(); } public void build() { AdStormEnvironment.init(System.getProperties(), false); TopologyBuilder builder = new TopologyBuilder(); Config config = new Config(); config.put("env", System.getProperty("env")); // 设置环境变量 try { StormSubmitter.submitTopology(testTopology + "-" + topologyIndex, config, builder.createTopology()); } catch (Exception e) { SlfLogUtil.error(logger, e, "部署集群任务失败|{0}|{1}", System.getenv(), StormEnvironment.getName(testTopology)); } } }
二 日志兼容问题
storm日志可以说是最头疼的问题，这也和java中日志体系有关，log4j log4j2 slf4j commons-logging jdk-log logback 等等
java日志体系分成两类，一类是实现，一类是接口定义。实现就是具体的log，接口定义主要是为了整合其他日志框架
1. 日志类实现
jdk-logging， jdk自带log类，基本没人用
log4j， log4j的实现，常见版本1.2.17
logback，log4j作者的有一个实现，性能更好
log4j2，性能更好的日志实现，storm使用的就是log4j2，版本为2.8。只不过log4j2引入有两个包，一个是log4j2-api，一个是log4j2-core，所以其他日志框架实现了log4j2-api都可以整合到log4j2的项目中
commons-logging，由于log4j先于jdk-logging，commons-logging主要做的事就是优先使用log4j，没有的话使用jdk-logging，再不行的话使用自己的实现
2. 日志类接口
slf4j，一种日志标准实现的定义，逐渐形成新的行业标准
slf4j有很多子包，所有xxx-slf4j-impl的包都是slf4j的具体实现，例如log4j-slf4j-impl, log4j2-slf4j-impl等
实现原理就是调用具体的日志实现的方法，比如log4j-slf4j-impl中的Logger会调用log4j的Logger
xxx-over-slf4j的包都是把日志实现转移到slf4j上，例如log4j-over-slf4j
实现原理是比如log4j包中有个叫Logger的类，在log4j-over-slf4j包中也有个同名的Logger类，但是方法实现是调用slf4j的api，java中同名类加载的顺序是按照classpath哪个在前面就先加载哪一个，如果是先加载了log4j也是无法生效的
所以xxx-over-slf4j和xxx-slf4j-impl不能同时引入，不然会造成死循环
3. storm中引入了哪些包
slf4j-api log4j-api-2.8 log4j-slf4j-impl-2.8 log4j-core-2.8 这几个主要是slf4j和log4j2的组合
log4j-over-slf4j-1.6.6 log4j的日志转到slf4j
log4j-over-slf4j-1.6.6 中的坑，主要是这个adapter对于log4j-1.2.17的实现有问题，比如https://jira.qos.ch/browse/SLF4J-368 这个问题，在使用DailyRollingAppender时会有问题，还有一些奇奇怪怪的问题，总的来说还是要把log4j迁移到slf4j比较保险
storm应用中会引入storm-core这个包，这个包也会依赖log4j2，当版本与storm安装目录下log4j2的2.8版本不一致的时候可能会产生错误，maven打包时最好execlude掉
三. 日志配置问题
由于storm不能指定log4j2配置文件的位置，所以集群中只能使用一份配置，对于测试和线上环境的区分就比较麻烦，以下给出解决方案如下：
修改config.yaml
worker.childopts: "-Xloggc:/data1/logs/storm/%TOPOLOGY-ID%/%ID%/gc.log" 其中%TOPOLOGY-ID%代表拓扑名，%ID%代表worker端口号，这样可以让GC LOG打印到与worker log同级
修改worker.xml
<configuration monitorInterval="60" shutdownHook="disable"> <properties> <property name="pattern">[%p] %d{yyyy-MM-dd HH:mm:ss,SSS} [%c]-[%M line:%L] %m%n</property> <property name="baseDir">/data1/logs/storm</property> </properties> <appenders> <RollingFile name="ROOT_LOG" fileName="${baseDir}/${sys:storm.id}/${sys:worker.port}/root.log" filePattern="${baseDir}/${sys:storm.id}/${sys:worker.port}/root.log.%d{yyyy-MM-dd}.gz"> <PatternLayout> <pattern>${pattern}</pattern> </PatternLayout> <Policies> <TimeBasedTriggeringPolicy modulate="true" interval="1"/> </Policies> <DefaultRolloverStrategy max="9"/> </RollingFile> <RollingFile name="worker" fileName="${baseDir}/${sys:storm.id}/${sys:worker.port}/worker.log" filePattern="${baseDir}/${sys:storm.id}/${sys:worker.port}/worker.log.%d{yyyy-MM-dd}.gz"> <PatternLayout> <pattern>${pattern}</pattern> </PatternLayout> <Policies> <TimeBasedTriggeringPolicy modulate="true" interval="1"/> </Policies> <DefaultRolloverStrategy max="9"/> </RollingFile> <RollingFile name="ERROR_LOG" fileName="${baseDir}/${sys:storm.id}/${sys:worker.port}/stdout.log" filePattern="${baseDir}/${sys:storm.id}/${sys:worker.port}/stdout.log.%d{yyyy-MM-dd}.gz"> <PatternLayout> <pattern>${pattern}</pattern> </PatternLayout> <Filters> <ThresholdFilter level="error" onMatch="ACCEPT" onMismatch="DENY" /> </Filters> <Policies> <TimeBasedTriggeringPolicy modulate="true" interval="1"/> </Policies> <DefaultRolloverStrategy max="4"/> </RollingFile> </appenders> <loggers> <root level="info"> <appender-ref ref="ROOT_LOG"/> <appender-ref ref="ERROR_LOG"/> </root> <Logger name="STDERR" level="INFO" additivity="true"> </Logger> <Logger name="STDOUT" level="INFO" additivity="true"> </Logger> <Logger name="oo.xx" level="info"> <appender-ref ref="worker"/> </Logger> </loggers> </configuration>
主要修改：
a. 自己应用的日志打印到worker.log
b. storm和一些其他方面的日志打印到root.log
c. 所有error级别的log打印到stdout.log，用来监控应用错误
d. [%c]-[%M line:%L] 这三个设置可以方便知道日志打印的 类，方法，行
创建自己自定义的Logger类
public class SlfLogUtil { private static final String FQCN = SlfLogUtil.class.getName(); public static void info(Logger logger, String message) { if (logger instanceof LocationAwareLogger) { ((LocationAwareLogger) logger).log(null, FQCN, LocationAwareLogger.INFO_INT, message, null, null); } else { logger.info(message); } } public static void debug(Logger logger, String message, Object... params) { if (Environment.isTest()) { info(logger, format(message, params), false); } } }
主要修改：
a. 代理info debug error 方法，尤其是debug，自己可以根据环境变量来判断，这里Environment.isTest()方法可以自己实现
b. 为了可以打印方法调用位置需要使用slf4j的LocationAwareLogger，不然日志中会变成SlfLogUtil方法调用的位置
四. 日志收集问题
Storm由于是分布式的，所以日志会分布在各各机器上，而且每次重启会新生成一次目录，非常不利于对应用日志的观察，提出如下几种解决办法
可以使用日志收集客户端，直接采集文件，但是需要监控文件和文件夹的新增，比较麻烦
还有一种办法是固定日志文件的名字，比如使用LOG4J2中的Routing功能，通过ThreadContext固定日志的位置，但是ThreadContext对于多线程的时候需要传递ThreadContext中的值，而且一个拓扑在不同worker中肯定无法输出到同一个文件，还是只能在固定路径生成stdout.$worker.log 这样的log
第三种办法后来尝试直接使用KafkaAppender，通过网络转走日志，最后也是使用这种办法，如果使用Log4j2的KafkaAppender在配置文件中配置，测试环境和线上环境又不能在同一个topic，所以自己实现了KafkaAppender，具体实现如下
@Plugin(name = "StormAppender", category = "Core", elementType = "appender", printObject = true) public class StormAppender extends AbstractAppender { String topic; Producer<String, String> producer = null; String hostName; /* 构造函数 */ public StormAppender(String name, Filter filter, Layout<? extends Serializable> layout, boolean ignoreExceptions, String topic) { super(name, filter, layout, ignoreExceptions); this.topic = topic; producer = new KafkaProducer<String, String>(getKafkaConfig()); try { hostName = InetAddress.getLocalHost().getHostName(); } catch (Exception e) { hostName = "unknown"; } } private Properties getKafkaConfig() { Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("acks", "1"); props.put("retries", 2); props.put("batch.size", 512); props.put("linger.ms", 1); props.put("max.block.ms", 1000); props.put("buffer.memory", 32 * 1024 * 1024); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("compression.type", "gzip"); return props; } @Override public void append(LogEvent event) { if (event.getLoggerName().startsWith("org.apache.kafka")) { LOGGER.warn("Recursive logging from [{}] for appender [{}].", event.getLoggerName(), getName()); } else { try { final Layout<? extends Serializable> layout = getLayout(); byte[] data; if (layout != null) { if (layout instanceof SerializedLayout) { final byte[] header = layout.getHeader(); final byte[] body = layout.toByteArray(event); data = new byte[header.length + body.length]; System.arraycopy(header, 0, data, 0, header.length); System.arraycopy(body, 0, data, header.length, body.length); } else { data = layout.toByteArray(event); } } else { data = StringEncoder.toBytes(event.getMessage().getFormattedMessage(), StandardCharsets.UTF_8); } String line = hostName + "|" + StormEnvironment.getTopology() + "|" + new String(data); producer.send(new ProducerRecord<String, String>(topic, line)); } catch (final Exception e) { LOGGER.error("Unable to write to Kafka [{}] for appender [{}].", topic, getName(), e); throw new AppenderLoggingException("Unable to write to Kafka in appender: " + e.getMessage(), e); } } } @PluginFactory public static StormAppender createAppender(@PluginAttribute("name") String name, @PluginAttribute("topic") String topic, @PluginElement("Filter") final Filter filter, @PluginElement("Layout") Layout<? extends Serializable> layout, @PluginAttribute("ignoreExceptions") boolean ignoreExceptions) { if (name == null) { LOGGER.error("no name defined in conf."); return null; } if (layout == null) { layout = PatternLayout.createDefaultLayout(); } return new StormAppender(name, filter, layout, ignoreExceptions, topic); } @Override public void stop() { } }
主要修改：
a. 向kafka投递日志内容的时候会增加拓扑名，方便消费的时候做区分，根据LogEvent还可以做更多的定制
b. 日志防止循环打印，如果是org.apache.kafka的日志不打印，还有Appender不要使用工程中的其他类，比如A类的m方法中记录日志会调用自定义的Appender，在自定义的Appender中又会调用A类的m方法造成死循环
有了Appender，下一步是在启动拓扑的时候，将appender加入到rootlogger中，可以使用代码的方式动态更新rootlogger的appender，这样也可以根据环境来投递到不同的topic种，代码如下
final LoggerContext ctx = (LoggerContext) LogManager.getContext(false); final Configuration config = ctx.getConfiguration(); Layout layout = PatternLayout.newBuilder().withPattern("[%p] %d{yyyy-MM-dd HH:mm:ss,SSS} [%c]-[%M line:%L] %m%n") .withConfiguration(config).build(); for (Appender appender : config.getAppenders().values()) { if ("stormAppender".equals(appender.getName())) { System.out.println("storm appender has inited"); return; } } System.out.println("init storm log to kafka topic " + StormEnvironment.getName(KafkaTopics.STORM_LOG)); final Appender stormAppender = StormAppender.createAppender("stormAppender", StormEnvironment.getName(KafkaTopics.STORM_LOG), null, layout, true); stormAppender.start(); config.addAppender(stormAppender); AppenderRef stormAppenderRef = AppenderRef.createAppenderRef("stormAppender", Level.INFO, null); final Appender appender = AsyncAppender.newBuilder().setIgnoreExceptions(true).setConfiguration(config) .setName("asyncStormAppender").setIncludeLocation(true).setBlocking(false).setAppenderRefs(new AppenderRef[] {stormAppenderRef}).build(); appender.start(); config.getRootLogger().addAppender(appender, Level.INFO, null);
主要修改：
a. 这里自定义的Appender用AsyncAppender包了一层，一定要设置setIncludeLocation(true)，不然无法打印日志调用的位置
五. Storm不只是WordCount
1. streamid的概念
strorm资料比较多的是讲word count的例子，http://zqhxuyuan.github.io/2016/06/30/Hello-Storm/ 这篇文章讲了streamid的概念，让流可以分叉，可以合并
一个bolt可以同时定义多种输入，一个bolt或者spout在emit数据的时候也可以到任意的spout或者bolt
mergeBolt接收两种输入
builder.setBolt("merge", merge, mergeThread) .fieldsGrouping("recoverSpout", "merge-recover", new Fields("ideaId")) .fieldsGrouping("log", new Fields("ideaId"));
定义两种输出流，可以在运行时emit的时候指定streamid输出到哪个bolt
@Override public void declareOutputFields(OutputFieldsDeclarer outputFieldsDeclarer) { outputFieldsDeclarer.declare(new Fields("encrypt", "topic", "messageId")); outputFieldsDeclarer.declareStream("merge-recover", new Fields("param", "campaignId", "ideaId", "messageId", "topic")); }
2. ack
开启ack机制后需要注意如下几点：
2.1 Spout需要自己存储未确认的消息，一般存储在一个LRUMapV2<String, Object> pending这样的定长队列中，防止爆内存
2.2 Spout ack时删除pending数据
2.3 Spout fail时一般选择重新投递，如果失败次数过多只记录日志，防止死消息在拓扑中无限循环
2.4 messageId 最好由topology上游业务生成，更安全
2.5 因为有重投存在，所以所有需要写数据的地方需要保持幂等性，用messageId + 操作做key，redis集群来存储，比如一个IncBolt -> SaveBolt，在SaveBolt失败，重投的时候IncBolt不需要在做具体的Inc操作
ack机制不作为业务处理失败时的恢复机制：
每个bolt在finally中进行ack，如果消息处理有异常放入到外部队列，手动进行重投，而不是依靠storm进行自动重投。让storm的ack机制保证的仅仅是当某个bolt挂掉时候的自动重投
3. 慎用静态变量
首先topology中的bolt和spout都是worker中的线程，可以使用jstack查看，如果一个boltA和boltB在同一个jvm中同时操作static变量可能会造成问题，所以最好不要使用单例，尤其是有状态的类，一定要在open的时候创建一个实例
如果是资源类的，比如数据库连接，可以是各种bolt spout共享一个，将其设置为静态，但是注意初始化的时候需要synchronize
4. bolt异常退出问题
bolt的execute(Tuple input)方法，一定要加try catch exception finally，如果为execute的异常抛出到storm框架，会导致worker异常退出，整个拓扑stop，建议是异常自己catch并处理
5. 长时间空消息导致Spout emptyEmit
在测试环境发现Spout长时间的没有消息emit会出现一只调用emptyEmit，但是也不是一定出现，为了安全做了两点
5.1 Spout从kafka消费的时候增加超时时间，当超时以后nextTuple立刻return
5.2 长时间没有emit消失，Spout emit一条空消息，bolt收到空消息只ack不处理