kafka 的介绍

kafka相关资料

kafka 是什么

kafka 是消息队列消息队列的其中一种。
消息队列一般有以下几种特性

1.异步和解耦：
　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
　　- 短信
　　- 多系统
2.冗余：
　　消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3.扩展性：
　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
4.灵活性 & 峰值处理能力：
　　在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5.可恢复性：
　　系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6.异步通信：
　　很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
7.数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

kafka 相关基础概念

• topic
• Partition [分区]
• groupid [消费组]
• Producers[生产者]
• Consumers[消费者]

topic [主题]

topic可以理解为对消息的分类

Partition [分区]

一个topic可以下会有多个partition，每个partition是一个有序的队列。一般推荐为6的倍数，最好为24

partition中的每条消息都会被分配一个有序的id（offset）

groupid

消费者从属于消费者群组。

• 一个群组里的消费者订阅的是同一个主题，每个消费者 接收主题一部分分区的消息。
  
• 一个主题也可以被不同的群组的消费者订阅，
  

区别和场景

常用消息队列对比

消息队列对比

rabbitMQ

rabbitmq作为交易数据作为数据传输管道，主要的取舍因素则是是否存在丢数据的可能；rabbitmq在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同事具备更高的实时性；而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；而且由于kafka保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况；

redis

redis 如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能

缺陷
1、redis是基于内存的一旦发生崩溃可能会导致数据丢失
2、kakfa信息是存在磁盘里的能堆积大量信息
3、kafka有消费分组模式

Redis作为消息队列

Redis的pub-sub模式非常像西式快餐一样,快产快消,全都是因为Redis是使用内存来做存取,所有你生产的消息立马会被消费者一次性全部处理掉,并且没有留下任何痕迹, 同时因为内存总是宝贵的,所以内存上会有限制,当生产者以及消费者上来的时候也会对redis的效率,还有Redis在处理发布和消费big size(10K+的文件)的数据的时候会表现出无法忍受的缓慢

如果有以下场景可以考虑使用Redis作为消息队列

• 如果你的需求是快产快消的即时消费场景,并且生产的消息立 即被消费者消费掉
• 如果速度是你十分看重的,比如慢了一秒好几千万这种
• 如果允许出现消息丢失的场景
• 如果你不需要系统保存你发送过的消息,做到来无影去无踪
• 需要处理的数据量并不是那么巨大

kafka的特点

1、kafka的消息存储在磁盘上面的，无论它们是否已被消耗都会保存记录的，只要可配置的保留期内。

2、如果你的消息希望是保持顺序的话，因为消息在Partition中写入是有序的，同时一个Partition只能够被一个Consumer消费，这样就可能实现消息在Partition中的有序。自定义写入哪个Partition的规则能够让需要有序消费的相关消息都进入同一个Partition中被消费。这样就可以达到有序

3、kafka 扩展分区和消费组是不需要停机，系统会自动平衡

消费者相关配置

• fetch.max.wait.ms 设置了broker返回给消费者最小的数据量，而fetch.max.wait.ms设置的则是broker的等待时间，两个属性只要满足了任何一条，broker都会将数据返回给消费者，也就是说举个例子，fetch.min.bytes设置成1MB，fetch.max.wait.ms设置成1000ms，那么如果在1000ms时间内，如果数据量达到了1MB，broker将会把数据返回给消费者；如果已经过了1000ms，但是数据量还没有达到1MB，那么broker仍然会把当前积累的所有数据返回给消费者。 // 一般来说你使用默认的配置就行了
• session.timeout.ms 心跳时间:没有在这个时间内发送心跳就会判断消费者已经死亡，会触发在均衡。// 心跳时间(服务器上设了 3s) // 默认配置就行了

• partition.assignment.strategy // 消费分区策略

  • Range // 轮训策略 [推荐]
  • RoundRobin // 范围策略

• Offsets.Initial // 如果读不到服务器上 offset 配置，就初始化成从服务器上上次记录的最旧的读

  • OffsetOldest // 导致重复消费 [推荐]
  • OffsetNewest // 漏掉消费

生产者配置

• Partitioner // 分区器

  • RobinPartitioner // 轮训 [推荐]
  • RandomPartitioner // 随机
• RequiredAcks // 等待多少 broke 应答才认为发布成功
• all //所有 [推荐]

问题

重分配再均衡问题

• 因为重分配再分区的问题大多数时候是由消费者决定的，消费者会定时发送一个心跳包给[群组协调器(broker)],当消费者下线或者重新加入的话，就会触发重分配再均衡,当一个消费者不断上下线可能会导致该topic出现不断的重分配，导致该topic停止被消费
• 尽量不要减少topic的分区数，可能导致会出现数据丢失与错乱的问题

1.2 Kafka的使用场景：

• 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
• 消息系统：解耦和生产者和消费者、缓存消息等。
• 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
• 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

参考资料

• kafka消费者组概念
• https://blog.csdn.net/why444216978/article/details/85237342
• 场景分析
• php下的kafka应用