ActiveMQ的做用總結(應用場景及優點)以及springboot+activeMq 實戰

業務場景說明:html

消息隊列在大型電子商務類網站,如京東、淘寶、去哪兒等網站有着深刻的應用,前端

隊列的主要做用是消除高併發訪問高峯,加快網站的響應速度。mysql

在不使用消息隊列的狀況下,用戶的請求數據直接寫入數據庫,在高併發的狀況下,會對數據庫形成巨大的壓力,同時也使得系統響應延遲加重。面試

在使用隊列後,用戶的請求發給隊列後當即返回,spring

(例如: 固然不能直接給用戶提示訂單提交成功,京東上提示:您「您提交了訂單,請等待系統確認」),sql

再由消息隊列的消費者進程從消息隊列中獲取數據,異步寫入數據庫。數據庫

因爲消息隊列的服務處理速度遠快於數據庫,所以用戶的響應延遲可獲得有效改善。apache

圖解說明:api

1.   消息隊列說明

消息隊列中間件是分佈式系統中重要的組件,主要解決應用耦合,異步消息,流量削鋒等問題。服務器

實現高性能,高可用,可伸縮和最終一致性架構。是大型分佈式系統不可缺乏的中間件。

目前在生產環境,使用較多的消息隊列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

 

2.    消息隊列應用場景

消息隊列在實際應用中經常使用的使用場景。異步處理,應用解耦,流量削鋒和消息通信四個場景。

2.1.     異步處理

場景說明:用戶註冊後,須要發註冊郵件和註冊短信。傳統的作法有兩種1.串行的方式;2.並行方式。

(1)串行方式:將註冊信息寫入數據庫成功後,發送註冊郵件,再發送註冊短信。以上三個任務所有完成後,返回給客戶端。

 

(2)並行方式:將註冊信息寫入數據庫成功後,發送註冊郵件的同時,發送註冊短信。以上三個任務完成後,返回給客戶端。與串行的差異是,並行的方式能夠提升處理的時間。

 

假設三個業務節點每一個使用50毫秒鐘,不考慮網絡等其餘開銷,則串行方式的時間是150毫秒,並行的時間多是100毫秒。

由於CPU在單位時間內處理的請求數是必定的,假設CPU1秒內吞吐量是100次。

則串行方式1秒內CPU可處理的請求量是7次(1000/150)。並行方式處理的請求量是10次(1000/100)。

 

小結:如以上案例描述,傳統的方式系統的性能(併發量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?

引入消息隊列,將不是必須的業務邏輯,異步處理。改造後的架構以下:

 

按照以上約定,用戶的響應時間至關因而註冊信息寫入數據庫的時間,也就是50毫秒。

註冊郵件,發送短信寫入消息隊列後,直接返回,所以寫入消息隊列的速度很快,基本能夠忽略,

所以用戶的響應時間多是50毫秒。因此基於此架構改變後,系統的吞吐量提升到每秒20 QPS。比串行提升了3倍,比並行提升了兩倍。

2.2.    應用解耦

場景說明:用戶下單後,訂單系統須要通知庫存系統。傳統的作法是,訂單系統調用庫存系統的接口。以下圖:

 

傳統模式的缺點:

1)  假如庫存系統沒法訪問,則訂單減庫存將失敗,從而致使訂單失敗;

2)  訂單系統與庫存系統耦合;

如何解決以上問題呢?引入應用消息隊列後的方案,以下圖:

 

  • 1:訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功,請等待物流配送。
  • 2:庫存系統:訂閱下單的消息,採用拉/推的方式,獲取下單信息,庫存系統根據下單信息,進行庫存操做。
  • 3:假如:在下單時庫存系統不能正常使用。也不影響正常下單,
  • 由於下單後,訂單系統寫入消息隊列就再也不關心其餘的後續操做了。實現訂單系統與庫存系統的應用解耦。

 

2.3.    流量削鋒

流量削鋒也是消息隊列中的經常使用場景,通常在秒殺或團搶活動中使用普遍。

應用場景:秒殺活動,通常會由於流量過大,致使流量暴增,應用容易掛掉。爲解決這個問題,通常須要在應用前端加入消息隊列。

  1. 能夠控制活動的人數.
  2. 能夠緩解短期內高流量壓垮應用;

 

  1. 用戶的請求,服務器接收後,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面;
  2. 秒殺業務根據消息隊列中的請求信息,再作後續處理。

2.4.    消息通信

消息通信是指,消息隊列通常都內置了高效的通訊機制,所以也能夠用在純的消息通信。好比實現點對點消息隊列,或者聊天室等。

點對點通信:

 

客戶端A和客戶端B使用同一隊列,進行消息通信。

聊天室通信:

 

客戶端A,客戶端B,客戶端N訂閱同一主題,進行消息發佈和接收。實現相似聊天室效果。

以上實際是消息隊列的兩種消息模式,點對點或發佈訂閱模式。

點對點和發佈訂閱的區別:

點對點與發佈訂閱最初是由JMS定義的。這兩種模式主要區別或解決的問題就是發送到隊列的消息可否重複消費(多訂閱)

點對點: 
消息生產者生產消息發送到queue中,而後消息消費者從queue中取出而且消費消息。這裏要注意: 
消息被消費之後,queue中再也不有存儲,因此消息消費者不可能消費到已經被消費的消息。 
Queue支持存在多個消費者,可是對一個消息而言,只會有一個消費者能夠消費。 
發佈/訂閱 
消息生產者(發佈)將消息發佈到topic中,同時有多個消息消費者(訂閱)消費該消息。和點對點方式不一樣,發佈到topic的消息會被全部訂閱者消費。

 注:發佈訂閱模式適用於1個消息生產者,多個消費者場景,首先啓動消息訂閱方,在消息發佈方開始執行後,接收該消息進行處理。在ActiveMQ管理界面會動態跟進消息產生-消費(入隊、出隊)狀況;以及生產者個數,消費者個數

 

//項目實戰

1.引入依賴

<!-- 整合消息隊列ActiveMQ -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-activemq</artifactId>
</dependency>
<!-- 若是配置線程池則加入 -->
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-pool</artifactId>
</dependency>

2.啓動類加上

@SpringBootApplication //一個註解頂下面3個
@EnableJms //可加可不加,建議加上
public class XdclassApplication {

public static void main(String[] args) {
SpringApplication.run(XdclassApplication.class, args);
}
}
3.注入activeMq的對象(省的每一次使用都new ,之後再使用直接去spring容器中拿就好了@Autowired)
@Component
public class CreatBean {
//消息隊列的pub_sub模式
@Bean
public Topic topic() {
return new ActiveMQTopic("video.topic");
}
//消息隊列的點對點模式
@Bean
public Queue queue() {
return new ActiveMQQueue("common.queue");
}
//自定義同時開啓pub_sub和點對點模式,由於activeMQ 默認只支持一種模式
@Bean
public JmsListenerContainerFactory<?> jmsListenerContainerTopic(ConnectionFactory activeMQConnectionFactory) {
DefaultJmsListenerContainerFactory bean = new DefaultJmsListenerContainerFactory();
bean.setPubSubDomain(true);
bean.setConnectionFactory(activeMQConnectionFactory);
return bean;
}
}
4.配置文件
#整合jms測試,安裝在別的機器,防火牆和端口號記得開放
spring.activemq.broker-url=tcp://XX.XX.XX.XX:61616

#集羣配置
#spring.activemq.broker-url=failover:(tcp://localhost:61616,tcp://localhost:61617)

spring.activemq.user=admin
spring.activemq.password=admin
#下列配置要增長依賴(activeMq鏈接池)
spring.activemq.pool.enabled=true
spring.activemq.pool.max-connections=100

#activeMq 默認是支持點對點模式的,開啓下面第二行註釋就支持 pub_sub模式了,可是又不支持點對點了,要想兩個模式都支持
#註釋下面的代碼,看第二步中的自定義jms工廠
#default point to point
# spring.jms.pub-sub-domain=true
4.生產者代碼
a.service
@Service
public class ProducerServiceImpl implements ProducerService{

@Autowired
private JmsMessagingTemplate jmsTemplate; //用來發送消息到broker的對象

//發送消息,destination是發送到的隊列,message是待發送的消息
@Override
public void sendMessage(Destination destination, String message) {
System.out.println("OrderConsumer發送的報文爲:123");
jmsTemplate.convertAndSend(destination, message);

}

//發送消息,destination是發送到的隊列,message是待發送的消息
@Override
public void sendMessage(final String message) {
jmsTemplate.convertAndSend( message);

}

//=======發佈訂閱相關代碼=========

@Autowired
private Topic topic;


@Override
public void publish(String msg) {
System.out.println("pubsub 報文發送成功");
this.jmsTemplate.convertAndSend(this.topic, msg);

}

}
b.controller
@RestController
@RequestMapping("/api/v1")
public class OrderController {

@Autowired
private ProducerService producerService;

@Autowired
private Queue queue;
@GetMapping("order")
public Object order(String msg){
producerService.sendMessage(queue, msg);

return JsonData.buildSuccess();
}
@GetMapping("pabsub")
public Object pabsub(String msg){
producerService.publish(msg);
return JsonData.buildSuccess();
}
}
6.消費者
  點對點的消費者:
@Component
public class OrderConsumer {

@JmsListener(destination="common.queue")
public void receiveQueue(String text){
System.out.println("OrderConsumer收到的報文爲OrderConsume:"+text);
}
}
pub_sub的消費者:
@Component
public class TopicSub {
@JmsListener(destination="video.topic", containerFactory="jmsListenerContainerTopic")
public void receive1(String text){
System.out.println("video.topic 消費者:receive1="+text);
}

@JmsListener(destination="video.topic", containerFactory="jmsListenerContainerTopic")
public void receive2(String text){
System.out.println("video.topic 消費者:receive2="+text);
}

 //containerFactory="jmsListenerContainerTopic" 這裏要標明自定義的jms工廠
   @JmsListener(destination="video.topic", containerFactory="jmsListenerContainerTopic")
public void receive3(String text){
System.out.println("video.topic 消費者:receive3="+text);
}
}
 面試題 https://blog.csdn.net/belvine/article/details/79399798
相關文章
相關標籤/搜索