業務場景說明:
消息隊列在大型電子商務類網站，如京東、淘寶、去哪兒等網站有着深入的應用，
隊列的主要作用是消除高並發訪問高峰，加快網站的響應速度。
在不使用消息隊列的情況下，用戶的請求數據直接寫入數據庫，在高並發的情況下，會對數據庫造成巨大的壓力，同時也使得系統響應延遲加劇。
在使用隊列后，用戶的請求發給隊列后立即返回,
（例如: 當然不能直接給用戶提示訂單提交成功，京東上提示：您“您提交了訂單，請等待系統確認”），
再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。
由於消息隊列的服務處理速度遠快於數據庫，因此用戶的響應延遲可得到有效改善。
圖解說明:
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. 流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用容易掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。
- 可以控制活動的人數.
- 可以緩解短時間內高流量壓垮應用；
- 用戶的請求，服務器接收后，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；
- 秒殺業務根據消息隊列中的請求信息，再做后續處理。
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