面试题答案
一键面试1. 利用消息唯一标识去重
- 实现方式：在生产者发送消息时，为每条消息生成一个全局唯一的标识（如UUID），并将其放入消息体或消息属性中。消费者在消费消息时，首先根据这个唯一标识去查询本地数据库或缓存（如Redis），判断该消息是否已经被处理过。如果已经处理过，则直接丢弃消息；否则，处理消息并将唯一标识存入数据库或缓存。
- 性能分析：查询数据库或缓存会带来一定的性能开销，尤其是在高并发场景下，频繁的读写操作可能成为性能瓶颈。如果使用缓存，如Redis，由于其基于内存且读写速度快，性能相对较好，但缓存可能存在数据丢失风险。
- 可靠性分析：可靠性较高，只要唯一标识不重复，且存储唯一标识的数据库或缓存不丢失数据，就能有效防止重复消费。然而，如果数据库或缓存出现故障，可能导致部分消息的去重标识丢失，从而出现重复消费。
2. 数据库唯一约束去重
- 实现方式：在数据库表中，针对消费业务数据的关键字段设置唯一约束（如订单号等）。当消费者处理消息时，将业务数据插入数据库，如果插入成功，说明该消息是首次处理；如果因为唯一约束冲突插入失败，则说明该消息已被处理过，直接丢弃。
- 性能分析：数据库的写入操作性能相对较低，特别是在高并发场景下，可能会因为大量的插入操作导致数据库性能下降。而且如果唯一约束检查逻辑过于复杂，也会影响性能。
- 可靠性分析：可靠性高，因为数据库的唯一约束机制保证了数据的唯一性。只要数据库正常运行，就不会出现重复消费导致的数据不一致问题。但如果数据库出现故障或唯一约束设置不当，可能导致重复消费。
3. 基于幂等性设计业务逻辑
- 实现方式：设计业务逻辑时，使其具备幂等性，即多次执行相同操作产生的效果与执行一次相同。例如，对于支付操作，在处理支付消息时，先查询支付状态，如果已经支付成功，则直接返回成功，不再重复执行支付流程。
- 性能分析：对性能影响较小，因为无需额外的查询去重操作，业务逻辑直接根据自身状态判断是否重复执行。但需要在业务逻辑设计阶段就充分考虑幂等性，可能增加开发复杂度。
- 可靠性分析：可靠性高，无论消息是否重复消费，业务结果都不会受到影响。但如果幂等性设计不完善，可能会出现重复消费导致的业务异常。
4. 消费组内去重
- 实现方式：在RocketMQ的消费组层面进行去重。RocketMQ的消费组内的消费者通过协调，保证同一个消息只会被消费组内的一个消费者处理。例如，可以利用消费组内的负载均衡机制，将相同消息发送到同一个消费者进行处理，该消费者在本地维护一个已消费消息的记录，防止重复消费。
- 性能分析：消费组内的协调和负载均衡会带来一定的性能开销，尤其是在消费组规模较大时。但如果合理配置负载均衡策略，可以在一定程度上减少性能损失。
- 可靠性分析：在消费组层面有较高的可靠性，只要消费组内的协调机制正常运行，就可以避免组内重复消费。但如果消费组出现异常，如部分消费者故障或负载均衡算法失效，可能导致重复消费。
5. 时间窗口去重
- 实现方式：消费者维护一个时间窗口，在这个时间窗口内，记录已消费消息的标识。如果在时间窗口内再次收到相同标识的消息，则丢弃；超过时间窗口后，清除记录并重新开始记录。
- 性能分析：性能较好，因为时间窗口内的记录可以采用简单的数据结构（如哈希表）进行维护，查询和插入操作速度快。但时间窗口的大小需要合理设置，窗口过大可能导致长时间占用内存，窗口过小可能无法有效防止短时间内的重复消费。
- 可靠性分析：可靠性相对较低，因为存在时间窗口的限制，如果消息在时间窗口结束后再次出现，可能会被重复消费。但在大多数情况下，对于短时间内的重复消费可以有效防止。
综合来看，幂等性设计业务逻辑对性能影响小且可靠性高，但开发成本较大；利用消息唯一标识去重和数据库唯一约束去重可靠性高，但对性能有一定影响；消费组内去重和时间窗口去重性能较好，但可靠性有一定局限。实际应用中需要根据业务场景和性能、可靠性要求综合选择合适的去重方式。