去哪儿网:从问题到实践——定制消息队列的设计与实现

0 下载量 138 浏览量 更新于2024-08-28 收藏 283KB PDF 举报
去哪儿网在2012年面对业务增长带来的挑战时,开始进行服务化改造,以应对单体应用架构无法满足需求的问题。在这个过程中,选择合适的通信中间件是关键。他们最初考虑了同步通信(如Dubbo)和异步通信(如消息队列),但出于对数据一致性、技术成熟度和代码复杂性的考量,最终决定自建消息队列。 在服务化拆分中使用消息队列,去哪儿网面临的主要问题包括: 1. 数据一致性保障:由于业务涉及到旅游产品的在线预订,尤其是电商交易,数据一致性至关重要。他们需要确保消息的发送与业务操作保持一致,避免出现业务成功但消息未发或消息发出去但业务失败的情况。例如,支付成功但未通知出票服务可能导致用户不满,反之,支付失败却出票了则会造成公司损失。 2. 发送与消费一致性:为了防止上述问题,去哪儿网需要实现发送和消费之间的事务保证。这包括确保业务操作成功后消息被发送,并且在消费者遇到临时错误或网络故障时,能通过消费确认(ACK)机制和重试策略确保消息最终被处理。 3. 服务端设计:初期计划仅在交易环节使用自建MQ,但随着MQ的广泛应用,他们意识到需要一个更通用的解决方案。最初的方案是将消息存储在数据库中,但这不足以满足所有场景的需求。因此,他们可能需要扩展MQ的功能,支持更多的服务和场景,比如日志处理、监控报警等。 4. 技术选型与挑战:在当时的选项中,RabbitMQ因为技术栈问题被排除,而Kafka和MetaQ(RocketMQ的前身)在成熟度和稳定性上存在问题。ActiveMQ虽然已广泛使用,但其复杂性使得完全控制变得困难。因此,去哪儿网决定自己开发一个定制化的消息队列系统,以满足特定的业务需求和性能要求。 这个过程不仅涉及技术选型,还包括团队在设计和实现过程中面临的挑战,如如何优化性能、提高可靠性,以及如何与现有的技术栈无缝集成。通过自建MQ,去哪儿网不仅解决了即时通信问题,还提升了系统的灵活性和可扩展性,为后续的服务化改造奠定了坚实的基础。