用Kafka两年踩过的一些非比寻常的坑

实证明，这一切的关键是消息中间件：kafka，如果它有问题，将会直接影响到后厨显示系统的功能。

接下来，我跟大家一起聊聊使用kafka两年时间踩过哪些坑?

顺序问题

1. 为什么要保证消息的顺序?

刚开始我们系统的商户很少，为了快速实现功能，我们没想太多。既然是走消息中间件kafka通信，订单系统发消息时将订单详细数据放在消息体，我们后厨显示系统只要订阅topic，就能获取相关消息数据，然后处理自己的业务即可。

不过这套方案有个关键因素：要保证消息的顺序。

为什么呢?

订单有很多状态，比如：下单、支付、完成、撤销等，不可能下单的消息都没读取到，就先读取支付或撤销的消息吧，如果真的这样，数据不是会产生错乱?

好吧，看来保证消息顺序是有必要的。

2.如何保证消息顺序?

我们都知道kafka的topic是无序的，但是一个topic包含多个partition，每个partition内部是有序的。如此一来，思路就变得清晰了：只要保证生产者写消息时，按照一定的规则写到同一个partition，不同的消费者读不同的partition的消息，就能保证生产和消费者消息的顺序。

我们刚开始就是这么做的，同一个商户编号的消息写到同一个partition，topic中创建了4个partition，然后部署了4个消费者节点，构成消费者组，一个partition对应一个消费者节点。从理论上说，这套方案是能够保证消息顺序的。

切规划得看似“天衣无缝”，我们就这样”顺利“上线了。

3.出现意外

该功能上线了一段时间，刚开始还是比较正常的。

但是，好景不长，很快就收到用户投诉，说在划菜客户端有些订单和菜品一直看不到，无法划菜。

我定位到了原因，公司在那段时间网络经常不稳定，业务接口时不时报超时，业务请求时不时会连不上数据库。

这种情况对顺序消息的打击，可以说是毁灭性的。

为什么这么说?

假设订单系统发了：”下单“、”支付“、”完成“ 三条消息。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!