一个天天用消息队列的人,不知道为啥用 MQ,这就有点尴尬
因此,为了避免生产者丢数据,做如下两点配置
(2)消息队列丢数据 针对消息队列丢数据的情况,无外乎就是,数据还没同步,leader就挂了,这时zookpeer会将其他的follwer切换为leader,那数据就丢失了。 针对这种情况,应该做两个配置。 replication.factor参数,这个值必须大于1,即要求每个partition必须有至少2个副本 min.insync.replicas参数,这个值必须大于1,这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系 这两个配置加上上面生产者的配置联合起来用,基本可确保kafka不丢数据 (3)消费者丢数据 这种情况一般是自动提交了offset,然后你处理程序过程中挂了。kafka以为你处理好了。 再强调一次offset是干嘛的 offset:指的是kafka的topic中的每个消费组消费的下标。 简单的来说就是一条消息对应一个offset下标,每次消费数据的时候如果提交offset,那么下次消费就会从提交的offset加一那里开始消费。 比如一个topic中有100条数据,我消费了50条并且提交了,那么此时的kafka服务端记录提交的offset就是49(offset从0开始),那么下次消费的时候offset就从50开始消费。 解决方案也很简单,改成手动提交即可。 ActiveMQ和RocketMQ 大家自行查阅吧 7、如何保证消息的顺序性? 分析:其实并非所有的公司都有这种业务需求,但是还是对这个问题要有所复习。 回答:针对这个问题,通过某种算法,将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。 有的人会问:那如果为了吞吐量,有多个消费者去消费怎么办? 这个问题,没有固定回答的套路。比如我们有一个微博的操作,发微博、写评论、删除微博,这三个异步操作。如果是这样一个业务场景,那只要重试就行。 比如你一个消费者先执行了写评论的操作,但是这时候,微博都还没发,写评论一定是失败的,等一段时间。等另一个消费者,先执行写评论的操作后,再执行,就可以成功。 总之,针对这个问题,我的观点是保证入队有序就行,出队以后的顺序交给消费者自己去保证,没有固定套路。 总结 写到这里,希望读者把本文提出的这几个问题,经过深刻的准备后,一般来说,能囊括大部分的消息队列的知识点。 如果面试官不问这几个问题怎么办,简单,自己把几个问题讲清楚,突出以下自己考虑的全面性。 最后,其实我不太提倡这样突击复习,希望大家打好基本功,做一个爱思考,懂思考,会思考的程序员。
(编辑:常州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |