當你看到這個文章時,想必已經了解了一些關于spring-redis發布訂閱方面的知識,如果你也遇到同樣的問題
那么請考慮spring在啟動時有沒有重復的加載配置文件
具體的方式可以在 AbstractApplicationContext 的 refresh() 方法中打斷點,如果走了兩次,說明配置文件加載了兩遍
而配置文件加載兩遍的原因是因為web.xml中DispatcherServlet和ContextLoaderLinistener 共用了 某些配置文件導致的。
一、哨兵模式概述
哨兵模式是一種特殊的模式,首先Redis提供了哨兵的命令,哨兵是一個獨立的進程,作為進程,它會獨立運行。其原理是 哨兵通過發送命令,等待Redis服務器響應,從而監控運行的多個Redis實例。
Redis哨兵
這里的哨兵有兩個作用
通過發送命令,讓Redis服務器返回監控其運行狀態,包括主服務器和從服務器。
當哨兵監測到master宕機,會自動將slave切換成master,然后通過 發布訂閱模式 通知其他的從服務器,修改配置文件,讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控,可能會出現問題,為此,我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控,這樣就形成了多哨兵模式。
用文字描述一下 故障切換(failover) 的過程。假設主服務器宕機,哨兵1先檢測到這個結果,系統并不會馬上進行failover過程,僅僅是哨兵1主觀的認為主服務器不可用,這個現象成為 主觀下線 。當后面的哨兵也檢測到主服務器不可用,并且數量達到一定值時,那么哨兵之間就會進行一次投票,投票的結果由一個哨兵發起,進行failover操作。切換成功后,就會通過發布訂閱模式,讓各個哨兵把自己監控的從服務器實現切換主機,這個過程稱為 客觀下線 。這樣對于客戶端而言,一切都是透明的。
二、Redis配置哨兵模式
配置3個哨兵和1主2從的Redis服務器來演示這個過程。
服務類型是否是主服務器IP地址端口
Redis是192.168.11.1286379
Redis否192.168.11.1296379
Redis否192.168.11.1306379
Sentinel-192.168.11.12826379
Sentinel-192.168.11.12926379
Sentinel-192.168.11.13026379
多哨兵監控Redis
首先配置Redis的主從服務器,修改redis.買粉絲nf文件如下
上述內容主要是配置Redis服務器,從服務器比主服務器多一個slaveof的配置和密碼。
配置3個哨兵,每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.買粉絲nf文件,買粉絲py一份進行修改
上述關閉了保護模式,便于測試。
有了上述的修改,我們可以進入Redis的安裝目錄的src目錄,通過下面的命令啟動服務器和哨兵
注意啟動的順序。 首先是主機(192.168.11.128)的Redis服務進程,然后啟動從機的服務進程,最后啟動3個哨兵的服務進程。
三、Java中使用哨兵模式
上面是通過Jedis進行使用的,同樣也可以使用Spring進行配置RedisTemplate使用。
四、哨兵模式的其他配置項
sentinel down-after-millise買粉絲nds配置項只是一個哨兵在超過規定時間依舊沒有得到響應后,會自己認為主機不可用。對于其他哨兵而言,并不是這樣認為。哨兵會記錄這個消息,當擁有認為主觀下線的哨兵達到sentinel monitor所配置的數量時,就會發起一次投票,進行failover,此時哨兵會重寫Redis的哨兵配置文件,以適應新場景的需要。
一、消息隊列概述
消息隊列中間件是分布式系統中重要的組件,主要解決應用耦合,異步消息,流量削鋒等問題。實現高性能,高可用,可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境,使用較多的消息隊列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。
二、消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。異步處理,應用解耦,流量削鋒和消息通訊四個場景。
2.1異步處理
場景說明:用戶注冊后,需要發注冊郵件和注冊短信。傳統的做法有兩種1.串行的方式;2.并行方式。
(1)串行方式:將注冊信息寫入數據庫成功后,發送注冊郵件,再發送注冊短信。以上三個任務全部完成后,返回給客戶端。(架構KKQ:466097527,歡迎加入)
(2)并行方式:將注冊信息寫入數據庫成功后,發送注冊郵件的同時,發送注冊短信。以上三個任務完成后,返回給客戶端。與串行的差別是,并行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鐘,不考慮網絡等其他開銷,則串行方式的時間是150毫秒,并行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的,假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次(1000/150)。并行方式處理的請求量是10次(1000/100)。
小結:如以上案例描述,傳統的方式系統的性能(并發量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?
引入消息隊列,將不是必須的業務邏輯,異步處理。改造后的架構如下:
按照以上約定,用戶的響應時間相當于是注冊信息寫入數據庫的時間,也就是50毫秒。注冊郵件,發送短信寫入消息隊列后,直接返回,因此寫入消息隊列的速度很快,基本可以忽略,因此用戶的響應時間可能是50毫秒。因此架構改變后,系統的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了兩倍。
2.2應用解耦
場景說明:用戶下單后,訂單系統需要通知庫存系統。傳統的做法是,訂單系統調用庫存系統的接口。如下圖:
傳統模式的缺點:
1) 假如庫存系統無法訪問,則訂單減庫存將失敗,從而導致訂單失敗;
2) 訂單系統與庫存系統耦合;
如何解決以上問題呢?引入應用消息隊列后的方案,如下圖:
訂單系統:用戶下單后,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。
庫存系統:訂閱下單的消息,采用拉/推的方式,獲取下單信息,庫存系統根據下單信息,進行庫存操作。
假如:在下單時庫存系統不能正常使用。也不影響正常下單,因為下單后,訂單系統寫入消息隊列就不再關心其他的后續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景,一般在秒殺或團搶活動中使用廣泛。
應用場景:秒殺活動,一般會因為流量過大,導致流量暴增,應用掛掉。為解決這個問題,一般需要在應用前端加入消息隊列。
可以控制活動的人數;
可以緩解短時間內高流量壓垮應用;
用戶的請求,服務器接收后,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面;
秒殺業務根據消息隊列中的請求信息,再做后續處理。
2.4日志處理
日志處理是指將消息隊列用在日志處理中,比如Kafka的應用,解決大量日志傳輸的問題。架構簡化如下:
日志采集客戶端,負責日志數據采集,定時寫受寫入Kafka隊列;
Kafka消息隊列,負責日志數據的接收,存儲和轉發;
日志處理應用:訂閱并消費kafka隊列中的日志數據;
以下是新浪kafka日志處理應用案例:
(1)Kafka:接收用戶日志的消息隊列。
(2)Logstash:做日志解析,統一成JSON輸出給Elasticsearch。
(3)Elasticsearch:實時日志分析服務的核心技術,一個schemaless,實時的數據存儲服務,通過index組織數據,兼具強大的搜索和統計功能。
(4)Kibana:基于Elasticsearch的數據可視化組件,超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指,消息隊列一般都內置了高效的通信機制,因此也可以用在純的消息通訊。比如實現點對點消息隊列,或者聊天室等。
點對點通訊:
客戶端A和客戶端B使用同一隊列,進行消息通訊。
聊天室通訊:
客戶端A,客戶端B,客戶端N訂閱同一主題,進行消息發布和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式,點對點或發布訂閱模式。模型為示意圖,供參考。
三、消息中間件示例
3.1電商系統
消息隊列采用高可用,可持久化的消息中間件。比如Active MQ,Rabbit MQ,Rocket Mq。(1)應用將主干邏輯處理完成后,寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。(消息隊列返回消息接收成功狀態后,應用再返回,這樣保障消息的完整性)
(2)擴展流程(發短信,配送處理)訂閱隊列消息。采用推或拉的方式獲取消息并處理。
(3)消息將應用解耦的同時,帶來了數據一致性問題,可以采用最終一致性方式解決。比如主數據寫入數據庫,擴展應用根據消息隊列,并結合數據庫方式實現基于消息隊列的后續處理。
3.2日志收集系統
分為Zookeeper注冊中心,日志收集客戶端,Kafka集群和Storm集群(OtherApp)四部分組成。
Zookeeper注冊中心,提出負載均衡和地址查找服務;
日志收集客戶端,用于采集應用系統的日志,并將數據推送到kafka隊列;
四、JMS消息服務
講消息隊列就不得不提JMS 。JMS(Java Message Service,Java消息服務)API是一個消息服務的標準/規范,允許應用程序組件基于JavaEE平臺創建、發送、接收和讀取消息。它使分布式通信耦合度更低,消息服務更加可靠以及異步性。
在EJB架構中,有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中,有消息服務者模式,用于實現消息與應用直接的解耦。
4.1消息模型
在JMS標準中,有兩種消息模型P2P(Point to Point),Publish/Subscribe(Pub/Sub)。