任務分發或系統互動, 我們很容易可以想到就是兩種方式主動推送和被動拉取.
push
主動推一般需要建立長連線, 也可以通過乙個註冊中心知道所有的推送位址通過http推送. 優點 : 更加及時, 有任務就可以push. 缺點 : 無法根據對方的消費能力進行判斷, 任務量過大可能會把對方壓垮.
pull
被動拉取任務, 一般呼叫服務的介面或者消費服務的mq訊息就行. 大部分的mq框架都是pull的模型. 優點 : 就是不會有push的壓力過大的問題. 缺點 : 拉取的頻率很難設定, 時間長了任務消費不及時, 時間短了有很多空輪詢對服務端造成壓力.
這種方式最簡單, 因為效能不好, 需要重複的請求. 僅僅適用於業務量比較小的場景.
apollo 配置中心就是採用長輪詢的方式, 客戶端從服務端獲取配置的變更.
rocket mq 雖然有 pushconsumer, 但其實內部也是使用長輪詢的拉取方式.
// todo
// todo
先拉取任務, 消費完, 需要反饋給服務端是否可以繼續消費, 如果有服務端就可以直接push任務. 這樣就不用每次都能乙個間隔時間再來拉取, 提高及時性.
如何進行架構技術方案選型
在架構設計時,通常面臨的乙個難題是,如何選擇架構的技術方案.這也是各種專案都會碰到的問題.我們到底是選擇c s，b s模式，如果選擇c s,那麼到底是三層c s還是兩層，到底要不要分布式，b s的展示層是自己寫mvc，還是應用已有的開源的如spring mvc，struts 2.0,jsf技術。總之...
如何進行架構技術方案選型
在架構設計時,通常面臨的乙個難題是,如何選擇架構的技術方案.這也是各種專案都會碰到的問題.我們到底是選擇c s，b s模式，如果選擇c s,那麼到底是三層c s還是兩層，到底要不要分布式，b s的展示層是自己寫mvc，還是應用已有的開源的如spring mvc，struts 2.0,jsf技術。總之...
延遲任務排程系統 技術選型與設計（上篇）
redis實現 delayqueue實現 時間輪實現 之前的設計 db delayqueue zookeeper 另一種方案 db delayqueue zookeeper mq 下面所討論技術方案的前提是精確觸發，所以我們不討論目前業界的一些分布式排程系統如 elastic job,xxl job...