消息中间键MQ

目录

                                                             消息中间键总结

一、为什么要引入消息中间键

二、消息中间键有什么缺点

---

                                                    消息中间键总结

一、为什么要引入消息中间键

1. 常见的消息中间键以及他们的区别

• ActiveMQ

老牌的消息中间键，功能强大，但没办法确定是否支持互联网的高并发、高负载以及高吞吐量的复杂场景，落地较少，大多是传统的企业用于异步和系统解耦

 

• RabbitMQ

能支持高并发、高通吐量、高负载，同时拥有后台管理界面，另外还支持集群部署、高可用部署、消息可靠支持，国内大规模落地的案例较多，而且开源社区也很活跃。

注意：底层使用erlang语言开发，源码定制和改造相对来说难度大。

 

• RocketMQ

阿里开源，经过阿里生产环境超高并发、高吞吐考验，性能卓越，支持分布式事务，同时基于java开发，适合源码定制和改造

 

• Kafka

功能较少，一般用于超高吞吐量的日志采集、实时数据同步、实时数据计算等场景

 

1. 消息中间键的作用

• 系统解耦

当多个下游系统都需要上游系统的数据时，挨个转发是极不方便的，可以将数据发送到消息中间键，其他系统直接从消息中间键消费消息即可

 

• 异步调用

把系统中不需要串行化的业务采用异步的方式处理，加快系统的响应时间，提升用户体验

 

• 流量削峰

比如系统某段时间的流量峰值很大，超过了系统的承受能力，但购置更多服务器开销变大，此时就可以使用MQ积压请求，峰值后陆续消费即可。

 

二、消息中间键有什么缺点

1. 系统可用性降低

系统部分服务之间的交互依赖于中间键，一旦中间键宕机，部分业务就中断了

1. 系统稳定性降低

比如发送到消息中间键的消息丢失、消息重复，还有下游系统宕机，导致消息堆积

1. 分布式一致性问题

下游系统消费消息成功，但是处理失败，导致数据不一致的问题

• 生产环境常见问题

1. 如何保证消息100%不丢失？

• 将自动确认消息改为手动确认，即由自动ack变为手动ack

自动ack：消息发送了直接删除消息，不管消费者是否收到消息，性能很好，但是消息容易丢失

手动ack：等消费者消费了主动告诉它消息已被消费，可以删除消息

ack原理：每一个channel都有标识消息的唯一值叫delivery tag，大致而言就是一个增张的数字，在消费和删除消息的时候都会带着这个值，从而定位到消息

• 消息失败重试

设置消息nack，不确认，就会返回到消息队列，发给其他消费者

• prefetch count的合理设置

所谓prefetch count就是一个channel中uack的消息数量，设置过大可能造成OOM、内存溢出等问题，设置过小，服务的吞吐量又很低。rabbitMq官方建议prefetch count设置在100-300之间，可根据实际情况压测调整。

• 开启队列持久化和消息持久化

1. 消息中间键的高可用架构

• 集群部署和数据多副本冗余

部署多台MQ服务，并且生产者给一台服务写入消息的时候，需要复制一份消息到另外一台服务中，这时需要保证集群中该消息有双副本了才能算消息写入成功（副本的强复制要求），至少有2台机器正常才能写入消息。