23｜延迟消息：怎么在 Kafka 上支持延迟消息？

作者回复: 盲生，你发现了华点，哈哈哈哈。是的，正常来说，并发很高的话，你可能一秒轮询就拿到几千条消息，这个时候你肯定来不及发完。‘ 优化的方法就是多线程，扫出来之后直接多线程来发送。这样的话发送比较快，就可以扫描更加频繁。

作者回复: 感谢提醒，倒是没想到！！！！果然是一年不学习，立马变垃圾。

作者回复: 首先纠正一个小细节，就是如果要是采用的是同一个分区固定延迟时间或者同一个 topic 固定延迟时间，那么你可以预期，如果第一个消息需要延迟一小时，后续的消息必然也是要延迟一小时的。因此你一小时到时之后，消费了第一条消息，第二条消息应该就差不多要到期了。你可以理解为流水，睡眠只是等第一滴水到来，之后都是源源不断的。

作者回复: 这是有可能的。但是你可以手动指定分区，并且在代码里面直接写死如果不是你预期的分区，你就忽略。那么在一个节点宕机之后，即便这个分区被分配给了别的消费者，因为别的消费者不会处理这个分区的消息，所以只有等到你本来宕机的节点重新恢复之后，这个分区的消息才会被处理。

作者回复: 对，有一致性问题。比如说你启动 goroutine 之后，我节点和 Broker 失去联系了，一样会 rebalance。除非你说，我先提交，然后开 Goroutine 延迟处理，但是这样就会丢失。

作者回复: 有一个 Kafka 在前面挡着，可以保护住 mysql。直接用的话，mysql 不一定撑得住那么大的并发。 另外一方面则是，客户端那边可能不希望和 mysql 打交道，而是希望说直接和 Kafka 打交道，然后 Kafka 后面你们怎么搞，就随便。

作者回复: 可以的。Redis 高可用的话，可以不用 MySQL 的

作者回复: 1. 对的，因为你同一个分区，延迟时间都是一样的。 2. 这个我倒是没尝试过，但是你可以试试，看起来应该没啥问题。

作者回复: 不是遍历。它扫描就是用下次发送时间在下一秒的。每次就是取出来一秒，当然你也可以取出来十秒，但是要小心时间准确度。 性能的话，其实也没那么差，你保持一个线程扫描一张表，然后扫出来的数据可以开启多线程处理。

作者回复: 就是我提到的，当你要处理这个消息的时候，你要先确保它还是处于一种未支付的状态。 最简单的做法就是加分布式锁，检测状态，然后决定要不要丢弃消息。高级一点的就是用乐观锁。