Kafka various components
Broker (a kafka node)
Each node is called a kafka Broker, or a plurality of kafka may be deployed on a server node (in the example of FIG only deploys a), then the nodes connected to the registry, to form a cluster kafka.
Topic
That theme, kafka message is categorical in, such as user behavior log type, the type of payment orders, billing and other data types, different types of messages can be specified at the time of production sent to different Topic years.
On a Broker can create one or more Topic. The same topic can be distributed across multiple Broker in the same cluster.
Partition
Each Topic the Partition into one or more, each partition is mapped to a logical log (log) file is stored in the real cell kafka message.
Whenever a message is posted to a partition on a topic, broker should be appended to the message on the last segment of the logical log file. These segments are flush to disk. It can be carried out according to the time when Flush, can be performed in a number of message.
每个partition都是一个有序的、不可变的结构化的提交日志记录的序列。在每个partition中每一条日志记录都会被分配一个序号——通常称为offset，offset在partition内是唯一的。论点逻辑文件会被化分为多个文件segment（每个segment的大小一样的）。
也就是说在kafka中虽然消息是无序的，但是发送到同一个partition上的消息是有序的。
看到这里，你可能会以为服务器1上的topic2和服务器2上的topic2和服务器3上的topic2包含的Partition是一样的，但其实并不如此。
假设一个topic分为4个Partition，**kafka内部会根据一定的算法把这4个Partition尽可能均匀分布到不同的服务器上。同一个Partition会分配到同一个topic所在的多个服务器上。这样做是为了容灾。具体会复制几份，会复制到哪些broker上，都是可以配置的。**比如：
服务器1负责topic2的Partition1、Partition2，Partition4
服务器2负责topic2的Partition1、Partition3，Partition4
服务器3负责topic2的Partition2、Partition3
为了方便，我在每个broker中只画了一个topic。
那么对于每一个Partition实际上都有2个备份。
Kafka的架构优点
看了上面，相信你已经对kafka的架构有所了解了，其实这种奇妙的架构，笔者也是第一次遇见。那么为什么称为奇妙，而不叫奇怪呢？是因为这种架构是有很大的优点的。kafka是不支持读写分离的，也就是说，不管是写还是读，都是发送到主节点。只不过在kafka中的主节点，并不是我们传统意义上的实体服务器，而是一个Partition。前面讲过了，生产者生产数据和消费者接收数据，实际上都是和topic里面的Partition打交道。
我们假设上图中标红的Partition为主节点，那么这个时候生产者生产数据和消费者消费数据是怎样的流程图呢？
在kafka中，生产者生产的数据会采用一定的算法分配到不同的Partition上，当数据量足够大的时候，每个Partition的负载压力是差不多的，对于上图，可能服务器2的负载压力会大一点，那是因为 我懒的画图 有两个主节点在在这台服务器上，在实际环境中，我们可以尽可能的均匀分配主节点，这样每一台服务器的压力就差不多了。
总结
可以看出kafka的奇妙架构以及这种架构带来的优势，当然在某些情况下可能会带来负载不均衡，但我们也可以通过调整来避免这些情况，详细可以看这篇文章
总的来说，Kafka 只支持主写主读有几个优点：
可以简化代码的实现逻辑，减少出错的可能;将负载粒度细化均摊，与主写从读相比，不仅负载效能更好，而且对用户可控;没有延时的影响；
在副本稳定的情况下，不会出现数据不一致的情况。为此，Kafka 又何必再去实现对它而言毫无收益的主写从读的功能呢？这一切都得益于 Kafka 优秀的架构设计，从某种意义上来说，主写从读是由于设计上的缺陷而形成的权宜之计。
