前言

kafka作为高效的消息队列，其数据的维护也是十分重要的。有时候，我们可能存在对broker进行数据迁移，或者增加或者减少broker。对于我们已经创建了对topic。其配置不会随便进行更新。isr中依然存在着已经移除了对broker，这个时候，我们就需要更新它们的信息，告诉kafka数据分布的情况。并且在最少isr的问题到来之前，提前减少事故的事发。

linux 的文件描述符

文件描述符（FD:file descriptors），也可以说是文件句柄，当某个程序打开文件时，内核返回相应的文件描述符，程序为了处理该文件必须引用此描述符。文件描述符是一个正整数，用以标明每一个被进程所打开的文件和 socket。最前面的三个文件描述符（0，1，2）分别与标准输入（stdin），标准输出（stdout）和标准错误（stderr）对应，后面打开的文件依此类推对应 3、4…… 。

linux 系统对每个用户、进程、或整个系统的可打开文件描述符数量都有一个限制，一般默认为 1024。当我们在系统或应用的日志中碰到“too many open files”错误记录时，这个其实不是说打开的文件过多，而是打开的文件描述符数量已达到了限制，这时就需要增加文件描述符的数量限制了。

linux 的文件描述符

文件描述符（FD:file descriptors），也可以说是文件句柄，当某个程序打开文件时，内核返回相应的文件描述符，程序为了处理该文件必须引用此描述符。文件描述符是一个正整数，用以标明每一个被进程所打开的文件和 socket。最前面的三个文件描述符（0，1，2）分别与标准输入（stdin），标准输出（stdout）和标准错误（stderr）对应，后面打开的文件依此类推对应 3、4…… 。

linux 系统对每个用户、进程、或整个系统的可打开文件描述符数量都有一个限制，一般默认为 1024。当我们在系统或应用的日志中碰到“too many open files”错误记录时，这个其实不是说打开的文件过多，而是打开的文件描述符数量已达到了限制，这时就需要增加文件描述符的数量限制了。

前沿

B/B+树在数据存储上一直都是最高效的数据结构。B 树的概念比较清晰，但是 B+树的概念却有不同的解释。

开发笔记

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#define M (3) // B+树的阶数
#define LIMIT_M_2 (M >> 1) // M的中点
#define True (1)
#define False (0)
#define INDEX_NAME ("index") // 索引文件
#define SUCCESS (1)
#define ERROR (-1)
#define OPEN_MODE (O_RDWR | O_CREAT | O_TRUNC) // 打开文件的模式：可读可写打开 | 若此文件不存在则创建它 | 如果文件已存在，并且以只写或可读可写方式打开，则将其长度截断（Truncate）为0字节
#define FILE_MODE (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) // 文件的权限：660

typedef int KeyType; // 关键字的数据类型
typedef off_t Record; // 索引所对应的值

typedef struct BPTNode{
	int isLeaf;                // 是否是叶子节点
	int keynum;                // 关键字个数
	KeyType key[M + 1];        // 存放的关键字的连续内存
	struct BPTNode *ptr[M + 1];// 关键字子树的连续内存
	struct BPTNode *next;
	Record value[M + 1];       // 关键字对应的value，当节点为叶子节点的时候才有效
}BPTNode, *BPTree;

我们看到 BPTNode 是我们的节点结构体，这个结构体占用的内存大小我们计算一下：

记住内存对齐的原则，并且指针占用 8 个字节，off_t 一般是 64 位，占用 8 个字节

1

4(int)+4(int)+4(KeyType)*4(M+1)+4(*pts)*4(M+1)+4(*next)+8(Record)*4(M+1) = 4+4+16+32+8+32 = 96bytes

前言

目前 kafka 客户端在 php 中比较出名的仅有 2 个，这 2 个项目都有各自的利弊。在这里我选择几个来列一下

• weiboad/kafka-php
  • 协议非结构化封装，自定义性较强，不好维护
  • 目前的 API 在消费者中由于单例设计的原因，不允许在消费者中生产消息
  • 不支持多种压缩协议
  • 单进程“协程式”逻辑，数据未实现分离，容易堵塞消费
• arnaud-lb/php-rdkafka
  • 协议非结构化封装，自定义性较强，不好维护
  • 不支持多种压缩协议
  • 利用多线程，但是 PHP 对多线程对支持并不友好，相对于用 swoole 而言，劣势较为明显，容易出 bug，且维护性不高

基于以上几点，我们在基于swoole-4.3以上重新开发了kafka-swoole项目，优点如下：

• 多进程多核处理
• 支持 kafka 多个 sink 方式，实现拉取 kafka 数据和业务逻辑分离，从而不堵塞数据拉取
• 首个支持多种压缩方式（normal(不压缩)/gzip/snappy）的 php 客户端，从而在大吞吐对情况下减少带宽占用，提高传输速率
• 协议封装采用 OOP 的方式，结构化了协议的封装，利于维护和封装，对协议利用反射来统一封包和解包
• 利用协程来实现单个进程中对异步逻辑处理
• 提供了 runtime 的 rpc 命令，实时获取 kafka 成员进程对内部数据，实时查看消费情况
• 提供了 kafka 命令，方便获取 kafka 服务相关信息和 kafka 相关操作
• 在成员进程挂掉的情况下，记录错误信息，自动拉起。
• 对于常驻进程，不排除业务逻辑写出了内存泄漏的情况，所以所有的子进程都带有内存临界值重启机制来释放内存
• 主进程退出的情况下，发起了离开消费者组的请求，使得 kafka 能快速响应消费者组最新状态，从而更好平滑重新加入消费者

前言

目前 kafka 客户端在 php 中比较出名的仅有 2 个，但是其各有利弊，在这里就不展开详细说明了。因此，我们实现了一个叫kafka-swoole的项目，项目由swoole4.x协程+多进程实现，实现在串行化协程的基础上实现并行操作。

由于很多小伙伴对 kafka 并不是特别了解，所以在这里记录一下一些基础的 kafka 自带的命令使用方式

前言

犹豫公司的流式计算，并没有用类似于 Hadoop 的 mapreduce 机制或者 storm 或者 flink，是我们自研基于 erlang 的单节点服务，其优点就是：部署和迁移都十分简单，并且犹豫 erlang 的天然的良好的利用了多核 CPU 的优势，可以实现效率较高的大数据流式计算。但是由于其单机性，导致对单台机器的要求过于苛刻，并且不能进行扩展机器提高计算能力是其致命的缺点，所以目前我规划利用 golang，写一个支持分布式并行计算的服务，在此之前，了解了各大流式计算的基本思想，并且结合 golang 语言的特性，找到了一个叫glow的服务，想要写好一个分布式流式计算的服务，我们先来看看 glow 有什么好的借鉴的思想和思路。

前言

由于我们在服务器上编程或者调试的时候，都不可能是各种抓包客户端，所以我们需要学会运用 tcpdump 来对网络的数据进行抓包。
用简单的话来定义 tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。 tcpdump 可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供 and、or、not 等逻辑语句来帮助你去掉无用的信息。

前言

TCP 要保证所有的数据包都可以到达，所以，必需要有重传机制。

其中涉及 ACK 包比较关键，因为在窗口的这篇文章中，已经说过了，ACK 机制起始就是类似于一种反馈机制。