Storm中遇到的日志多次重写问题（一）

本文主要是介绍Storm中遇到的日志多次重写问题（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

原文：

http://www.cnblogs.com/zpfbuaa/p/5974000.html

业务描述：

　　统计从kafka spout中读取的数据条数，以及写入redis的数据的条数，写入hdfs的数据条数，写入kafaka的数据条数。并且每过5秒将数据按照json文件的形式写入日志。其中保存为json数据的格式为：时间戳 + 进程名称 + 读kafka数据条数 + 写入redis数据条数 + 写入hbase条数 + 写入kafka条数。time_stamp + process_name + from_kafka + to_redis + to_hdfs + to_kafka

给出实现的关键代码：

package count;import java.io.FileWriter;
import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;import bolt.addGridNo;
import bolt.transGPS;
/** 写在main函数里面了，因此只是跑在nimbus上面* 这样做是不对的！！！*/
public class countflow{private static String fileName = "/home/storm/countflow";//定义写文件路径static FileWriter writer = null;//文件读写流//private static Timer timer = new Timer();//计时器，每过5秒钟进行写数据
//    private static countflow uniqueInstance;
//    private countflow(){}
//    public static countflow getInstance(){
//        if(uniqueInstance == null){
//            uniqueInstance = new countflow();
//        }
//        return uniqueInstance;
//    }/*public void run() {try {writer = new FileWriter(fileName, true);} catch (IOException e) {e.printStackTrace();}executeFixedRate();/*Timer timer = new Timer();timer.schedule(new count(writer), 0, 5000);//每过5秒调用新建一个count类并且将writer传入。}*//*** 以固定周期频率执行任务* @throws IOException */public static void executeFixedRate() throws IOException {writer = new FileWriter(fileName, true);ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);executor.scheduleAtFixedRate(new count(writer),0,5000,TimeUnit.MILLISECONDS);}static class count implements Runnable{private FileWriter writer = null;//设置日期格式private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");count(FileWriter writer){//构造函数this.writer = writer;}public void run(){//运行代码   try {writer.write("Bolt"+addGridNo.indexId+" From Grid and GPS "+"<"+df.format(new Date())+">strom_flow,<"+addGridNo.countGrid()+">,<"+transGPS.countGPS()+">\n");writer.flush();} catch (IOException e) {// TODO Auto-generated catch block
                e.printStackTrace();}}   }
}

某一个需要统计的bolt中的代码

package bolt;import java.io.FileWriter;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;import backtype.storm.Config;
import backtype.storm.Constants;
import backtype.storm.task.OutputCollector;
import backtype.storm.task.TopologyContext;
import backtype.storm.topology.OutputFieldsDeclarer;
import backtype.storm.topology.base.BaseRichBolt;
import backtype.storm.tuple.Fields;
import backtype.storm.tuple.Tuple;
import backtype.storm.tuple.Values;
import topology.topo;/*** @author ZPF**/public class addGridNo extends BaseRichBolt {private static final long serialVersionUID = -6586283337287975719L;public static int numOfGrid = 0;private static FileWriter writer = null;private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");private static String fileName = "/home/storm/testflowgrid";//定义写文件路径private OutputCollector collector;public static int countGrid(){return numOfGrid;}@Overridepublic void prepare(Map config, TopologyContext context, OutputCollector collector) {       this. collector = collector;}@Overridepublic void execute(Tuple tuple) {topo.numOfGrid++;numOfGrid++;String line = tuple.getString(0);    synchronized (collector){ collector.emit(new Values(line.toString()));}    synchronized (collector){  collector.ack(tuple); }synchronized (collector){ collector.fail(tuple);}}@Overridepublic void declareOutputFields(OutputFieldsDeclarer declarer) {declarer.declare(new Fields("GPSWithGridNo"));}
}

最后在topo的main函数中需要bulid一个topology。然后设置该topology的属性，以及指定读取数据的路径，数据采用何种分发方式，topology的并发数目为多少等相关设置。

另外一种统计的方法

package bolt;import java.io.FileWriter;
import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;import topology.topo;
import backtype.storm.Config;
import backtype.storm.Constants;
import backtype.storm.task.OutputCollector;
import backtype.storm.task.TopologyContext;
import backtype.storm.topology.OutputFieldsDeclarer;
import backtype.storm.topology.base.BaseRichBolt;
import backtype.storm.tuple.Fields;
import backtype.storm.tuple.Tuple;
import backtype.storm.tuple.Values;/*** * 实现日志编写* author ZPF* */public class transGPS extends BaseRichBolt{private static final long serialVersionUID = -5653803832498574866L;public static int numOfGPS = 0;//统计计算GPS的次数 numOfGPSprivate static FileWriter writer = null;private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");private static String fileName = "/home/storm/countflow";//定义写文件路径private OutputCollector collector;  public void prepare(Map config, TopologyContext context, OutputCollector collector) {  this. collector = collector;  }/** 返回统计次数*/public static int countGPS(){return numOfGPS;}@Overridepublic void execute(Tuple tuple) {addGridNo.numOfGrid = topo.numOfGrid;numOfGPS = topo.numOfGPS;try {if(isTickTuple(tuple)){writer = new FileWriter(fileName, true);String str = null;writer.write("{\"time_stamp\":\"" +df.format(new Date())+ "\",\"process_name\":\"" + "strom_flow" + "\",\"from_kafka:"+addGridNo.numOfGrid+"\",\"to_redis:"+topo.numOfGPS+"}\n");//writer.write("Grid and GPS "+df.format(new Date())+",strom_flow,"+topo.numOfGrid+","+topo.numOfGPS+"\n");
                writer.flush();}else{numOfGPS++;topo.numOfGPS++;String line = tuple.getString(0);//json格式synchronized (collector){collector.emit(new Values(line.toString()));}    synchronized (collector){  collector.ack(tuple);  }synchronized (collector){  collector.fail(tuple);  }}}catch (IOException e1) {e1.printStackTrace();}}@Overridepublic void declareOutputFields(OutputFieldsDeclarer declarer) {declarer.declare(new Fields("GPS02"));}@Overridepublic Map<String, Object> getComponentConfiguration() {Map<String, Object> conf = new HashMap<String, Object>();conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 5);//每5s持久化一次数据return conf;}
//    @Override
//    public void cleanup() {
//
//        // TODO Auto-generated method stub
//
//        try {
//            writer = new FileWriter(fileName, true);
//            String str = null;
//            writer.write("{\"time_stamp\":\"" +df.format(new Date())+ "\",\"process_name\":\"" + "strom_flow" 
//                            + "\",\"from_kafka\":"+topo.numOfGrid
//                            +"\",\"to_redis\":"+topo.numOfGPS+"}\n");
//            //writer.write("Grid and GPS "+df.format(new Date())+",strom_flow,"+topo.numOfGrid+","+topo.numOfGPS+"\n");
//            writer.flush();
//            addGridNo.numOfGrid = topo.numOfGrid;
//            numOfGPS = topo.numOfGPS;
//
//        } catch (IOException e) {
//
//            // TODO Auto-generated catch block
//
//            e.printStackTrace();
//
//        }
//
//    }public static boolean isTickTuple(Tuple tuple) {return tuple.getSourceComponent().equals(Constants.SYSTEM_COMPONENT_ID)&& tuple.getSourceStreamId().equals(Constants.SYSTEM_TICK_STREAM_ID);}    }

出现的问题：

　　日志的多次重写以及时间戳的延时问题。

分析已知结果：

　　已知的问题以及出现的结果：

numOfGrid以及numOfGPS以及其他的变量目前都是声明为静态私有变量，这里numOfGrid和numOfGPS无论声明在bolt中还是topo中都是可以正确得到答案。
目前使用的统计方法。为了实现5秒向文件写一次数据。现在大致可以分为两种方法。一种是在提交topo之后开启一个线程进行统计和写入读入的数据条数。另一种方法是使用静态的函数，函数在bolt被调用。
每一个bolt都可以产生多个task，这是从网上摘过来的，因此在一个bolt的prepare中运行的代码其实不只是运行了一次，到底是每一个task都运行了这个prepare还是在每一台机器上都运行了这个prepare程序？如果运行次数不止一次的话，那么向文件中写入的线程或者静态程序就不仅仅开启或者调用了一次，那么就可以解释了为什么产生了文件的多次读写操作！！！
当一台机器出现故障，经常的是storm3崩溃了。那么最终的统计结果肯定出现问题。至于结果是否可以简单地相加，现在还是不清楚。为什么不清楚能不能简单的相加呢？其一是不知道线程究竟开启了多少个或者静态的统计函数究竟调用了多少次！另外如果简单的将重复的数据忽略的话，并且三台机器能够正常运行，那么最后的结果经过另外自己开启的一个topic测试过，消费的数据和压入的总数据的条数相等。但是一台机器崩溃结果就不等于topic中的总数据条数！！
老师上课提到了线程安全问题，那么根据网上的讲解来看，将变量全部设置为全局静态变量这肯定是有问题的。如果将代码修改为可重入函数的话应该就可以解决文件重写这个问题。那么这个角度来看，前提是线程开启的不止一个，而是多个。但是，如果不将变量设置为全局变量的话，只是为局部变量又需要怎么修改来实时统计处理数据的条数呢。或者只是在topo中设置全局变量，每次将局部变量传给外部，但是这还是有全局变量啊。
查看手册调用数量！！！

　　emitted栏显示的数字表示的是调用OutputCollector的emit方法的次数.

　　transferred栏显示的数字表示的是实际tuple发送到下一个task的计数.

　　如果一个bolt A使用all group的方式(每一个bolt都要接收到)向bolt B发射tuple, 此时bolt B启动了5个task, 那么trasferred显示的数量将是emitted的5倍.

　　如果一个bolt A内部执行了emit操作, 但是没有指定tuple的接受者, 那么transferred将为0.

　　另外collector.emit(new Values(xxx))和collector.emit(tuple, new Values(xxx)) 这两种不同的emit方法也会影响后面bolt的emitted和transferred, 如果是前者, 则后续bolt的这两个值都是0, 因为前一个emit方法是非安全的, 不再使用acker来进行校验.

分析造成该结果的原因：

clip_image001

clip_image002

clip_image003

Storm与传统关系型数据库

传统关系型数据库是先存后计算，而storm则是先算后存，甚至不存

传统关系型数据库很难部署实时计算，只能部署定时任务统计分析窗口数据

关系型数据库重视事务，并发控制，相对来说Storm比较简陋

Storm不Hadoop，Spark等是流行的大数据方案

与Storm关系密切的语言：核心代码用clojure书写，实用程序用python开发，使用java开发拓扑

　　来自 <http://www.open-open.com/lib/view/open1430095563146.html>

　　Storm集群中有两种节点，一种是控制节点(Nimbus节点)，另一种是工作节点(Supervisor节点)。所有Topology任务的提交必须在Storm客户端节点上进行(需要配置 storm.yaml文件)，由Nimbus节点分配给其他Supervisor节点进行处理。 Nimbus节点首先将提交的Topology进行分片，分成一个个的Task，并将Task和Supervisor相关的信息提交到 zookeeper集群上，Supervisor会去zookeeper集群上认领自己的Task，通知自己的Worker进程进行Task的处理。

和同样是计算框架的MapReduce相比，MapReduce集群上运行的是Job，而Storm集群上运行的是Topology。但是Job在运行结束之后会自行结束，Topology却只能被手动的kill掉，否则会一直运行下去

Storm不处理计算结果的保存，这是应用代码需要负责的事情，如果数据不大，你可以简单地保存在内存里，也可以每次都更新数据库，也可以采用NoSQL存储。这部分事情完全交给用户。

数据存储之后的展现，也是你需要自己处理的，storm UI 只提供对topology的监控和统计。

总体的Topology处理流程图为：

clip_image004

来自 <http://www.open-open.com/lib/view/open1430095563146.html>

clip_image005

Bolt类接收由Spout或者其他上游Bolt类发来的Tuple，对其进行处理。Bolt组件的实现可以通过继承BasicRichBolt类或者IRichBolt接口等来完成

prepare方法 -- 此方法和Spout中的open方法类似，在集群中一个worker中的task初始化时调用。它提供了bolt执行的环境

declareOutputFields方法 -- 用于声明当前Bolt发送的Tuple中包含的字段(field)，和Spout中类似

cleanup方法 -- 同ISpout的close方法，在关闭前调用。同样不保证其一定执行。

execute方法 -- 这是Bolt中最关键的一个方法，对于Tuple的处理都可以放到此方法中进行。具体的发送是通过emit方法来完成的。execute接受一个 tuple进行处理，并用prepare方法传入的OutputCollector的ack方法（表示成功）或fail（表示失败）来反馈处理结果。

来自 <http://www.open-open.com/lib/view/open1430095563146.html>

尝试解决文件多次重写：

　　1.由于程序运行在三台不同的机器上，在进行多线程操作时，程序是否是安全的很关键！

使得rand函数变为线程安全的唯一方式是重写它，使得它不再使用任何静态数据，取而代之地依靠调用者在参数中传递状态信息。这样的缺点是，程序员现在要被迫改变调用程序的代码。

　　来自 <http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html>

　　该问题的详细描述：http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html

　　某些函数（如gethostbyname）将计算结果放在静态结构中，并返回一个指向这个结构的指针。如果我们从并发线程中调用这些函数，那么将可能发生灾难，因为正在被一个线程使用的结果会被另一个线程悄悄地覆盖了。

　　有两种方法来处理这类线程不安全函数。一种是选择重写函数，使得调用者传递存放结果的结构地址。这就消除了所有共享数据，但是它要求程序员还要改写调用者的代码。

　　如果线程不安全函数是难以修改或不可修改的（例如，它是从一个库中链接过来的），那么另外一种选择就是使用lock-and-copy（加锁-拷贝）技术。这个概念将线程不安全函数与互斥锁联系起来。在每个调用位置，对互斥锁加锁，调用函数不安全函数，动态地为结果非配存储器，拷贝函数返回的结果到这个存储器位置，然后对互斥锁解锁。一个吸引人的变化是定义了一个线程安全的封装（wrapper）函数，它执行lock-and-copy，然后调用这个封转函数来取代所有线程不安全的函数。

　　线程安全：一个函数被称为线程安全的（thread-safe），当且仅当被多个并发进程反复调用时，它会一直产生正确的结果。如果一个函数不是线程安全的，我们就说它是线程不安全的（thread-unsafe）。我们定义四类（有相交的）线程不安全函数。

　　第1类：不保护共享变量的函数

　　第2类：保持跨越多个调用的状态函数

　　第3类：返回指向静态变量指针的函数

　　第4类：调用线程不安全函数的函数

　　可重入函数

　　可重入函数：可重入函数是线程安全函数的一种，其特点在于它们被多个线程调用时，不会引用任何共享数据。可重入函数通常要比不可重入的线程安全函数效率高一些，因为它们不需要同步操作。更进一步说，将第2类线程不安全函数转化为线程安全函数的唯一方法就是重写它，使之可重入。

来自 <http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html>

2.也许将写文件的函数写为可重入函数可能会解决问题！！！

显式可重入函数：如果所有函数的参数都是传值传递的（没有指针），并且所有的数据引用都是本地的自动栈变量（也就是说没有引用静态或全局变量），那么函数就是显示可重入的，也就是说不管如何调用，我们都可断言它是可重入的。

隐式可重入函数：可重入函数中的一些参数是引用传递（使用了指针），也就是说，在调用线程小心地传递指向非共享数据的指针时，它才是可重入的。例如rand_r就是隐式可重入的。

我们使用可重入（reentrant）来包括显式可重入函数和隐式可重入函数。然而，可重入性有时是调用者和被调用者共有的属性，并不只是被调用者单独的属性3002

3.根据task的ID进行实时计算，每次统计每一个task处理的数据，然后将task的统计结果发送给外部的统计函数，可能解决重写问题！！！

当数据量大到一定程度时就要使用并发，当并发需要考虑容错与事务性时处理逻辑又会变得复杂起来。在Storm中，每个bolt可以启动多个task，每一个task会有一个唯一的task ID。当需要持久化操作时，每个task必须把自己的中间状态连带自己的task ID一起持久化下来，而在故障恢复时，每个task只从数据库中读取属于自己的状态数据，否则很容易导致内存溢出。再加上有些业务逻辑要求多个task的数据必须在数据库中一起commit，这又增加了复杂性。

来自 <http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html>

但是这里面临着问题：task ID是变化着的，如果某次程序崩溃，重启之后发生错误。

如果在使用并发时想动态地调整并发数，那需要增加很多额外的处理逻辑。因为Storm默认的fieldsGrouping是根据并发数进行Hash计算取模。如果并发数变动，那么每个数据流应该分配到哪个task中也就发生了变动。在故障恢复时，如果并发数发生了变化，每个task的task ID也会发生变化，这会导致一个task从数据库中读取不到本来属于自己的那部分中间状态数据。这时需要采用一致性Hash策略来解决该问题。

来自 <http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html>

　　但是根据上面提出的各种方案，经过尝试都失败了！

找出为何失败以及文件重复读写是否真的是个错误。

　　首先，解释文件重写出现的原因：

　　无论是使用线程还是使用静态的方法都是需要再bolt中的prepare函数中进行调用。根据上述对storm的运行以及结构分析，可以得到在分布式系统上的运行并不只是一台机器上简单的日志统计而言。原因就在于storm采用分布式系统进行数据的处理操作。那么函数的调用次数以及线程的开启个数一定不会等于1。这一点需要十分注意！！！分布式系统并不是在一台机器上跑，而且分布式系统在此而言是相对独立的。而且我们自己无法提前将任务经行分配，比如说这一台机器跑几个，另一台机器跑哪些。所以出现文件的重复写入是难以避免的，而且是正常的。

　　通过上面的分析，以及对storm的结构分析。这里已经可以确定之前的判断是不对的。对于起初怀疑文件重写是个错误的假设已经被证实是不对的。那么除此之外，在代码书写过程中，还有几点需要注意。

　　接下来需要解决的问题：

除了之前错误认为的文件重写之外，存在的另外一个问题就是时间戳的延迟问题。举一些实际运行得到的结果：

{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

上面的运行结果是在设置每5秒进行写入文件。但是时间戳这里产生了问题。说明重复写入过程中存在严重的延时。那么接下来的工作除了合并重写的数据之外还要降低延时。

接下来就是合并重复数据，以及降低延时的处理了。

分布式系统的确不好考虑，问题各种各样的。

这篇关于Storm中遇到的日志多次重写问题（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！