消息可靠保证线程
1.消费端的保证消息可靠内存
惟一可能致使消息丢失的状况,在消费端获取到了消息,自动提交了offset,让borker觉得已经消费好了这个消息,实际上才开始准备消费这条消息,可能存在消费过程当中消费者挂了,这条消息就会丢掉。这和Rabbit差很少,Kafak会自动提交offset,那么只要关闭自动提交offset,处理完成以后手动提交ack。就能够保证消息不丢失。可能消费完了,提交ack过程发生失败,在消费端作好幂等性处理。同步
2.Borker弄丢了数据it
比较常见的一个场景,某个broker挂了,而后从新选举Partition的leader。此时其余follower恰好有数据没有同步,结果此时leader挂了,而后选举某个follower成为leader以后,这样就致使有些数据丢失了。 io
要设置4个参数:queue
1.给Topic设置replication.factor参数:这个值必须大于1,要求每一个partition至少有2个副本。数据
2.在Kafak服务端设置min.insync.replicas参数:这个值必须大于1,这个要求leader至少感知到至少一个follower还跟本身保持联系服务端
3.在producer端设置acks=all:这个要求每条数据,必须写入全部的replicas,才能确认写入成功。sync
4.在producer端设置retries=MAX,这个要求一旦写入失败,就无限重试。cas
3.生产者producer保证消息不丢失
按照上述思路设置了acks=all,必定不会消失。要求是消息写入了leader后,全部的follower都同步到了消息才确认。若是不知足这个条件,生产者就会不断的重试。
Kafak如何保证消息的顺序消费
kafak自己不想Rocket同样,提供顺序性的消息。因此提供的方案都是相对有损的。这里的顺序消息,咱们更多指的是,单个partition的消息,被顺序消费。
方式一:Consumer,对每一个parttion内部单线程消费,单线程吞吐量过低,通常不会用。
方式二:Consumer拉取到message,写到N个内存queue,具备相同key的数据都存到同一个内存queue。而后对于n个线程,每一个线程分别消费一个内存queue便可,这样能保证顺序性。