微信bug后企业微信又崩溃了？

实验结果表明，注释器对上述任务的一致性很高:

单元格高亮显示的Fleiss Kappa为0.856，最终目标句子的BLEU为67.0。

结果分析涉及话题极其广泛，「体育和国家」占比最大

Google的研究人员对ToTTo数据集进行了超过44个类别的主题分析，例如体育和国家主题。

每个主题都包含一系列细粒度的主题，例如体育的足球/奥林匹克和国家的人口/建筑，这些共占数据集的56.4%。

另外44%的话题范围更广，包括表演艺术、交通和娱乐。
 

关于data-collect这个Java服务的核心逻辑我在这里详细说明一下。这个系统的代码是很早的一位同事写的，因为早期我们的数据体量还不是很大，所以，他采用了一种简单的处理方式。先消费数据，处理完成以后放到一个Map中，然后，启动了一个每10s执行一次的定时任务，定时任务读取Map数据更新到mongo中，然后清空Map(ConcurrentMap)。这样做的优点是将消费Kafka的操作和入库操作分开了，可以防止因为入库时间太长而导致消费速度变慢，但是，这种做法有一个致命的缺点：内存不可控。如果定时任务因为Mongo操作时间太长而没有及时清空Map，Map中会积累大量的数据，最终耗尽内存，系统发生OOM。这时候如果系统自启了，也会丢失大量的数据。

其实，这个问题我很早有意识到，但是系统一直运行良好，没有出现任何问题，我们认为在现有数据体量下它是安全的。而碰巧的是，就在前一天我们升级了Mongo的配置，mongo机器进行了一个主从切换。同时，有一些大表清理和TTL索引重建的工作还在mongo后台运行。这就导致了我们操作mongo耗时的增加。进而导致了我们一直认为安全的系统出现了这个问题。

回到data-collect这个系统的设计上。可能有的同学会在这里有个疑问，为什么不直接消费出来就入库操作呢?这里我们有一个重要的处理逻辑：为了防止频繁的更新mongo，我们会将消费出来的数据在内存中进行一个合并处理，你可以简单的理解为一个Map，如果key存在，我们就进行++的操作。最终操作mongo是$inc的操作，不是insert和update的操作。这也是我们需要一个ConcurrentMap的原因。也就是我们大概消费了1000万条数据，但是最终我们处理完成以后只有10万条数据，很多key相同的数据我们都进行了合并处理，这样我们mongo的操作就减少了很多。

data-collect发生了OOM，我只能第一时间重启，重启以后，消费正常，系统开始有了数据。但是大概运行了几分钟以后，又发生了OOM。原因很简单：kafka积压的了大量的消息，消费很快，但是异步如mongo太耗时，所以导致数据全部挤压在了这个Map内存中。看到这里，我想只能动手改造代码了。改造的最终要达到的结果是：系统在不发生OOM的前提下，消费积压在kafka中的数据，完成mongo操作。

改造的思路很简单，就是干掉定时任务。在消费kafka消息中增加一个逻辑，每当消费消息并且内存进行数据合并完成以后，我们判断Map的大小，如果Map的大小超过我们设定的限制以后，开始触发mongo操作。之前的代码mongo操作是单线程执行，为了提升mongo插入操作，我们开启20个线程并行执行，所以我们这里需要一个带阻塞队列的线程池。改造后的代码如下：
 

周日早上醒来，明媚的阳光从卧室的窗户直射进来，久违的好天气。穿好衣服我开始筹划今天去哪里转转。一周忙碌的工作几乎没有时间陪家人，今天该好好陪陪家人了。

当我起来收拾好一切准备出发的时候，我瞄了一眼手机，发现手机的邮箱里有一份报警邮件，报警邮件显示线上最近10分钟流量有异常，而且是多个渠道。有突然有一种不祥的预感：线上kafka出问题了。我让媳妇和孩子下楼在车里等我，我赶紧打开了电脑，查看线上系统。果然不出意外，kafka已经积压了几千万的数据。因为我们的业务分为实时数据和离线数据，实时数据是FileBeat负责收集日志发到Kafka，然后我们这个业务系统消费Kafka统计数据，实时数据对于当前流量分析、预算控制、熔断有非常重要的作用，如果实时数据异常，其它业务系统都会受到一定的影响。

定位到报警邮件是由于kafka消息积压而导致实时数据异常触发的，我立马连上了我们消费Kafka的业务系统(data-collect)。这是一个运行时间很长了的Java服务，它的作用就是实时消费kafka数据，然后经过一定的业务逻辑处理，将最终结果更新到mongodb中。进到服务器以后，我发现这个服务已经处于假死状态，最后一条日志显示系统发生了OOM，也就是服务器内存爆了。

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!