本文探讨了一种将多个Java消息合并为一条发送以节省成本的方案，适用于允许消息部分消费失败的业务场景。通过借鉴sqs批量发送、限流中间件和netty的设计，实现了在不影响并发性能的情况下合并消息。此外，文章提到了使用Go语言实现消费者的原因，以及在消费过程中遇到的消息重复和延迟问题，并给出了相应的优化策略。
关注
“Java艺术”一起来充电吧!
这是笔者最近处理一个叫异步大点击的业务问题所思考出来的方案。由于mq使用的是亚马逊的sqs服务，而sqs是按请求数消费的原因，所以才有的将多消息合并为一条消息发送的想法。
这个想法从sqs的消息批量发送以及阿里限流中间件的qps统计、netty的EventLoopGroup设计中得到启发。本篇将介绍如何将多个消息合并成一个消息发送而不影响服务的并发性能，以及由于合并后产生的大消息消费出现的消息堆积现象，开的消费者越多反而消息堆积越多的bug。
为什么要将多消息合并为一个消息发送？
前面也说了，为了节约成本。以每分钟50w的广告点击数来算，一个月将产生50＊60＊24＊31w的点击消息，再乘以3就是每个月的sqs请求数，3代表的是发送消息、拉取消息、删除消息，按每100w请求0.4美刀的价格计算大概一个月要26784美刀。
由于sqs限制单条消息的大小最大为256k，根据业务场景估算每点击消息也不可能达到1k,，所以我将256个请求合并为一个消息发送，或者1s内未达到256个消息也合并为一个消息发送，这样
最低0.47元/天 解锁文章
扫一扫
2986
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
