2019-10-30处理方式：
网络抖动处理：重发
消息队列服务器宕机：集群
消息重复：使用唯一 ID 保证消息唯一性。 17
2019-10-30我们目前是在消费消息后，将消息id(业务上定义的唯一标识)放入redis。消费前，先去redis查找，也算是业务上的一种防重复吧作者回复: 嗯那 这个也是的
11 7
2019-12-21联想到MongoDB在写策略中有w和j两个参数，w对应同步多个从节点，j是刷journal到磁盘。看来存储系统的技术都差不多。一般设置w=majority就可以，j=false。跟kafka中老师的建议一样。Redis中也有AOF，不同存储系统解决问题不一样，但共性还是很多的。因为都要保证性能，可用性，数据一致性，只是每个存储系统侧重点不一样，Kafka是写性能，Redis是读性能，普通关系数据库是事务作者回复: 👍
3
2019-12-24消费端 消息处理的幂等性：1.增加去重表（通用）；2.根据业务数据状态来判断（例如 订单支付后变更状态为已支付，如果订单当前状态已经为已支付则忽略此消息）。作者回复: 赞~
2
2019-10-31消息队列的服务端会存储 < 生产者 ID，最后一条消息 ID> 的映射。当某一个生产者产生新的消息时，消息队列服务端会比对消息 ID 是否与存储的最后一条 ID 一致，如果一致，就认为是重复的消息，服务端会自动丢弃。
老师，只校验最后一条ID应该不能完全保证消息不重复吧？作者回复: 如果每条消息生产时都使用发号器发一个唯一的号就好了
2
2020-02-02推荐使用多副本而不是每次刷盘。我不太理解，难道每次都刷盘（flush），性能应该比每次都要多次网络调用要强得多啊（备份同步）作者回复: 从性能数据看，网络调用耗时要比磁盘写入耗时低
1 1
2019-12-21生产者判重交给消息中间件自行处理，加判重表。消费端的重复消费通过分布式锁控制，过期时间可以放长些。作者回复: 👍
1
2019-12-15我们在生产环境中为了避免重复消费使用了全局唯一ID的方式，每次业务逻辑前都会从库中查一下。但是会出现两条消息瞬时并发处理问题，这时事务都没提交所以都查不到。这时可以用老师说的版本乐观锁来解决 ， 我们目前的方式是增加了分布式锁作者回复: 👍
1
2019-11-21老师好，我对消息全局id存在疑问。该id是否应该是这个消息的签名呢？如果仅仅是全局id并不能判断两条消息是否一致 1
2019-10-30老师请教一个问题，例如我开发个服务端程序，我想知道我开发的服务程序性能指标，怎么得的，例如机器配置 cpu有i3 i5的那个更适合怎么测试出来的，另外qps吞吐率等这些都是用工具测试的吗😊作者回复: 用哪种机器都可以，只是你在出性能报告的时候需要说明机器的配置：）
qps的话一般会收集访问日志来统计，后面我讲到监控时会提到的 1 1
2019-10-30老师 按照上面说的生产者保证消息幂等的方法 如果一个生产者的一个线程1发送了一条消息 有了唯一id 结果没被确认 需要重传 但是在重传的时候 该生产者的另一个线程2 发送了消息2 这是线程1对消息进行了重传 那么不就不能保证幂等了么作者回复: 是的，在并发下这种方式不能保证幂等。不过也可以在消费端保证幂等
1 1
2020-02-04版本号在消息生产者生成，两次amount，取出来的version是同样的；会导致消费者第二次失败作者回复: 正常情况version不应该相同
2020-01-21老师你好，今天下午的时间全部奉献给这个专栏了，一口气看到了18。
我很想继续深入学习文中这一段更深入的解决方案：
如果消息在处理之后，还没有来得及写入数据库，消费者宕机了重启之后发现数据库中并没有这条消息，还是会重复执行两次消费逻辑，这时你就需要引入事务机制，保证消息处理和写入数据库必须同时成功或者同时失败，但是这样消息处理的成本就更高了。
老师可以继续往下深入讲吗？金融系统跟钱有关的必须解决好这一点啊……展开作者回复: 基本上还是分布式事务，比如两阶段提交的办法
2020-01-10如果生产端较长时间网络不可用，又不想影响主线业务流程，这种情况该怎么办呢？作者回复: 在本地磁盘或者内存中暂存
- 2020-01-08老师，不太懂，使用乐观锁防止重复消费的话，如果生产时有两条并发的消息处理同一个数据(不是重复消息)，获取到的是相同的版本号，写入消息队列后，第一条消息被消费成功，修改了版本号，第二条消息就再也无法消费成功了，那怎么办呢？我看评论区写了可以重新查询，可以详细说说吗？因为我觉得这个消费者再怎么重新查询到的版本号都已经和生产者写入时的版本号不一致了，只能由生产者重新生产一次消息才能写入更新后的版本号吧，可是消费者又怎么通知生产者需要重新生产消息呢？而且消费者发现版本号不一致，它也没法判断是由于并发还是重复造成的吧
作者回复: 如果版本号重复是没有办法的，不过版本号可以用发号器生成，保证唯一
2019-12-31看了老师整个课程，知识体系非常全面且深入。但是mq这块儿有一个很重要的方面没有设计，mq消息乱序的问题，想知道老师工作中是怎么处理这个问题的。作者回复: 有一个办法是可以把相关的数据写入到同一个partition
- 2019-12-25老师，为保证消息不丢失，你给的建议是使用集群，而不是同步刷盘，并提到这样对写性能影响小。我有个疑问：同步集群是网络IO，刷盘是磁盘IO，难道网络IO比磁盘IO快吗？
2019-12-09比方说，消息生产时由于消息队列处理慢或者网络的抖动，导致虽然最终写入消息队列成功，但在生产端却超时了
请教老师，这个地方，如果超时了，生产者还会把消息传递到消费队列，然后造成消息重复嘛？
2019-11-25通过数据库锁实现幂等性：insert ignore, insert ... on duplicate, insert replace, update set a where a等等- 2019-11-22【当 Leader 故障时，新选举出来的 Leader 会从 ISR 中选择，默认 Leader 的数据会异步地复制给 Follower，这样在 Leader 发生掉电或者宕机时，Kafka 会从 Follower 中消费消息】这里不太明白。当leader宕掉之后，kafka从follower中消费消息，这个follower是包括ISR的吗？那么是从哪个follower中消费呢？还是从选举成新leader的follower中消费呢
作者回复: 是从ISR中选出一个follower作为新的leader