东哥和系统设计开荒小分队的基地
我们在之前的《Kafka基本架构和概述》中提到了Kafka的几个重要的组成部分，本文就来深入聊一聊其中的Producer的概念。 简介 我们知道要想使用Kafka，其实最开始就是要创建一个Producer来往其中写消息，可以称之为消息源头吧，没有Producer来写，也就谈不上后面的consumer读了。 写消息粗听起来很简单，但是我们仔细思考一下这里就有很多问题需要确认。比如你的应用可以接受某些消息没有成功写进去吗？或者能够接受有重复的消息被写入吗？亦或是你的应用对写入的速度和延时有要求吗？ 各种应用显然对我上面提到的问题有不同的答案，比如说一个log系统，丢一条或者少一条数据并不重要，延时一个几十秒甚至几分钟也不是什么大的问题。但假如是一个销售的系统，丢一条或者少一条销售数据可能就不行了。因此对于不同的应用，不同的要求，Kafka的producer可能都需要有不同的设置来进行匹配。...
我想大家对Kafka或多或少都有所耳闻，那么它究竟是什么呢？其实说白了也很简单，它其实就是一个分布式的消息队列，也就是我们通常所说的消息的发布和订阅，只是它的目标更倾向于高吞吐和低延迟。那我们就从头开始来看看Kafka究竟是如何诞生的。 发布/订阅消息 在正式开始聊Kafka之前，我们来看看什么是消息的发布和订阅。我们先来看这样一个例子：系统中有两个应用程序，然后我们有一个metrics的dashboard，当这两个应用程序开始运行时，会把相关的metric数据发送到dashboard所在的server，然后就可以把它们的metric显示出来，简单的架构如下所示： 这种架构看起来还是很清晰的，但是当我们的系统变得稍微庞大起来，有了更多的应用，也需要有了不同的metric处理方式，比如我们既需要显示metrics的数据到一个UI上，又需要分析这个metric或者根据metric的数据来做一些monitor发送alerts之类的，那整个系统就可能变得复杂起来，甚至有时你会觉得有一些系统，比如monitor其实并不需要你一直把metric发送过去，最好是做个poll的形式，让monitor主动找application来拿数据，于是你的系统变成了下面这样： 这样一来整个系统看起来就很乱，程序员的特性让你蠢蠢欲动，捋起袖子来refactor一下呗，你想啊想，要是能在中间加一层，让所有的应用端把数据都发送给这一层，然后对这个数据感兴趣的server再统一到这一层来拿就完美了，于是你的想法就变成了下面这样的一个架构：...
Follow:
More
Recent Comments