java webservice(java webservice接口調(diào)用)

一發(fā)一存一消費(fèi)，沒有最好的消息隊列中間件(簡稱消息中間件)，只有最合適的消息中間件。

消息隊列常用的使用場景：非實時性：當(dāng)不需要立即獲得結(jié)果，但是并發(fā)量又需要進(jìn)行控制的時候，差不多就是需要使用消息隊列的時候。主要解決了應(yīng)用耦合、異步處理、流量削鋒等問題。應(yīng)用耦合：多應(yīng)用間通過消息隊列對同一消息進(jìn)行處理，避免調(diào)用接口失敗導(dǎo)致整個過程失敗；（如：訂單->庫存）異步處理：多應(yīng)用對消息隊列中同一消息進(jìn)行處理，應(yīng)用間并發(fā)處理消息，相比串行處理，減少處理時間；(點(diǎn)對多場景，廣播場景(注冊發(fā)短信，發(fā)郵件)等等)限流削峰：應(yīng)用于秒殺或搶購活動中，避免流量過大導(dǎo)致應(yīng)用系統(tǒng)掛掉的情況；(根據(jù)服務(wù)承受度設(shè)置隊列大小，超過了就返回活動結(jié)束了，咱們經(jīng)常各大商城秒殺，心里還沒有點(diǎn)B數(shù)嗎)減少壓力,避免服務(wù)掛掉。消息驅(qū)動的系統(tǒng)：系統(tǒng)分為消息隊列、消息生產(chǎn)者、消息消費(fèi)者，生產(chǎn)者負(fù)責(zé)產(chǎn)生消息，消費(fèi)者(可能有多個)負(fù)責(zé)對消息進(jìn)行處理；(分工處理(各自對應(yīng)相應(yīng)的隊列)，靈活應(yīng)用(收到就處理/定時處理))消息隊列是異步RPC的主要手段之一兩種模式：

點(diǎn)對點(diǎn)：每個消息只有一個消費(fèi)者（Consumer），不可重復(fù)消費(fèi)(一旦被消費(fèi)，消息就不再在消息隊列中)

發(fā)布/訂閱：微信公眾號(Topic)，大伙(訂閱者)訂閱關(guān)注之后，微信公眾號運(yùn)營平臺(發(fā)布者)發(fā)布信息后，大伙微信就都收到信息了，這里其實還分pull/push的。一個是主動推送，一個是被動拉取

基于發(fā)布/訂閱模式做擴(kuò)展就是橫向擴(kuò)展，多個隊列及消費(fèi)分組訂閱(提高消費(fèi)能力)

pull：主動權(quán)在于消費(fèi)方，優(yōu)點(diǎn)是按需消費(fèi)(吃自助餐，能吃多少拿多少)，而且服務(wù)端隊列堆積的消息處理也相對簡單(不用記錄狀態(tài)啊，狀態(tài)都消費(fèi)端)；缺點(diǎn)就是消息延遲(不知道啥時候去拉取更新)，這時候有小伙伴會問，那為啥不叫服務(wù)端通知一下呢(有句話叫不在其位不謀其政，服務(wù)端通知必然要記錄通知狀態(tài)和增加之間的通信帶寬；當(dāng)然也可以根據(jù)實際情況來選擇和push組合起來用(男女搭配干活不累嘛)來提高消息的實時性)

push：主動權(quán)就在服務(wù)方了，優(yōu)點(diǎn)是實時性高，服務(wù)端可以統(tǒng)一管理來進(jìn)行負(fù)載，不過也容易導(dǎo)致慢消費(fèi)(就得考慮消費(fèi)方受不受得了，畢竟你說你了解，但也只有對方才清楚你有多了解)；缺點(diǎn)就是發(fā)送消息的狀態(tài)是集中式管理，壓力大啊(要分發(fā)消息還要記錄狀態(tài)還要做備份，又當(dāng)?shù)鶃碛之?dāng)媽，你說累不累)

對于順序消息，這種場景有限且成本太高的方式就得慎重考慮了，對那種全局有序但允許出現(xiàn)小誤差的場景(日志推送)，pull模式就非常適合了(所以說kafka為啥常用于日志處理、大數(shù)據(jù)等方面)，要問為什么？自己去領(lǐng)悟，這里給大家分享一份詳細(xì)介紹中間件的文檔

由于篇幅原因，為了避免影響到大家的閱讀體驗，在此只以截圖展示部分內(nèi)容，有需要的小伙伴麻煩三連支持一下，私信小編【學(xué)習(xí)】即可~~~

目錄

第1章中間件技術(shù)導(dǎo)論

第2章 應(yīng)用服務(wù)器概述

第3章準(zhǔn)備上手

第4章JSP編程范例

第5章Java Servlet編程范例.

第6章JDBC 數(shù)據(jù)庫編程范例

第7章使用 Java進(jìn)行XML編程

第8章分布式對象概述

第9章RMI 編程范例

第10章EJB 編程范例

第11章CORBA以及Java IDL編程范例

第12章JNDI 編程范例.

第13章Java 開發(fā)Web Service .

第14章消息中 ****間件****概述

第15章JMS 應(yīng)用開發(fā)

第16章JavaMail 應(yīng)用開發(fā)

第17章數(shù)據(jù)集成中間件

第18章門戶(Portal) 中間件

第19章網(wǎng)格中間件

第20章工作流中 間件

第21章中間件技術(shù)的最新進(jìn)展

給大家展示一下部分內(nèi)容

實際開發(fā)中消息中間件選型基于幾個方面：功能：這個就多了，優(yōu)先級隊列、延遲隊列(劃分不同的延遲隊列來避免重新排序消耗性能，缺點(diǎn)嘛自己悟)、死信隊列(放沒有推送成功的)、消費(fèi)模式(pull/push)、廣播消費(fèi)、消息回溯(可追溯嘛，不然被賣了都不知道是誰)、消息堆積+持久化、消息追蹤(鏈路條，方便定位)、消息過濾(根據(jù)規(guī)則過濾啊，不同類別消息發(fā)送到不同topic)、多協(xié)議支持(通用性)、跨語言支持(流行程度)、流量控制(嘿嘿嘿，上面有)、消息順序性(還要再說一遍？)、安全機(jī)制(身份認(rèn)證，權(quán)限認(rèn)證(讀寫))、消息冪等性(承諾知道不，答應(yīng)人家的事就一定要做到)、事務(wù)性消息(不想說)等性能：一般是指其吞吐量(統(tǒng)一大小的消息體和不同大小的消息體生產(chǎn)和消耗能力)，性能和功能很多時候是相悖的，魚和熊掌不可兼得。高可靠、高可用：先說可靠，主要在于消息的持久化這一塊(消息只要寫入就一定會被消費(fèi)，不會因為故障導(dǎo)致數(shù)據(jù)丟失(這個就很好測試出來了吧))。如果是從系統(tǒng)的角度來看就得從整體的維度去衡量了(不能單單只靠消息中間件本身，要從生產(chǎn)端、服務(wù)端、消費(fèi)端三個維度去保障)。再說可用，主要在于一個是對外部服務(wù)的依賴性(像kafka依賴zookeeper)，依賴也分強(qiáng)依賴和弱依賴，一個在于本身的備份機(jī)制所帶來的保障性(像主從復(fù)制這種備份啊，增加多個slave來加強(qiáng)保障同時也會存在資源浪費(fèi)，大部分時候Slave可能是空閑的)。運(yùn)維：通常有審核評估啊、監(jiān)控啊、報警提醒啊、容災(zāi)啊、擴(kuò)容啊、升級部署等等，一方面看中間件支撐的維度，一方面就看結(jié)合自動化運(yùn)維的難易度社區(qū)力度及生態(tài)發(fā)展：這個好理解吧，使用開源框架最開始基本上愉快的奔跑，但時不時的總會掉坑里，能不能爬出來一方面看自身的實力，一方面就看社區(qū)的力度了成本： 盡量貼合團(tuán)隊自身的技術(shù)棧體系，讓一個C棧的團(tuán)隊去深挖zeroMQ總比scala編寫kafka要容易的多

由于篇幅原因，為了避免影響到大家的閱讀體驗，在此只以截圖展示部分內(nèi)容，有需要的小伙伴麻煩三連支持一下，私信小編【學(xué)習(xí)】即可~~~