Kafa 教程-0 认识Kafa

一步一步给学习使用Kafa的码友们。如有错漏，欢迎指正。

 

预览下Kafa涉及名词：

log：所以说Kafa是日志形的，消息是存储在log中，log是最简单的数据存储格式，他只会append、append、append...

offset：偏移，表示消息在log中的位置，offer越低，被消费的越早

topic ：消息的归类

partion：分区，每个Topic都有固定大小的若干分区，分区个数不限，消息其实是存在partion中

producer：生产者

consumer：消费者

queuing：队列模式，消息只会通知给消费者中的一个

publish-subscribe：发布订阅模式，消息会发布给所有消费者

Consumer Group：消费者组，每个消费者可以标记自己属于哪个组，按组来订阅的消息，同一个组内只会有一个消费者收到消息，就是说，同组内的消费者是队列模式。这表明，订阅者可以是集群并灾备的模式。

1、Kafa是集群分部式的，工作模式如下图

 

2、Kafa里一个类型的消息叫做Topic，Topic包含很多Partition，在集群分部的时候，有一个Server是leader，用于被读写，这个Leader角色的Partion可能有0或多个复制分别在其他Server上，这是灾备策略，如果Leader当机，会自动决策出下一个leader。还有另一个好处，比如Topic_A有Partion_0、Partion_1 两个Partion，他们各自的Leader分别在集群Cluster的两个服务Server0、Server1上，那么对Topic_A的读写请求，会被均衡的负载到两个Server上了，当Topic很多的时候，这种灵活的负载均衡好处就出来了，同时相对Partion0和Partion1各自的备份分别在Server1、Server0上。

3、Kafa有queuing和publish-subscribe两种模式结合来使用，加上用户组的概念，就可以灵活的、健壮的搭建出消费者集群。比如，有两个客户端消费者Consumer0、Consumer1属于Group_A_0，Group0订阅了上面说的Topic_A，那么可以分配Consumer0消费Partion_0，Consumer1消费Partion_1，Kafa这种设计，天然的支持了消费者多线程的、并发的来消费消息，不会出现传统的消息框架中这样的问题：两个同组的消费者同时请求消息队列要拿消息，那么队列为了保证数据准确性，就必须在同组消费者消费的时候给消息上锁，还要在不同组之间的消费者消费时候不上锁，上锁之后还就不能支持并发只能单线程，种种繁琐效率也低。Kafa通过Topic下分区Partion，并根据消费者组概念，同组内的消费者因为职能一样(其实在消费者也就是客户端部分采用了集群+并发+灾备这种想法，高性能的同时便于扩展和容错)，按照分区Partion各自分配各自同时消费，互不影响同时进行。

但是！但是！但是！这里千万注意，用的时候，同组的Consumer个数，不可超过所订阅的Topic下的Partion个数。

4、再说说Kafa对数据安全性的保证：

     1、保证消息的生产、消费顺序，同一个Producer发布的消息，在log中肯定按照发布时的时间顺序排列，如果消息M1先发送，M2后发送，M1就拥有更低的偏移，并在log中更早的会被消费掉。

     2、保证消息的可读性，保证消费者实例能获取到log中存在的消息。

     3、保证消息的完整性，如果一个Topic的复制因子(就是partion复制的份数)为N，我们会最大容忍到N-1个服务当机，但是依然保证不会丢失任何一个提交到log里的消息。

 

到底怎么开始使用Kafa，回头再说。