同步請求：瀏覽器 向服務器 發送一個登錄請求,如果服務器 沒有及時響應，則瀏覽器則會一直等待狀態，直至服務器響應或者超時。
異步請求：瀏覽器 向服務器 發送一個登錄請求,不管服務器是否立即響應，瀏覽器不需要等待。
在java中,在多線程的情況，也有同步，異步 阻塞的說法，多線程的情況，加了同步關鍵字synchronized以后，當一個線程正在執行一個方法的時候，其余線程想要執行該方法則需要等待當前正在執行的線程 執行完以后，這個過程其他線程就是阻塞狀態。
同步請求，瀏覽器--->服務器，如果服務器有延遲，則 瀏覽器 會一直等待，等待服務器的響應或者Http超時，如果在一些實際項目中，例如，A 項目調用B 項目，同步請求，B 由於網絡原因或者說查詢數據庫過慢，導致 A 項目調用超時，則可能A 會重復提交。
同步請求的缺點：超時，阻塞，數據可能重復提交
以上 可以看出：
在客戶端與服務器進行通訊時.客戶端調用后，必須等待服務對象完成處理返回結果才能繼續執行。客戶端與服務器對象的生命周期緊密耦合,客戶端進程和服務對象進程都都必須正常運行;如果由於服務對象崩潰或者網絡故障導致用戶的請求不可達,客戶端會受到異常
在這種情況下，可以使用消息中間件
什么是消息中間件：
發送者將消息發送給消息服務器，消息服務器將消息存放到隊列中，在合適的時候再將消息轉發給接收者，發送者將消息發送給隊列的時候，不需要關注接收者是否接受消息，也不需要等待接收者的響應，接收者處理消息的時候，同樣也不需要關注 發送者是否正常運行。這種模式下，發送和接收是異步的，發送者無需等（異步通訊）
消息中間件的通訊方式：JMS
JMS是java的消息服務，JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。
JMS有兩種消息模型：點對點 和點對多（發布訂閱）
點對點消息模型
生產者：向隊列發送消息的一方（提供接口）
消費者：向隊列獲取消息的一方（調用接口）
消息隊列：存放消息的地方（可以做持久化）
生產者向消息隊列發送消息，如果消費者在，則從消息隊列獲取消息消費，消費成功以后，該消息在隊列中清除，如果消費者不在，生產者生成的消息則會緩存到到隊列之中 ,根據這個特性，可以知道中間件可以解決高並發，對消息 緩存排隊，在高並發的情況下，大量的消息會緩存到隊列中，消費者可以根據自己的需要選擇一次性消費多少條數據，而不是直接將所有的消息 直接發送給消費者。
點對點模型特點：
- 每個消息只有一個消費者(即一旦被消費，消息就不再在消息隊列中)
- 發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之后，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列
- 接收者在成功接收消息之后需向隊列應答成功
所以如果希望發送的每個消息都應該被成功處理的話
在點對點中 一個消息只能被一個消費者消費，一旦消費成功，該消息就從隊列中清除，如果不清除，則可能出現重復消費的情況
點對多 (發布與訂閱)
發布者：
主題：
訂閱者：
客戶端將消息發送到主題。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
點對多特點：
1 .發布者發布到主題的消息可以被多個訂閱者訂閱消費
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之后，才能消費發布者的消息，而且為了消費消息，訂閱者必須保持運行的狀態。
為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。
如果你希望發送的消息可以不被做任何處理、或者被一個消息者處理、或者可以被多個消費者處理的話，那么可以采用點對多模型
在JMS中，消息的產生和消息是異步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。
○ 同步
訂閱者或接收者調用receive方法來接收消息，receive方法在能夠接收到消息之前（或超時之前）將一直阻塞
○ 異步
訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之后，系統自動調用監聽器的onMessage方法。
可以理解成廣播，或者電視的場景