目录
消息队列的连环炮
在系统用过消息队列吗
如何在项目中用消息队列的
为什么使用消息队列
对整个系统的架构体系是否了解 是知道使用消息队列的原因还是只是单纯的炫技 同时对于 公司来说 盲目使用技术 可能后面会给公司埋下很多坑 对己对公司都是不好的
建议回答
某个业务场景 不用MQ对于日后项目的扩大会比较的麻烦 使用MQ相对来说会更加有好处 - 解耦: 对于系统A 他要给其他系统B C D传数据 不使用MQ的时候 会让系统A考虑非常多的情况 比如 B C D 宕机后是否要重发 要不要把数据存起来 - 削峰: 在某个时刻 并发请求数量就会增大,比如:中午时候外卖APP的并发请求就会增大 如果系统最大的处理能力不能满足 系统就会崩溃 - 异步: 进行数据的写入时 不仅仅需要在A 写入 还需要在B C D 也写入 耗费的时间就是
T = Ta + Tb + Tc + Td
进行异步化 时间将会降低
T = Ta + T(a发给MQ的时间)
使用消息队列有什么优点和缺点
不懂得优缺点 同样给后面接手这个项目的人 带有许多问题
建议回答： 优点 1. 上面已经说了
缺点
- 系统可用性降低 如果MQ挂了 其他系统会受到影响
- 系统复杂性提高 添加了MQ 就要保证不会重复消费 保证传的消息的顺序性
- 一致性问题: A系统处理完了 直接返回成功 但若B C D中有一个失败 该如何保证
kafka、activemq、rabbitmq、rocketmq都有什么区别
没有经过调研随意听信他人使用某一个消息队列好 原因可能是支持高可用 亦或者社区活跃 度高 并没有绝对好坏的技术 只能是根据业务场景及公司状况来使用
| header 1 | header 2 |
|---|---|
| row 1 col 1 | row 1 col 2 |
| row 2 col 1 | row 2 col 2 |
| 特性 | 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丢失 | 经过参数优化配置，消息可以做到0丢失 | ||
| 功能支持 | MQ领域的功能极其完备 | 基于erlang开发，所以并发能力很强，性能极其好，延时很低 | MQ功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
最终建议:
- 稳妥为主 还是使用RabbitMQ
- 有实力的话还是使用RocketMQ
- 大数据领域的实时计算 日志采集等可以使用Kafka 业内标准
