解决思路：
1. 如果仅仅是 Consumer消费速度落后于消息生产的速度的话，可以考虑采用扩容消费者群组的方式。
2. 如果积压比较严重，积压了上百万、上千万的消息。
a. 修复现有 Consumer问题，并将其停掉。
b. 重新创建一个容量更太的 topic，例如 patition是原来的 10倍，临时建立好原来10倍的 queue数量。
c. 重新写一个临时 Consumer 程序，消费原来积压的队列。该 Consumer不做任何耗时的操作，将消息均匀写入新创建的队列里。
d. 征用 10 倍的机器来部署 已经修复好的 consumer 程序，每一批 consumer 消费一个临时 queue的数据。这种做法相当于临时将 queue资源和 consumer资源扩大 10 倍，以正常的 10 倍速度来消费数据。
e. 消息积压解决后，恢复原有架构。
3. 如果消息已经丢失
由于有的消息队列有过期失效机制，造成了大量的消息丢失。这种情况下只能将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 MQ 里面去。
4. 消息队列快写满了
如果消息积压在 MQ 里，很长时间都没有处理掉，此时导致 MQ快些满了，这个是时候还有别的办法吗？没有，谁让第二个方案执行的太慢了，临时写程序，接入数据来消费，消费一个丢弃一个，都不要了。快速消费掉所有的消息，然后走第三个方案，补数据。
原文地址：http://www.cnblogs.com/qiezi777/p/16877784.html
1. 本站所有资源来源于用户上传和网络，如有侵权请邮件联系站长！
2. 分享目的仅供大家学习和交流，请务用于商业用途!
3. 如果你也有好源码或者教程，可以到用户中心发布，分享有积分奖励和额外收入！
4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！
5. 如有链接无法下载、失效或广告，请联系管理员处理！
6. 本站资源售价只是赞助，收取费用仅维持本站的日常运营所需！
7. 如遇到加密压缩包，默认解压密码为"gltf",如遇到无法解压的请联系管理员！
8. 因为资源和程序源码均为可复制品，所以不支持任何理由的退款兑现，请斟酌后支付下载
声明：如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性
