东哥和系统设计开荒小分队的基地
我们在之前介绍了很多Kafka的基础和进阶的知识，他们中很多都是服务于功能，性能或者可靠性的。而现代开发中有一个点也越来越被关注，那就是安全性相关的内容，本文就来聊聊Kafka在Security这个方面都做了些什么。 概述 在我们开始介绍security之前，先来看看几个专有名词，知道了它们对我们后面内容的理解会很有帮助。 Authentication：这个是用来鉴别身份，也就是表明你是谁。就像军队中说我是司令，我是团长，我是小排长之类的。 Authorization：这个用来判断你这个身份可以做什么。比如说司令可以号令全军，团长只能管你这个团。...
我们在之前聊到Kafka内部各个节点之间会通过replication来拷贝数据以保证high availability。现实中还有一些使用场景就是需要在不同的cluster之间连续拷贝数据，我们称之为mirroring，Kafka内部有实现这样的功能，这就是本文要来聊一聊的MirrorMaker。 使用场景 也许你会好奇，究竟有哪些使用场景会要用到MirrorMaker呢？我们来举几个例子中： 各地和中心cluster，有些公司在不同的数据中心拥有一个本地的cluster，很多时候应用只需要在一个数据中心进行处理就可以了，但是有时有某些应用希望访问多个数据中心的数据，比如说一个供应链的价格数据，每个数据中心都有他们本地的供给价格，然后我们又希望能有一个全公司的价格分析，这样就需要把所有数据中心的数据都复制到中心cluster进行分析处理。...
Kafka在可靠性这一块有很灵活的配置，我们可以根据自己的应用需求来设置相应的参数，有时候我们希望Kafka不要丢失message，但是不在意是否有重复的message，这个时候也许at least once的保证就足够了。当然对于我们通常来说的producer产生message，consumer消费message的应用来说，处理重复message还是很容易的，比如通过一些unique的id来进行判断是否是重复的信息等，但对于stream的process，比如说计算一些信息的平均值，这种process就很难去一个个看是否有重复的message了，这个时候就希望Kafka能够保证不要有重复的信息，这也就是本文要来聊一聊的Exactly once保证。 我们来简单想一想，如果让你来做，怎么才能做到exactly...
本周我们很开心邀请到Xing Wang给我们带来了《Kafka的介绍》的演讲，参与人数突破史高达到220+人，感谢大家的参与，相关总结如下： Slides Xing Wang使用的slides。...
我们都知道Kafka数据是可以持久化保存在磁盘上的，它在磁盘上最基本的存储单元是一个partition的replica，我们可以通过log.dirs参数来决定partition保存的文件目录，本文就来详细和大家聊聊Kafka是怎样使用这个目录保存文件的。 Partition的分配 当我们创建一个topic的时候，Kafka首先要做的事情就是如何为对应的partition分配空间。我们假设你的topic有10个partitions，每个partition有3个replication，然后总共有6个brokers。这也就意味着我们需要在6个brokers中申请30个partition replicas。一般来说，我们会遵循下面这些规则来进行分配： 让replica在broker中尽可能均匀地分布，比如我们的例子会希望每个broker有5个replica。...
我们知道Kafka的Client端可以发送各种请求给Broker，Broker在收到请求之后会进行相应的处理，然后返回response给对应的client，本文就来详细地聊一聊这个请求处理的过程。 概述 如我们上面提到，Client端会建立连接，然后发送request到broker，broker会进行处理再返回response到client。这里最基本的一个保证就是同一个client的不同request的处理是有序的，即先收到先处理。 整个请求的处理流程如下图所示： 简单来说，在broker中，当连接建立之后，会有一个Network的thread专门来接收从这个连接（client）发送过来的请求，当它收到请求之后，会把这个请求放到Request...
Replication这个词相信大家都不会陌生，在很多分布式系统中，我们都需要Replication来保证Availability和Durability，Kafka也不例外，它也是利用Replication来保证某个节点发生问题的时候仍然能够保证数据不丢失并正常工作。本文就来详细聊一聊Kafka中的Replication。 概念 我们在前面提过Kafka的数据是根据topic来组织的，每个topic可以有很多个partition，每个partition可以有多个replica。这些replica都保存在brokers上，每个broker可能保存成百上千个replica。总得来说有两种replica： Leader Replica：每个partition只能有一个leader...
我们在前面的文章中已经介绍了Kafka的基础部分包括Producer，consumer等基本概念，本文来稍微深入聊一聊Kafka内部Cluster的架构。这个部分的理解对我们Debug相关的问题会有很大的帮助。 Cluster成员 Kafka在3. 0版本之前使用的是ZooKeeper来进行管理broker的列表的。每一个broker都用一个唯一的ID来进行标识。当一个broker启动的时候，它会去ZooKeeper中利用它的ID来创建一个ephemeral node。其它的broker包括controller可以subscribe到/brokers/ids这个路径下，这样每次有新的broker加入或者删除的时候都可以得到通知。当然如果有同样的ID试图加入，也会有error信息报出。...
我们在《Kafka基础介绍之Consumer》中有提到可以使用poll函数来获取消息，而每次调用poll函数的时候，它返回的其实是Kafka中你这个consumer所在group还没有读的message。那这个还没有读是通过什么来判断的呢？它在Kafka中是通过offset来决定的，本文就来详细和大家聊聊Kafka中是如何通过offset来进行commit的。 概述 Kafka中consumer是通过offset来track每个partition中读的位置的，和一般的Queue的处理有些不同，在Kafka中你不需要每个message都进行commit，你可以一段一段地进行commit，也就是说假如Kafka收到你对offset 9的commit，那么它会默认你已经接受了9以前的所有的信息，而不需要你对8,7,6等都进行commit。 这种commit的方式在正常情况下是没有问题的，但是当出现我们以前提到的rebalance的情况，比如说consumer...
我们在前面的《Kafka基本架构和概述》中知道Kafka最基本的两个组成部分就是producer和Consumers，producer已经在之前的《Kafka基础介绍之Producer》中介绍过了，本文就来继续和大家详细聊一聊Consumers的概念。 Consumers和Consumer Groups 假如我们有一个应用需要从Kafka中读数据，并且把它写到一个data store中，我们首先就需要创建一个consumer的object，然后subscribe到对应的topic中，然后就可以开始接收数据了。这就是最基本的consumer形式，但是假如我们的数据写入的速度很快，而一个consumer处理不过来，这个时候就需要多个consumer一起来接收数据，我们把它称之为consumer...
Follow:
More
Recent Comments