zk kafka常识

-5 偶数个zk节点数

假如zk有6个节点，根据过半存活集群就可提供服务的特点，最少要 4个节点，也就是最多挂2个节点；

但是5个节点也可以最多挂2个节点；相比较之下，当然少投入 一台服务器更好

-4 zk的四字母命令

zk启动之后, 可以通过telnet (nc 亦可) 向zk提交相应的命令,比如:

conf
输出相关服务配置的详细信息。
cons
列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump
列出未经处理的会话和临时节点。
envi
输出关于服务环境的详细信息（区别于 conf 命令）。
reqs
列出未经处理的请求
ruok
测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。
stat
输出关于性能和连接的客户端的列表。
wchs
列出服务器 watch 的详细信息。
wchc
通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch 相关的会话的列表。
wchp
通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。

-3 如何利用kafka topic存储配置

可以参考kafka mirror maker2 的代码 org.apache.kafka.connect.storage.KafkaConfigBackingStore
这里有2个关键点:

• 存储配置的topic ,只有1个分区(为了保证顺序性)
• cleanup.policy=compact, 即不会删除分区数据,但是会"压实"数据

-2 如何查看kafka的__consumer_offsets内容

./kafka-console-consumer.sh --bootstrap-server 10.10.10.10:9092 --topic __consumer_offsets --partition 0 --from-beginning --formatter 'kafka.coordinator.group.GroupMetadataManager$OffsetsMessageFormatter'

-1 如何将ZK集群变成单ZK

比起how, 这个场景更有意思的是 why.
笔者经常要手动维护线下的ZK 机器, 有时ZK集群 3个节点,挂了2个,那整个集群都不可用.但恢复挂掉的这2台有时没那么快, 尤其是 云主机有问题时.为了不影响用户使用,可以将存活的节点的配置改成单个节点(standalone)模式启动.
当客户端重启将能正常连上来,至少先顶一阵子…

0 暴力强杀所有的测试机器上的java进程

因为线下的kafka集群在部署时经常是一个kafka 进程 + 一个ZK进程, 三台成一个集群, 线下维护往往不要数据了, 直接暴力地杀所有进程,清所有数据,然后重建.

ps -ef|grep java|grep -v "grep"| awk '{print $2}' |xargs kill -9;

1 清除日志

ls |grep "controller"|grep -v -x "controller.log" |xargs rm -rf;
ls |grep "log-cleaner"|grep -v -x "log-cleaner.log" |xargs rm -rf;
ls |grep "server"|grep -v -x "server.log" |xargs rm -rf;
ls |grep "state-change"|grep -v -x "state-change.log" |xargs rm -rf;
ls |grep "gc"|grep -v "current" |xargs rm -rf;
ls |grep "kafka-audit"|grep -v "kafka-audit.log" |xargs rm -rf;

2 如何利用Zk 的客户端手动设置带换行符的节点内容

./bin/zkCli.sh set /default/bootstrap "`cat b.txt`"

如该命令, 把要写入ZK节点的内容先写到一个文本中,然后执行.本质就是把文本内容读到,写到ZK中.

3 如何整改kafka集群中的一台机器?

比如一个集群10台机器,有一条我们想换掉,怎么玩? 这里给出一个方案:

1、找新机器先部署好环境，主机名和配置文件(主要是id)和被替换机器一样。
2、被替换机器broker关闭，dns上把域名切到替换机器
3、新机器启动，代替原id的机器恢复服务，数据等它自然追上（如果数据比较多先拷过去都行，数据少自己去追）
但要注意某些地方会长期缓存dns指向(理论上应该极少)

不过还有一个更稳的办法:

1. 先将producer 迁移到新集群
2. 等旧集群上消息消费完了
3. 再把consuemr迁移到新集群.
   这种做法需要 公司基础架构的消息SDK能够动态响应参数