The Mirages

最近碰到一个kafka流量引发的故障。期初的现象是我们有些consumer超时。于是去看了下kafka broker的日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[2020-XX-XX YY:35:51,703] WARN [ReplicaFetcherThread-0-0], Error in fetch kafka.server.ReplicaFetcherThread$FetchRequest@712892d4 (kafka.server.ReplicaFetcherThread)
java.io.IOException: Connection to 0 was disconnected before the response was read
	at kafka.utils.NetworkClientBlockingOps$$anonfun$blockingSendAndReceive$extension$1$$anonfun$apply$1.apply(NetworkClientBlockingOps.scala:87)
	at kafka.utils.NetworkClientBlockingOps$$anonfun$blockingSendAndReceive$extension$1$$anonfun$apply$1.apply(NetworkClientBlockingOps.scala:84)
	at scala.Option.foreach(Option.scala:257)
	at kafka.utils.NetworkClientBlockingOps$$anonfun$blockingSendAndReceive$extension$1.apply(NetworkClientBlockingOps.scala:84)
	at kafka.utils.NetworkClientBlockingOps$$anonfun$blockingSendAndReceive$extension$1.apply(NetworkClientBlockingOps.scala:80)
	at kafka.utils.NetworkClientBlockingOps$.recursivePoll$2(NetworkClientBlockingOps.scala:137)
	at kafka.utils.NetworkClientBlockingOps$.kafka$utils$NetworkClientBlockingOps$$pollContinuously$extension(NetworkClientBlockingOps.scala:143)
	at kafka.utils.NetworkClientBlockingOps$.blockingSendAndReceive$extension(NetworkClientBlockingOps.scala:80)
	at kafka.server.ReplicaFetcherThread.sendRequest(ReplicaFetcherThread.scala:244)
	at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:229)
	at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:42)
	at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:107)
	at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:98)
	at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:63)

这里写着id为0的broker连接超时啊。那就重启id 0的broker了。可重启了之后发现如下日志了

1
2
3
4
5
6

[2020-XX-YY 14:13:27,728] INFO Partition [Event,196] on broker 1: Shrinking ISR for partition [Event,196] from 1,2 to 1 (kafka.cluster.Partition)
[2020-XX-YY 14:13:43,752] INFO Partition [Event,196] on broker 1: Expanding ISR for partition [Event,196] from 1 to 1,2 (kafka.cluster.Partition)
[2020-XX-YY 14:13:57,729] INFO Partition [Event,196] on broker 1: Shrinking ISR for partition [Event,196] from 1,2 to 1 (kafka.cluster.Partition)
[2020-XX-YY 14:14:16,304] INFO Partition [Event,196] on broker 1: Expanding ISR for partition [Event,196] from 1 to 1,2 (kafka.cluster.Partition)
[2020-XX-YY 14:14:37,510] INFO Partition [Event,196] on broker 1: Shrinking ISR for partition [Event,196] from 1,2 to 1 (kafka.cluster.Partition)
[2020-XX-YY 14:14:48,230] INFO Partition [Event,196] on broker 1: Expanding ISR for partition [Event,196] from 1 to 1,2 (kafka.cluster.Partition)

这里你看这一会儿Shrinking，一会儿Expanding。而且间隔时间相当的短，现在想来是很快的连接超时了。

这时候明显大家就慌了,远程办公就这点不好啊.

上篇有提到firewalld和iptables的区别。那就比较好奇firewalld的其他状态。

首先测试了22端口，这个端口在firewalld里是开放的，但是实际上机器上没有监听这个端口。这里我们看到，实际服务器返回的也是一个TCP-RESET。

然后又测试了一个被firewalld屏蔽的端口，实际服务器上也没有监听这个端口。这里我们可以看到返回的是ICMP的destination unreachable。

接着我们测试了一个被firewalld屏蔽的端口，实际服务器上监听了这个端口。这里我们可以看到返回的也是ICMP的destination unreachable。

最后我们直接屏蔽某个端口,发现也一样是返回ICMP的destination unreachable。

1
2
3

<rule family="ipv4">
  <port protocol="tcp" port="10050"/>
  <reject/>

在iptables中，我们一般封闭端口都是使用DROP参数，这样client端是不知道服务器已经DROP掉对应请求了，会继续进行等待，直到超时。

而像nc这种软件会根据这个其实是可以检测到服务器是否开启了这些端口。

但是我发现使用firewalld封闭后，用nc测试直接显示refused的

1
2
3

$ nc 202.96.209.5 29327 -v
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: No route to host.

而用iptables的话必须得是

1

# iptables -A INPUT -p tcp -m tcp --dport 29327 -j REJECT --reject-with tcp-reset

本文是「kafka权威指南」的第三章笔记。

在设置生产者之前我们先看看整个生产者到kafka broker的流程是怎么样的。

这个图是原文里的。

可以看到一个标准的ProducerRecord是必须要包含Topic和Value，然后Partition和Key是可选的。

从图中也可以看到，生产者需要把Key，Value序列化成数组，然后再去网络上传输。

如果record里有包含了Partition了，那就不需要分区器干活了，如果没有包含，那分区器就会根据record对象的key来选择一个分区。

选好分区之后，那生产者就知道往哪个topic和分区里发送记录了。然后这个记录就被添加到一个记录批次里，这个批次里所有消息都会被发送到相同的topic和分区上，这是由一个独立线程来处理的。

不知道从什么时候开始，就非常害怕爆炸了。

记得小时候我堂兄结婚，他们家放高升（二踢脚），好像直接把我吓的关屋里了，有没有钻床底下有点记不清了。

还有一次是在我爷爷家，不知道谁放了一个哑巴高升，可到最后居然落到我旁边表弟的头上就炸了，那场景我至今都可以很清晰回想起来。

要说怕这些吧，可还经常玩，可随着年龄的增加是越来越不敢玩了。

明明小时候经常放鞭炮的，还经常拿手里点着了直接扔出去放呢，但也失手过几次在手里直接炸了。

可现在看到气球有时候就比较恐惧，特别是当它飘向某个尖锐物体的时候，或者眼看着某人一脚踩下去的时候，都会有一种揪心的恐惧。

kafka这个服务是不怎么耗资源的，基本上没有特殊的要求，除了磁盘容量大点，别的要求真不高。

这个也是记录了「kafka权威指南」第二章内容

硬件

磁盘

• 磁盘吞吐量：大多数客户端在发送消息之后会一直等待到至少有一个服务器确认消息已经成功提交为止。这个通知基本就是leader发出的。而kafka本身由于使用了0拷贝和顺序读写的特性，因此速度是相当快的。HDD和SSD的差距我记得测试过就只有10%的差距。
  当然这个还是看自己的实际读写量了。
• 磁盘容量：这个就是自己topic一天的大小 * 副本数 * 保留天数 * 120% / broker数量， 这基本就是你每个服务器所需要的磁盘容量了。

内存

kafka现在是所有队列组件里最常用的，虽然跟Rabbitmq这些相比还缺乏一些特性，但是它实在是成长的太快了，而且支持集群化，这个是最赞的，同时由于使用0拷贝，日志追加，所以它的磁盘效率非常高。

但是kafka的运维难度前期并不大，但是在后期主要的难点是在扩容，缩容阶段。主要是因为磁盘IO，网络IO的原因。导致了很多瓶颈点产生。

本文是读了「kafka权威指南」第二章的一个摘要总结。

broker整体配置

log.dirs

kafka是把所有消息都写入到磁盘，这个参数可以指定多个目录进行消息写入。而写入的原则是最少使用原则。
但是我们在实际使用中，不建议写多个，宁愿使用raid，LVM条带方式来扩展单目录的写入速度。

话说这两天肺炎疫情突然紧张起来，可每个地区的行动力真的差别很大，有放羊的，也有跟踪到户的。

已知的什么河南，北京，上海这些基本都是跟踪到户。连小小球幼儿园老师都要要求大家每天上报情况和方位。而西城有些社区已经不让大家出门了，有事情社区来帮你解决，实在不行的社区还派车给你。就是为了防止无畏的扩散。

刚刚看了当年小汤山医院7天建成的故事，这基本上就是个奇迹，也只有在集中资源办大事的国度才可以完成。连图纸都没有，材料也没有的情况下，7天就建成了。

而当年新市长王岐山主要的工作也是切断传染源，整片整片的隔离。扩散才得到遏制，而随着夏天的到来，病毒的存活条件也不行了，这场战斗终于是结束了。下岗一个卫生部部长，一个北京市市长。

想到我司迁移邮箱的事情，邮件全体发送一次，QQ群每日提醒，微信群每日提醒，可至今依然有30%的账号没有任何迁移。

按说文档也不能说不详细，毕竟让行政，HR部门的女生都根据文档执行过了，已经非常详尽了。可还是无动于衷，而公司老板也是如此。这就实在让人难以想象了。

昨天一下午要给丈母娘备份手机，然后连接上iTunes后，提示空间不够。

于是就开始清理磁盘空间，于是开始rm -rf一堆东西。可用df 一看居然一点磁盘都没少。

看了下回收站也没有啊。du 所有目录也没有看见大的。

用mac的磁盘工具，发现就是使用了这么多。

走投无路的时候终于找到了一个。
https://zhuanlan.zhihu.com/p/31809578

原来mac用的APFS，会自动建立snapshot的。所以你的很多空间其实就是被snapshot占据的

设M={a|a=x²-y²,x,y∈Z},求证：

1. 2k-2∉M,(k∈Z)
2. 若p∈M,q∈M, 则pq∈M

第一题：
这是一道很简单的集合题目，但是我一开始看了半天也没思路，看了答案，发现居然看不懂。那就记录下吧。

由于x+y,x-y具有相同的奇偶性，所以x²-y²是奇数或者是4的倍数。 那这个所以是怎么来的呢？

如果x,y同为奇数或者偶数，那么它们的平方差一定是4的倍数，这个仔细想想还真是，因为都是平方。那如果x，y奇偶性不同，那么平方差一定是奇数。

所以4k-2∉M