我畫了個簡單的架構圖來幫助說明:
其實為發布訂閱架構模式.
生產者和消費者我們統一可理解為客戶端，訊息中介軟體可認為是服務端.
生產者和消費者做為客戶端要跟服務端互動，則先通過**訂閱服務端，訂閱成功後即可跟服務端互通互聯，此刻的連線通道為長連線.
長連線的優勢在於會將訊息主動通知到客戶端，避免客戶端去做大量的輪詢工作而造成資源浪費，而且對於移動應用來說，可較大程度上節省gprs流量.
當連線建立好後，生產者可隨時傳送訊息，如果在發訊息過程當中，服務端由於各種原因不能連線，則訊息的傳送會回放重試，當達到一定的閥值則轉為死信存擋.
而消費者則處於監聽狀態，一旦有訊息過來則立即做出響應，響應方式有兩種，1為同步，2為非同步;不同的訊息消費可以訂閱為不同的響應方式.
服務端則處於居中排程，統一處理訊息，制定傳送訊息策略，因為生產者不關心消費者，當生產者在傳送訊息的時候，要處理訊息的消費者卻停機了，則服務端會嘗試給指定的消費
者重發訊息，當超過一定時間，消費者還是處於停機狀態則此訊息轉為死信歸檔，但如果在規定的時間內消費者恢復工作，則仍會收到訊息通知避免因為沒有收到訊息而造成業務損失.
為了防止訊息的可靠性傳輸，我在每個環節都會冗餘訊息體.一旦任何乙個環節出現問題都能最大限度的保證訊息不會丟失.至於用什麼儲存機制，則靈活定製.
我們知道生產者和消費者之間通過宿主服務來互動，以message為載體,這樣的好處是一可以解耦，可以明確職責，各自獨立優化，生產者發訊息不關心消費者是誰，只是單純的執
行命令，而消費者接收到訊息後進行後續的業務處理，二來可以擴充套件，可以部署多個訊息中介軟體來應對高併發的訊息處理，避免單點的故障問題.
對於多個生產者和多個消費者如果單個服務端無法應對大併發情況，則可橫向擴充套件多個服務端，按組分配到不同的客戶端使用即可.所以可以一定程度上應對分布式的應用.
關於http長連線使用的分享
一.當時使用場景 使用者訪問 會有一條access log 這條log會有使用者的ip，為了了解每天 訪問者的地域分布情況，需要拿到這些ip去查詢ip所屬地域 這樣一下子就會有很多ip要到固定的服務 比如 上去查詢 二.分析難點和效能瓶頸 最簡單和一般的實現方式就是拿到這些ip迴圈的請求查詢 事實上...
分布式基礎 http協議
一 客戶端和服務端的請求原理 客戶端與服務端互動時將會涉及到協議的內容，通常我們使用的是http https協議。注意http協議是基於傳輸層協議 tcp udp等 之上的應用層協議，而https協議是在tcp udp和http協議之間加了一層ssl tls傳輸協議，http協議不保證安全傳輸，而h...
基於Redis實現分布式鎖
分布式鎖的基本功能 1.同一時刻只能存在乙個鎖 2.需要解決意外死鎖問題，也就是鎖能超時自動釋放 3.支援主動釋放鎖 分布式鎖解決什麼問題 多程序併發執行任務時，需要保證任務的有序性或者唯一性 準備 redis版本 2.6 redis是主從 sentinel模式 為了高可用 原理 redis2.6之...