前言
在学习kafak之前，觉得kafaka 是个处理日志的高性能消息队列，正式学习后发现有些不同。
学习kafaka 真的很容易让人产生误解，因为这个鬼作者用的术语和我们经常接触的术语都有很大差异。
日志型
以前大概过了一下，以为看了他是个日志为主就认为他特长是处理日志，谁知道他所谓的日志是指mysql binlog (一种用于主从同步数据的日志),以这种类型的日志意味着我们在开发中也可以用这种形式来同步数据给其他系统，也就是俗称消息驱动的东西。
与RoketMQ的差异
实现上有很大不同，最明显的就是RoketMQ是实时处理，Kafaka则是批处理,这也就是kafaka 性能你最关键的原因.其他差异要理解就难了，因为很难因为两种都要始终过才能知道的细节。
安装docker kafaka 测试环境
zookeeper
kafaka
关键术语
- Broker
Kafka集群包含一个或多个服务器，这种服务器被称为broker - Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） - Partition
Partition是物理上的概念，每个Topic包含一个或多个Partition. - Producer
负责发布消息到Kafka broker - Consumer
消息消费者，向Kafka broker读取消息的客户端。 - Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
实战的核心
失败补偿(5、6、7消费5、6、丢失)
- 待补充
极端情况
- 会发生重复数据，需要注意,例如 P->Kafka A写入磁盘成功，down机，未通知生产方，在高可用场景下P会重复发起->Kafka B,
Kafka B恢复后，会把这条消息再次发送给消费端，业务在设计的时候要支持幂等（也就是多次执行，只认其中一个） - 更极端的情况，例如上面那个鬼主机硬盘直接坏了无法恢复了，如果公司比较闲的情况下可以去实现一个检查回退，你的服务实现TCC的话就很简单的回退一下即可，正常客户都会给客服电话，然后人工处理一下也可以。
高可用
- kafaka天生高可用，弄的时候 2 zookeeper,2 kafaka即可。
网络对性能的影响
- 由于现在只是本地跑着玩，真实环境要关注一下网络的影响情况。
事务
- 每个Partition消费记录，有个下标。
- 待补充
kafaka是如何实现水平扩展的
- 待补充
提高分布式性能
- 前提，你的消费端也需要可以稍微水平扩展，只是可以开多几个来提高消费性能.
- 添加 Partition,来增加kafaka的处理线程.
参考
https://www.kancloud.cn/kancloud/log-real-time-datas-unifying/58711
http://kafka.apachecn.org/
网友评论