随笔分类 - 消息队列
摘要：大量消息在mq里积压了几个小时了还没解决 几千万条数据在MQ里积压了七八个小时，最简单的方法可以让他恢复消费速度，然后等待几个小时消费完毕。 一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条 ，所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概
阅读全文
摘要：RabbitMQ RabbitMQ消息顺序错乱的场景：数据1、2、3按顺序发到一个queue，多个消费者消费同一个queue 拆分为多个queue，每个queue由一个consumer消费； 或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底
阅读全文
摘要：RabbitMQ 生产者弄丢了数据 生产者将数据发送到RabbitMQ的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。 此时可以选择用RabbitMQ提供的事务功能，就是生产者发送数据之前开启RabbitMQ事务（channel.txSelect），然后发送消息，如果消息没有成功被Ra
阅读全文
摘要：重复消费可能会在什么场景下出现（以kafka为例） kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号， 然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我继续从上
阅读全文
摘要：RabbitMQ的高可用性 RabbitMQ是基于主从做高可用性的，有三种模式：单机模式，普通集群模式，镜像集群模式 单机模式： demo级别 普通集群模式： 在多台机器上启动rabbitmq实例，每个机器启动一个。 但是你创建的queue，只会放在一个rabbtimq实例上，每个实例都同步queu
阅读全文
摘要：ActiveMQ 单机吞吐量：万级 topic数量都吞吐量的影响： 时效性：ms级 可用性：高，基于主从架构实现高可用性 消息可靠性：有较低的概率丢失数据 功能支持：MQ领域的功能极其完备 总结： 非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用 偶尔会有较低概率丢失消息 现在社区以及国
阅读全文
摘要：优点： 解耦、异步、削峰 缺点： 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，如果MQ出问题，整个系统可能挂掉。 系统复杂性提高：可能出现消息重复消费，消息丢失的问题，要考虑如何保证消息传递的顺序性 一致性问题：A处理完直接返回成功，但是BCD中，C失败了，导致数据不一致。 转自：中华石杉J
阅读全文
摘要：回答这个问题的思路： 有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ之后带给了你很多的好处。 解耦 使用MQ之前，A系统发送一个数据到BCD三个系统，通过接口调用发送，如果E也要这个数据，或者B又突然不要了，A还得去改代码 而且A还得考虑其他系统挂了怎么
阅读全文
摘要：感觉这篇讲得还阔以： https://cloud.tencent.com/developer/article/1006035
阅读全文
