❶ java什麼叫類屬性 實例屬性 以及區別
一個是類的方法(也叫動態屬性)和屬性(靜態屬性),通過類名來訪問
一個是對象的方法和屬性,需要通過一個實例來訪問。
靜態屬性程序一載入時 就初始化 存放在棧中
實例屬性 需要實例化後 才載入 存放在堆中
❷ java如何推送消息給前端
Java伺服器推送消息給前端主要方法:❸ 微信給特定單個用戶推送消息,用Java如何實現
導入httpcore的jar包,httpclient用httppost調用
https://api.weixin.qq.com/cgi-bin/message/mass/send?access_token=ACCESS_TOKEN
這個介面 分別傳入用戶的openid即可
參考微信的wiki
http://mp.weixin.qq.com/wiki/15/.html
根據OpenID列表群發【訂閱號不可用,服務號認證後可用】
介面調用請求說明
http請求方式: POST
POST數據說明
POST數據示例如下:
圖文消息(注意圖文消息的media_id需要通過上述方法來得到):
{
"touser":[
"OPENID1",
"OPENID2"
],
"mpnews":{
"media_id":"123dsdajkasd231jhksad"
},
"msgtype":"mpnews"
}
❹ 網易傳媒技術團隊:消息中間件實現延遲隊列的應用與實踐
早期需要延遲處理的業務場景,更多的是通過定時任務掃表,然後執行滿足條件的記錄,具有頻率高、命中低、資源消耗大的缺點。隨著消息中間件的普及,延遲消息可以很好的處理這種場景,本文主要介紹延遲消息的使用場景以及基於常見的消息中間件如何實現延遲隊列,最後給出了一個在網易公開課使用延遲隊列的實踐。
1、有效期:限時活動、拼團。。。
2、超時處理:取消超時未支付訂單、超時自動確認收貨。。。
4、重試:網路異常重試、打車派單、依賴條件未滿足重試。。。
5、定時任務:智能設備定時啟動。。。
1、RabbitMQ
1)簡介:基於AMQP協議,使用Erlang編寫,實現了一個Broker框架
a、Broker:接收和分發消息的代理伺服器
b、Virtual Host:虛擬主機之間相互隔離,可理解為一個虛擬主機對應一個消息服務
c、Exchange:交換機,消息發送到指定虛擬機的交換機上
d、Binding:交換機與隊列綁定,並通過路由策略和routingKey將消息投遞到一個或多個隊列中
e、Queue:存放消息的隊列,FIFO,可持久化
f、Channel:信道,消費者通過信道消費消息,一個TCP連接上可同時創建成百上千個信道,作為消息隔離
2)延遲隊列實現:RabbitMQ的延遲隊列基於消息的存活時間TTL(Time To Live)和死信交換機DLE(Dead Letter Exchanges)實現
a、TTL:RabbitMQ支持對隊列和消息各自設置存活時間,取二者中較小的值,即隊列無消費者連接或消息在隊列中一直未被消費的過期時間
b、DLE:過期的消息通過綁定的死信交換機,路由到指定的死信隊列,消費者實際上消費的是死信隊列上的消息
3)缺點:
a、配置麻煩,額外增加一個死信交換機和一個死信隊列的配置
b、脆弱性,配置錯誤或者生產者消費者連接的隊列錯誤都有可能造成延遲失效
2、RocketMQ
1)簡介:來源於阿里,目前為Apache頂級開源項目,使用Java編寫,基於長輪詢的拉取方式,支持事務消息,並解決了順序消息和海量堆積的問題
a、Broker:存放Topic並根據讀取Procer的提交日誌,將邏輯上的一個Topic分多個Queue存儲,每個Queue上存儲消息在提交日誌上的位置
b、Name Server:無狀態的節點,維護Topic與Broker的對應關系以及Broker的主從關系
2)延遲隊列實現:RocketMQ發送延時消息時先把消息按照延遲時間段發送到指定的隊列中(rocketmq把每種延遲時間段的消息都存放到同一個隊列中),然後通過一個定時器進行輪訓這些隊列,查看消息是否到期,如果到期就把這個消息發送到指定topic的隊列中
3)缺點:延遲時間粒度受限制(1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h)
3、Kafka
1)簡介:來源於Linkedin,目前為Apache頂級開源項目,使用Scala和Java編寫,基於zookeeper協調的分布式、流處理的日誌系統,升級版為Jafka
2)延遲隊列實現:Kafka支持延時生產、延時拉取、延時刪除等,其基於時間輪和JDK的DelayQueue實現
a、時間輪(TimingWheel):是一個存儲定時任務的環形隊列,底層採用數組實現,數組中的每個元素可以存放一個定時任務列表
b、定時任務列表(TimerTaskList):是一個環形的雙向鏈表,鏈表中的每一項表示的都是定時任務項
c、定時任務項(TimerTaskEntry):封裝了真正的定時任務TimerTask
d、層級時間輪:當任務的到期時間超過了當前時間輪所表示的時間范圍時,就會嘗試添加到上層時間輪中,類似於鍾表就是一個三級時間輪
e、JDK DelayQueue:存儲TimerTaskList,並根據其expiration來推進時間輪的時間,每推進一次除執行相應任務列表外,層級時間輪也會進行相應調整
3)缺點:
a、延遲精度取決於時間格設置
b、延遲任務除由超時觸發還可能被外部事件觸發而執行
4、ActiveMQ
1)簡介:基於JMS協議,Java編寫的Apache頂級開源項目,支持點對點和發布訂閱兩種模式。
a、點對點(point-to-point):消息發送到指定的隊列,每條消息只有一個消費者能夠消費,基於拉模型
b、發布訂閱(publish/subscribe):消息發送到主題Topic上,每條消息會被訂閱該Topic的所有消費者各自消費,基於推模型
2)延遲隊列實現:需要延遲的消息會先存儲在JobStore中,通過非同步線程任務JobScheler將到達投遞時間的消息投遞到相應隊列上
a、Broker Filter:Broker中定義了一系列BrokerFilter的子類構成攔截器鏈,按順序對消息進行相應處理
b、ScheleBroker:當消息中指定了延遲相關屬性,並且jobId為空時,會生成調度任務存儲到JobStore中,此時消息不會進入到隊列
c、JobStore:基於BTree存儲,key為任務執行的時間戳,value為該時間戳下需要執行的任務列表
d、JobScheler:取JobStore中最小的key執行(調度時間最早的),執行時間<=當前時間,將該任務列表依次投遞到所屬的隊列,對於需要重復投遞和投遞失敗的會再次存入JobStore中。
註: 此處JobScheler的執行時間間隔可動態變化,默認0.5s,有新任務時會立即執行(Object->notifyAll())並設置時間間隔為0.1s,沒有新任務後,下次執行時間為最近任務的調度執行時間。
3)缺點:投遞到隊列失敗,將消息重新存入JobStore,消息調度執行時間=系統當前時間+延遲時間,會導致消息被真實投遞的時間可能為設置的延遲時間的整數倍
5、Redis
1)簡介:基於Key-Value的NoSQL資料庫,由於其極高的性能常被當作緩存來使用,其數據結構支持:字元串、哈希、列表、集合、有序集合
2)延遲隊列實現:Redis的延遲隊列基於有序集合,score為執行時間戳,value為任務實體或任務實體引用
3)缺點:
a、實現復雜,本身不支持
b、完全基於內存,延遲時間長浪費內存資源
6、消息隊列對比
1、公開課延遲隊列技術選型
1)業務場景:關閉超時未支付訂單、限時優惠活動、拼團
2)性能要求:訂單、活動、拼團 數據量可控,上述MQ均能滿足要求
3)可靠性:使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊列更普遍
4)可用性:ActiveMQ、RocketMQ自身支持延遲隊列功能,且目前公開課業務中使用的中間件為ActiveMQ和Kafka
5)延遲時間靈活:活動的開始和結束時間比較靈活,而RocketMQ時間粒度較粗,Kafka會依賴時間格有精度缺失
結論: 最終選擇ActiveMQ來作為延遲隊列
2、業務場景:關閉未支付訂單
1)關閉微信未支付訂單
2)關閉IOS未支付訂單
3、ActiveMQ使用方式
1)activemq.xml中支持調度任務
2)發送消息時,設置message的延遲屬性
其中:
a、延遲處理
AMQ_SCHEDULED_DELAY:設置多長時間後,投遞給消費者(毫秒)
b、重復投遞
AMQ_SCHEDULED_PERIOD:重復投遞時間間隔(毫秒)
AMQ_SCHEDULED_REPEAT:重復投遞次數
c、指定調度計劃
AMQ_SCHEDULED_CRON:corn正則表達式
4、公開課使用中進行的優化
1)可靠性:針對實際投遞時間可能翻倍的問題,結合ActiveMQ的重復投遞,在消費者邏輯中做冪等處理來保證延遲時間的准確性
2)可追溯性:延遲消息及消費情況做資料庫冗餘存儲
3)易用性:業務上定義好延遲枚舉類型,直接使用JmsDelayTemplate發送,無需關心數據備份和參數等細節
1、無論是基於死信隊列還是基於數據先存儲後投遞,本質上都是將延遲待發送的消息數據與正常訂閱的隊列分開存儲,從而降低耦合度
2、無論是檢查隊頭消息TTL還是調度存儲的延遲數據,本質上都是通過定時任務來完成的,但是定時任務的觸發策略以及延遲數據的存儲方式決定了不同中間件之間的性能優劣
張浩,2018年加入網易傳媒,高級Java開發工程師,目前在網易公開課主要做支付財務體系、版本迭代相關的工作。
❺ Java消息服務的持久訂閱
JMS 通過允許創建持久訂閱來簡化時間相關性,即使消息預訂者未激活也可以接收到消息。此外,使用持久訂閱還可通過隊列提供靈活性和可靠性,而仍然允許消息被發給許多的接收者。 Topic Subscriber topic Subscriber = topicSession.createDurableSubscriber(topic, subscriptionName);
Connection 對象表示了到兩種消息模型中的任一種的消息系統的連接。伺服器端和客戶機端對象要求管理創建的JMS連接的狀態。連接是由Connection Factory創建的並且通過JNDI查尋定位。//取得用於 P2P的 QueueConnectionFactory QueueConnectionFactory = queueConnectionFactory( ); Context messaging = new InitialContext( ); QueueConnectionFactory = (QueueConnectionFactory) Messaging.lookup(「QueueConnectionFactory」); //取得用於 pub/sub的 TopicConnectionFactory TopicConnectonFactory topicConnectionFactory; Context messaging = new InitialContext(); topicConnectionFactory = (TopicConnectionFactory) messaging.lookup(「TopicConnectionFactory」);
注意:用於P2P的代碼和用於PublishSubscribe的代碼非常相似。
如果 session 被標記為 transactiona l的話,確認消息就通過確認和校正來自動地處理。如果 session 沒有標記為 transactional,你有三個用於消息確認的選項:
· AUTO_ACKNOWLEDGE:session 將自動地確認收到一則消息;
· CLIENT_ACKNOWLEDGE:客戶端程序將確認收到一則消息,調用這則消息的確認方法;
· DUPS_OK_ACKNOWLEDGE:這個選項命令 session 「懶散地」確認消息傳遞,可以想到,這將導致消息提供者傳遞的一些復制消息可能會出錯。這種確認的方式只應當用於消息消費程序可以容忍潛在的副本消息存在的情況。 queueSession = queueConnection.createQueueSession(false, session.AUTO_ACKNOWLEDGE);//P2P topicSession = topicConnection.createTopicSession(false, session.AUTO_ACKNOWLEDGE); //Pub-Sub
注意:在本例中,一個session目的從連結中創建,非值指出session是non-transactional的,並且 session將自動地確認收到一則消息。
❻ java redis消息訂閱與發布 消息發布後 會丟失嗎
subscribe是一個阻塞的方法,在取消訂閱該頻道前,會一直阻塞在這,只有當取消了訂閱才會執行下面的other code,參考上面代碼,我在onMessage裡面收到消息後,調用了this.unsubscribe(); 來取消訂閱,這樣才會執行後面的other code!java redis消息訂閱與發布 消息發布後 會丟失嗎