網易資深java開發工程師,網易雲微專業Java高級工程師

本文目錄一覽:

網易2011成都地區JAVA開發工程師的筆試地點在哪裡

我也報的網易的Java工程師,後來網易給我發郵件了在電子科技大學清水河校區。如果你的簡歷篩選通過了網易會給你發郵件和短信通知筆試的。祝你成功。

網易java哪個部門好

網易電商部門招聘

java後台開發工程師

基本要求:

1、精通java,或者精通C/C 有意願轉到java;

2、熟悉常用數據庫,如oracle、mysql等;

3、熟悉常用數據結構和算法;

4、有一定的溝通能力和工作抗壓能力;

加分項:

1、熟悉電商業務流程;

2、熟悉spring和mybatis框架;

3、熟悉前端反向代理服務器nginx,熟悉後端服務器tomcat或者resin;

4、熟悉並發編程。

網易傳媒技術團隊:消息中間件實現延遲隊列的應用與實踐

早期需要延遲處理的業務場景,更多的是通過定時任務掃表,然後執行滿足條件的記錄,具有頻率高、命中低、資源消耗大的缺點。隨着消息中間件的普及,延遲消息可以很好的處理這種場景,本文主要介紹延遲消息的使用場景以及基於常見的消息中間件如何實現延遲隊列,最後給出了一個在網易公開課使用延遲隊列的實踐。

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並根據讀取Producer的提交日誌,將邏輯上的一個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中,通過異步線程任務JobScheduler將到達投遞時間的消息投遞到相應隊列上

a、Broker Filter:Broker中定義了一系列BrokerFilter的子類構成攔截器鏈,按順序對消息進行相應處理

b、ScheduleBroker:當消息中指定了延遲相關屬性,並且jobId為空時,會生成調度任務存儲到JobStore中,此時消息不會進入到隊列

c、JobStore:基於BTree存儲,key為任務執行的時間戳,value為該時間戳下需要執行的任務列表

d、JobScheduler:取JobStore中最小的key執行(調度時間最早的),執行時間=當前時間,將該任務列表依次投遞到所屬的隊列,對於需要重複投遞和投遞失敗的會再次存入JobStore中。

註: 此處JobScheduler的執行時間間隔可動態變化,默認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 開發工程師是什麼職位

簡單來講就是IT編程技術崗位,只不過可能要求比基礎的java開發工程師更多,無論是從技術上還是軟性技能上來講。下面舉個招聘網站上的例子,幫助了解一下。

原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/310029.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
小藍的頭像小藍
上一篇 2025-01-04 19:32
下一篇 2025-01-04 19:32

相關推薦

發表回復

登錄後才能評論