Apache Kafka快速入门指南
|
前面已经介绍了Kafka如何进行有效的存储，以及了解了Producer和Consumer如何工作。接下来讨论的是Kafka如何确保消息在Producer和Consumer之间传输。有以下三种可能的传输保障(delivery guarantee):
Kafka的消息传输保障机制非常直观。当Producer向Broker发送消息时，一旦这条消息被commit，由于副本机制(replication)的存在，它就不会丢失。但是如果Producer发送数据给Broker后，遇到的网络问题而造成通信中断，那producer就无法判断该条消息是否已经提交(commit)。虽然Kafka无法确定网络故障期间发生了什么，但是Producer可以retry多次，确保消息已经正确传输到Broker中，所以目前Kafka实现的是At least once。 Consumer从Broker中读取消息后，可以选择Commit，该操作会在Zookeeper中存下该Consumer在该Partition下读取的消息的offset。该Consumer下一次再读该Partition时会从下一条开始读取。如未commit，下一次读取的开始位置会跟上一次commit之后的开始位置相同。当然也可以将consumer设置为autocommit，即Consumer一旦读取到数据立即自动commit。如果只讨论这一读取消息的过程，那Kafka是确保了exactly once, 但是如果由于前面Producer与Broker之间的某种原因导致消息的重复，那么这里就是At least once。 考虑这样一种情况，当Consumer读完消息之后先commit再处理消息，在这种模式下，如果consumer在commit后还没来得及处理消息就crash了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息，这就对应于At most once了。读完消息先处理再commit。这种模式下，如果处理完了消息在commit之前Consumer crash了，下次重新开始工作时还会处理刚刚未commit的消息，实际上该消息已经被处理过了，这就对应于at least once。 要做到exactly once就需要引入消息去重机制。Kafka文档中提及GUID(Globally Unique Identifier)的概念，通过客户端生成算法得到每个消息的unique id，同时可映射至broker上存储的地址，即通过GUID便可查询提取消息内容，也便于发送方的幂等性保证，需要在broker上提供此去重处理模块，目前版本尚不支持。 针对GUID, 如果从客户端的角度去重，那么需要引入集中式缓存，必然会增加依赖复杂度，另外缓存的大小难以界定。不只是Kafka, 类似RabbitMQ以及RocketMQ这类商业级中间件也只保障at least once, 且也无法从自身去进行消息去重。所以我们建议业务方根据自身的业务特点进行去重，比如业务消息本身具备幂等性，或者借助Redis等其他产品进行去重处理。 Kafka作为消息队列： 传统的消息有两种模式：队列和发布订阅。 在队列模式中，消费者池从服务器读取消息(每个消息只被其中一个读取); 发布订阅模式：消息广播给所有的消费者。这两种模式都有优缺点，队列的优点是允许多个消费者瓜分处理数据，这样可以扩展处理。但是，队列不像多个订阅者，一旦消息者进程读取后故障了，那么消息就丢了。而发布和订阅允许你广播数据到多个消费者，由于每个订阅者都订阅了消息，所以没办法缩放处理。 Kafka中的Consumer Group有两种形式： a、队列：允许同名的消费者组成员共同处理。 b、发布订阅：广播消息给多个消费者组。 Kafka的每个topic都具有这两种模式。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |