(1)生产者概览
(1)不同的应用场景对消息有不同的需求,即是否允许消息丢失、重复、延迟以及吞吐量的要求。不同场景对Kafka生产者的API使用和配置会有直接的影响。
例子1:信用卡事务处理系统,不允许消息的重复和丢失,延迟最大500ms,对吞吐量要求较高。
例子2:保存网站的点击信息,允许少量的消息丢失和重复,延迟可以稍高(用户点击链接可以马上加载出页面即可),吞吐量取决于用户使用网站的频度。
(2)Kafka发送消息的主要步骤
消息格式:每个消息是一个ProducerRecord对象,必须指定消息所属的Topic和消息值Value,此外还可以指定消息所属的Partition以及消息的Key。
1:序列化ProducerRecord
2:如果ProducerRecord中指定了Partition,则Partitioner不做任何事情;否则,Partitioner根据消息的key得到一个Partition。这是生产者就知道向哪个Topic下的哪个Partition发送这条消息。
3:消息被添加到相应的batch中,独立的线程将这些batch发送到Broker上
4:broker收到消息会返回一个响应。如果消息成功写入Kafka,则返回RecordMetaData对象,该对象包含了Topic信息、Patition信息、消息在Partition中的Offset信息;若失败,返回一个错误
(3)Kafka的顺序保证。Kafka保证同一个partition中的消息是有序的,即如果生产者按照一定的顺序发送消息,broker就会按照这个顺序把他们写入partition,消费者也会按照相同的顺序读取他们。
例子:向账户中先存100再取出来 和 先取100再存进去是完全不同的,因此这样的场景对顺序很敏感。
如果某些场景要求消息是有序的,那么不建议把retries设置成0,。可以把m