redis的pub sub功能相較於常見的rabbitmq等訊息中介軟體還是有一些差異，在使用前需要進行甄別，確認是否適用當前專案，畢竟技術選型脫離現實是耍流氓。網上有很多這方面的文章，這裡就不貼了，使用難度不大。
由於服務基本都是多例項部署，當例項中訂閱了某個channel時，也就意味著多個例項都訂閱了同乙個channel，於是就會導致同乙個訊息會被多個例項同時消費，產生了重複處理的情況。
此時不管是做訂閱方的冪等，還是分布式鎖，還是配置檔案增加開關控制，都會增加開發和運維的複雜度，同時增加很大不確定性。
這時候redis其實還有一種變相的替代方案：redis list，利用push pop方式來實現佇列。
這樣等於使用了乙個有序的list方式，實現乙個先進先出的佇列。
對應spring-data-redis的方法：
@component
@slf4j
public
class
redispublisherdemo
}@component
@slf4j
public
class
redisconsumerdemo
implements
public
void
studioeventconsumer()
catch
(exception e)}}
).start()
;}}
你可以選擇忽略，因為我們就占用了乙個redis的連線，這個連線後面redis也會自己收回。
如果覺得不嚴謹，可以參考下面的**，在專案停止的時候，銷毀bean時做個手腳，將我們建立的執行緒顯式的中段掉。以下**僅作為乙個方案作為參考，問題不大，可能不嚴謹。
@component
@slf4j
public
class
redisconsumerdemo
implements
}studioeventconsumer()
;}@predestroy
public
void
destroy()
public
void
studioeventconsumer()
catch
(exception e)}}
}); studioeventthread.
start()
;}}
訊息中介軟體 MQ
1 為什麼需要訊息佇列mq 因為在高併發環境下，由於來不及同步處理，請求往往會發生阻塞，比如 大量的insert，update語句請求同時到達mysql，直接導致無數的行鎖鎖表，甚至最後的請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，可以非同步的處理請求，從...
MQ訊息中介軟體
mq是message queue,就是訊息佇列。是進行通訊的中介軟體產品，可以把訊息佇列比作是乙個存放訊息的容器，呼叫的方法就是訊息，把方法存到佇列中然後從佇列中取出方法去執行。目前使用較多的訊息佇列有activemq，rabbitmq，kafka，rocketmq。訊息佇列的作用有非同步 削峰 解...
訊息中介軟體MQ
訊息中介軟體利用高效可靠的訊息傳遞機制進行平台無關的資料交流，並基於資料通訊來進行分布式系統的整合。通過提供訊息傳遞和訊息排隊模型，它可以在分布式環境下擴充套件程序間的通訊。對於訊息中介軟體，常見的角色大致也就有producer 生產者 consumer 消費者 訊息佇列中介軟體是分布式系統中重要的...