摘要：数量对吞吐量的影响可以达到几百几千个的级别，吞吐量会有小幅度的下降。这是的一大优势，可在同等数量机器下支撑大量的从几十个到几百个的时候，吞吐量会大幅下降。下一篇如何保证消息队列的高可用
1.为什么使用消息队列？（1）解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。
（2）异步：加入一个操作设计到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用MQ将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。
（3）削峰：一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有100多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒5000个并发请求，而我们的系统每秒只能处理2000个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用MQ进行流量削峰，将用户的大量消息直接放到MQ里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果。
2.消息队列有什么优点和缺点？
优点：1、对结构复杂、设计系统多的操作进行解耦操作，降低系统的操作复杂度、降低系统的维护成本。
2、对一个可以进行异步操作的一些系统操作进行异步，减小操作的响应时间，提供更好的用户体验。
3、可对高流量进行削峰，保证系统的平稳运行。
缺点：1、系统可用性降低。比如在系统中引入MQ，那么万一MQ挂了怎么办呢？一般而言，引入的外部依赖越多，系统越
脆弱，每一个依赖出问题都会导致整个系统的崩溃。
2、系统复杂度提高。需要考虑MQ的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等......
3、数据一致性问题。比如A系统已经给客户返回操作成功，这时候操作BC都成功了，操作D却失败了，导致数据不
一致。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和kafka要低一个数量级 | 万级，吞吐量比RocketMQ和kafka要低一个数量级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别，kafka最大优点就是吞吐量大，一般配合大数据类的系统来进行实时数据计算、日志采集等场景。 |
| topic数量对吞吐量的影响 | topic可以达到几百、几千个的级别，吞吐量会有小幅度的下降。这是RocketMQ的一大优势，可在同等数量机器下支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅下降。所以在同等机器数量下，kafka尽量保证topic数量不要过多。如果支撑大规模topic需要增加更多的机器 | ||
| 时效性 | ms级 | 微秒级，这是rabbitmq的一大特点，延迟是最低的 | ms级 | 延迟在ms级以内 |
| 可用性 | 高，基于主从架构实现可用性 | 高，基于主从架构实现可用性 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置，可以做到0丢失 | 经过参数配置，消息可以做到零丢失 | |
| 功能支持 | MQ领域的功能及其完备 | 基于erlang开发，所以并发性能极强，性能极好，延时低 | MQ功能较为完备，分布式扩展性好 | 功能较为简单，主要支持加单MQ功能 |
| 优势 | 非常成熟，功能强大，在业内大量公司和项目中都有应用 | erlang语言开发，性能极好、延时很低，吞吐量万级、MQ功能完备，管理界面非常好，社区活跃；互联网公司使用较多 | 接口简单易用，阿里出品有保障，吞吐量大，分布式扩展方便、社区比较活跃，支持大规模的topic、支持复杂的业务场景，可以基于源码进行定制开发 | 超高吞吐量，ms级的时延，极高的可用性和可靠性，分布式扩展方便 |
| 劣势 | 偶尔有较低概率丢失消息，社区活跃度不高 | 吞吐量较低，erlang语音开发不容易进行定制开发，集群动态扩展麻烦 | 接口不是按照标准JMS规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险 | 有可能进行消息的重复消费 |
| 应用 | 主要用于解耦和异步，较少用在大规模吞吐的场景中 | 都有使用 | 用于大规模吞吐、复杂业务中 | 在大数据的实时计算和日志采集中被大规模使用，是业界的标准 |
综上所述，总结如下： 一般业务系统要引入MQ，最早大家都用ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。 后来大家开始用rabbitMQ，但是它是使用erlang语言开发的，如果不精通erlang，对公司而言，几乎处于不可控的状态，单其是开源的，社区活跃度高，拥有比较稳定的支持。 现在越来越多的公司开始使用RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用。否则还是选择RabbitMQ。 如果实在大数据的实时计算、日志采集等领域，用kafka是业界标准。
所以，对于中小型公司，技术实力一般的，应该用rabbitmq，对于大公司，基础架构研发能力强大的，推荐使用RocketMQ。
下一篇《如何保证消息队列的高可用》
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/7221.html
摘要：能不能支持数据丢失啊可以的，参考我们之前说的那个数据零丢失方案其实一个肯定是很复杂的，其实这是个开放题，就是看看你有没有从架构角度整体构思和设计的思维以及能力。其实回答这类问题，说白了，起码不求你看过那技术的源码，起码你大概知道那个技术的基本原理，核心组成部分，基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好 比如说这个消息队列系统，我们来从以下几个角度来考虑一下 （1...
摘要：紧接着征用倍的机器来部署，每一批消费一个临时的消息。这种做法相当于临时将资源和资源扩大倍，以正常速度的倍来消费消息。解决方案这种情况下，实际上没有什么消息挤压，而是丢了大量的消息。 1.大量消息在mq里积压了几个小时了还没解决 场景： 几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多。线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消...
摘要：一个对应一个，但是里面进行了多线程消费，这样也会造成消息消费顺序错误。保证消息的消费顺序拆分多个，每个一个，就是多一些而已，确实是麻烦点这样也会造成吞吐量下降，可以在消费者内部采用多线程的方式取消费。 1.为什么要保证顺序 消息队列中的若干消息如果是对同一个数据进行操作，这些操作具有前后的关系，必须要按前后的顺序执行，否则就会造成数据异常。举例： 比如通过mysql binlog进行两个数据...
摘要：消费端弄丢了数据关闭自动提交，在自己处理完毕之后手动提交，这样就不会丢失数据。弄丢了数据一般要求设置个参数来保证消息不丢失给设置参数这个值必须大于，表示要求每个必须至少有个副本。上一篇如何保证消息不重复消费下一篇如何保证消息按顺序执行 1.mq原则 数据不能多，也不能少，不能多是说消息不能重复消费，这个我们上一节已解决；不能少，就是说不能丢失数据。如果mq传递的是非常核心的消息，支撑核心的业...
摘要：这个是类似的一种结构，这个一般就是可以将结构化的数据，比如一个对象前提是这个对象没嵌套其他的对象给缓存在里，然后每次读写缓存的时候，可以就操作里的某个字段。 1.string 这是最基本的类型了，就是普通的set和get，做简单的kv缓存。 2.hash 这个是类似map的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在redis里，然后每次...
阅读 3451·2021-11-19 09:40
阅读 1472·2021-10-13 09:41
阅读 2634·2021-09-29 09:35
阅读 2682·2021-09-23 11:21
阅读 1666·2021-09-09 11:56
阅读 812·2019-08-30 15:53
阅读 824·2019-08-30 15:52
阅读 584·2019-08-30 12:47
