我们知道在kafka中有一个名词叫做HW(High Watermark)，但是具体这个高水位是用来做什么的呢？我们一起来学习下

无论是作为面试官，还是应聘者，我都接触过很多 Kafka 面试题。而在最近面试了很多候选人，发现写了熟悉Kafka，但是对于Kafka相关的知识却是只知道大概用处，简单搭建和使用。我想说，虽然我们是SRE(可靠性工程师)，但不论你是业务层的SRE还是基础设施层的SRE，我们都需要对业务方的使用场景有足够理解，或者对我们要提供的服务有足够的了解才行，这样你才能整体的保证你的业务连续性以及业务可靠性。因此，专门总结了如下经典的kafka面试详解。

在日常工作中，可能经常会遇到一些一致性需求，需要将本地代码和Git远端代码保持一致，因此这里就主要来记录一些Git的日常操作。 强制覆盖本地代

背景: 在日常工作中，我们经常会使用正则表达式来快速匹配和过滤一些我们期望的字符串来处理一些简单又繁琐的文字统计和过滤操作；而作为一名技术从业者，我们也经常会在程序中或者配置文件中使用正则表达式来处理字符或进行批量配置项的查询和更改，但通常情况下，我们需要对编写的正则表达式进行不断测试才能满足我们的需求，本篇文章带你重新回顾正则表达式，并分享一个在线的正则表达式工具(https://regex101.com/)，帮你在工作中快速测试你的正则表达式。

前言: 在大规模的使用kafka过程中，我们通常会遇到各种各样的问题，比如说，通常会有一些大数据集群中的Job发现总有几个task会比较慢，导致整体的任务迟迟不能完成运行，这种情况通常问题会比较复杂，想要知道具体延迟在哪里，我们需要知道在Kafka集群中哪些点可能会增加端到端的延迟。

接下来的内容翻译自confluent官网博客中的一篇文章，希望能够帮助大家理解kafka使用过程中端到端的延迟。99th Percentile Latency at Scale with Apache Kafka

背景: 如同其他分布式系统一样，在kafka集群中，单Topic的partition也并不是越多越好，但通常对于业务方来说，可能会简单的根据生产者或消费者的处理能力来提出扩partition的需求，此时就需要根据具体的场景进行分析以确定partition的数量。

对于Kafka集群承载的业务Topic来说，分区的数量，可以体现出整个业务的量级同时能够尽可能的提供更高的吞吐，但并不是越多的分区就意味着越高的吞吐和处理能力，通常情况下需要业务方和基础服务方一起来进行分析。

以下为多分区Topic的优缺点，可以适当根据需求和场景进行规划分区数量。

前言: 在kafka的集群运维操作过程中，我们需要通过一些工具来实现集群的高可用以及负载的平均操作，而对于kafka集群的SRE来说，需要掌握好如下几点，才能更好的维护和保证kafka集群服务的稳定性，可靠性和整体性能。