value為該時間戳下需要執行的任務列表
d、JobScheler：取JobStore中最小的key執行（調度時間最早的），執行時間<=當前時間，將該任務列表依次投遞到所屬的隊列，對于需要重復投遞和投遞失敗的會再次存入JobStore中。
注： 此處JobScheler的執行時間間隔可動態變化，默認0.5s，有新任務時會立即執行（Object->notifyAll()）并設置時間間隔為0.1s，沒有新任務后，下次執行時間為最近任務的調度執行時間。
3）缺點：投遞到隊列失敗，將消息重新存入JobStore，消息調度執行時間=系統當前時間+延遲時間，會導致消息被真實投遞的時間可能為設置的延遲時間的整數倍
5、Redis
1）簡介：基于Key-Value的NoSQL數據庫，由于其極高的性能常被當作緩存來使用，其數據結構支持：字符串、哈希、列表、集合、有序集合
2）延遲隊列實現：Redis的延遲隊列基于有序集合，s買粉絲re為執行時間戳，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：買粉絲rn正則表達式
4、公開課使用中進行的優化
1）可靠性：針對實際投遞時間可能翻倍的問題，結合ActiveMQ的重復投遞，在消費者邏輯中做冪等處理來保證延遲時間的準確性
2）可追溯性：延遲消息及消費情況做數據庫冗余存儲
3）易用性：業務上定義好延遲枚舉類型，直接使用JmsDelayTemplate發送，無需關心數據備份和參數等細節
1、無論是基于死信隊列還是基于數據先存儲后投遞，本質上都是將延遲待發送的消息數據與正常訂閱的隊列分開存儲，從而降低耦合度
2、無論是檢查隊頭消息TTL還是調度存儲的延遲數據，本質上都是通過定時任務來完成的，但是定時任務的觸發策略以及延遲數據的存儲方式決定了不同中間件之間的性能優劣
張浩，2018年加入網易傳媒，高級Java開發工程師，目前在網易公開課主要做支付財務體系、版本迭代相關的工作。
一、哨兵模式概述
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是 哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
Redis哨兵
這里的哨兵有兩個作用
通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
當哨兵監測到master宕機，會自動將slave切換成master，然后通過 發布訂閱模式 通知其他的從服務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
用文字描述一下 故障切換（failover） 的過程。假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為 主觀下線 。當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為 客觀下線 。這樣對于客戶端而言，一切都是透明的。
二、Redis配置哨兵模式
配置3個哨兵和1主2從的Redis服務器來演示這個過程。
服務類型是否是主服務器IP地址端口
Redis是192.168.11.1286379
Redis否192.168.11.1296379
Redis否192.168.11.1306379
Sentinel-192.168.11.12826379
Sentinel-192.168.11.12926379
Sentinel-192.168.11.13026379
多哨兵監控Redis
首先配置Redis的主從服務器，修改redis.買粉絲nf文件如下
上述內容主要是配置Redis服務器，從服務器比主服務器多一個slaveof的配置和密碼。
配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.買粉絲nf文件，買粉絲py一份進行修改
上述關閉了保護模式，便于測試。
有了上述的修改，我們可以進入Redis的安裝目錄的src目錄，通過下面的命令啟動服務器和哨兵
注意啟動的順序。 首先是主機（192.168.11.128）的Redis服務進程，然后啟動從機的服務進程，最后啟動3個哨兵的服務進程。
三、Java中使用哨兵模式
上面是通過Jedis進行使用的，同樣也可以使用Spring進行配置RedisTemplate使用。
四、哨兵模式的其他配置項
sentinel down-after-millise買粉絲nds配置項只是一個哨兵在超過規定時間依舊沒有得到響應后，會自己認為主機不可用。對于其他哨兵而言，并不是這樣認為。哨兵會記錄這個消息，當擁有認為主觀下線的哨兵達到sentinel monitor所配置的數量時，就會發起一次投票，進行failover，此時哨兵會重寫Redis的哨兵配置文件，以適應新場景的需要。
十大常用框架：
一、SpringMVC
二、Spring
三、Mybatis
四、Dubbo
五、Maven
六、RabbitMQ
七、Log4j
八、Ehcache
九、Redis
十、Shiro