在这一节中就主要讲讲kafka模型的构成和其中的一些概念，如主题（topic）、分区（Partition）、生产者、消费者。
如果让我们设计存储存储消息的系统时，一开始可能是这样的
一个消费者的情况下这样的架构并没有什么问题，现在假设原有的消费者为A模块，现在增加B、C模块也要加入我们的系统，也要消费全部消息，那怎么做呢？你可能会说这简单，把每份数据复制三份推给各个模块就好了，这里就有个问题了，如果要继续新增模块，就意味着 消息队列系统 要随时为其他系统做出改变了，这与中间件的理念不符合。还存在的一个问题就是如果A、B、C三个模块需要的消息都是不同的，那么把所有数据都复制几份，那不是浪费系统资源么？
所以我们就想着消息队列系统应该是要符合按需取各自的消息的且并不用关心子系统的存在。
于是有了第二版的设计
这个模型有个术语叫 发布-订阅 模型
这里存在三个角色：
1.发布者（publisher），消息的发送方
2.订阅者（subscriber）,消息的接收方
3.主题（主题），存放消息的容器。
发布者将消息发送到主题中，接收方在消费消息之前必须订阅主题。
这就解决了上边说的所有数据复制几份资源的问题。
然后订阅这一动作是客户端主动，主题无需预先知道由几个客户端的存在。
那第2版的模型就可以了吗？答案是否定的。
为了避免消息的丢失，当消费者消费完一条消息后会发送一个确认码给broker，只有当broker收到确认码后才认为一条消息被成功消费了。在这里就出现有一个矛盾的问题了，消息的消费是有序的，先进先出，又要保证消息的不丢失，那么就变成了同一时刻，任意多台消费者都只能有其中一个在消费，其他都处于等待之中，这就变成了消息队列反而成为了掣肘我们系统的短板.
(B系统部署了多个节点，想提高消费的性能)
那Kafka是如何解决这个问题的呢？
我们来看这张图。
Kafka一个Topic下边有多个分区，只在 分区 上保证消息消费的有序性，也就是说分区之间是独立的，消费者在消费分区一的时候，其他消费可以消费分区二、分区三，这样就可以提高整个系统的吞吐量了，同时也可以扩展消费者的数量来提高消费模块的处理性能了（需对应扩容分区数量）。图片懒得画整体的了，直接看关键的
下面是kafka官网上的模型图
那既然有那么多分区，那我们应该如何来保证一些消息的被顺序消费呢，其实上边已经说了，在分区上严格保证消息的顺序性消费，那么只要把要保证消费顺序的消息路由到同一个分区就好了。举个例子，当用户点击购买时，后台会生成一个订单，在用户扣款成功后，并且将订单数据发送到消息队列后，在用户看来就是成功购买了，但是对于对系统来说这仅仅是一个开始，会有很多其他逻辑。假设用户此时发起取消订单，这就要求保证前后两条消息由严格的顺序了，我们可以把订单号进行hash得到分区号，这样就可以保证同一个订单号不管是生成、修改还是取消都能分发到同一个分区，必然能保证严格的消费顺序了。
分区与消费者的关系：
分区与生产者的关系：
分区与消费者组的关系：
