Dubbo远程调用的性能问题
Dubbo调用普遍存在于我们的微服务项目中
这些Dubbo调用全部是同步的操作
这里的"同步"指:消费者A调用生产者B之后,A的线程会进入阻塞状态,等待生产者B运行结束返回之后,A才能运行之后的代码
Dubbo消费者发送调用后进入阻塞状态,这个状态表示该线程仍占用内存资源,但是什么动作都不做
如果生产者运行耗时较久,消费者就一直等待,如果消费者利用这个时间,那么可以处理更多请求,业务整体效率会提升
实际情况下,Dubbo有些必要的返回值必须等待,但是不必要等待的服务返回值,我们可以不等待去做别的事情
这种情况下我们就要使用消息队列
什么是消息队列
消息队列(Message Queue)简称MQ,也称:"消息中间件"
消息队列是采用"异步(两个微服务项目并不需要同时完成请求)"的方式来传递数据完成业务操作流程的业务处理方式
消息队列的特征
常见面试题:消息队列的特征(作用)
利用异步的特性,提高服务器的运行效率,减少因为远程调用出现的线程等待\阻塞时间
削峰填谷:在并发峰值超过当前系统处理能力时,我们将没处理的信息保存在消息队列中,在后面出现的较闲的时间中去处理,直到所有数据依次处理完成,能够防止在并发峰值时短时间大量请求而导致的系统不稳定
消息队列的延时:因为是异步执行,请求的发起者并不知道消息何时能处理完,如果业务不能接受这种延迟,就不要使用消息队列
常见消息队列软件
Kafka:性能好\功能弱:适合大数据量,高并发的情况,大数据领域使用较多
RabbitMQ:功能强\性能一般:适合发送业务需求复杂的消息队列,java业务中使用较多
RocketMQ:阿里的