qmq是一款去哪兒網內部使用多年的mq。不久前(大概1-2年前)已在攜程投入生產大規模使用，年前這款mq也開源了出來。關於qmq的相關設計文章可以看這裡。在這裡，我假設你已經對qmq前世今生以及其設計和實現等背景知識已經有了乙個較為全面的認識。對於delay-server，官方已經有了一些介紹。記住，官方通常是最賣力的那個"媒婆"。qmq-delay-server其實主要做的是**工作。所謂**，就是delay-server做的就是個儲存和投遞的工作。怎麼理解，就是qmq-client會對訊息進行乙個路由，即實時訊息投遞到實時server，延遲訊息往delay-server投遞，多說一句，這個路由的功能是由qmq-meta-server提供。投遞到delay-server的訊息會存下來，到時間之後再進行投遞。現在我們知道了
儲存和投遞是delay-server主要的兩個功能點。那麼我們挨個擊破.
儲存投遞
解決了儲存，那麼到期的延遲訊息如何投遞呢？如在上一小節儲存中所提到的，記憶體中的hashwheel會提前一段時間載入delay_schedule_index，這個時間自然也是可以配置的。而在hashwheel中，預設每500ms會tick一次，這個500ms也是可以根據使用者需求配置的。而在投遞的時候，qmq根據實時broker進行分組多執行緒投遞，如果某一broker離線不可用，導致投遞失敗，delay-server會將延遲訊息投遞在其他存活的實時broker。其實這裡對於實時的broker應該有乙個關於投遞訊息權重的，現在delay-server沒有考慮到這一點，不過我看已經有乙個pr解決了這個問題，只是官方還沒有時間看這個問題。除此之外，qmq還考慮到了要是當前延遲訊息所屬的delay_segment已經載入到記憶體中的hashwheel了，這個時候訊息應該是直接投遞或也應載入到hashwheel中的。這裡需要考慮的情況還是比較多的，比如考慮delay_segment正在載入、已經載入、載入完成等情況，對於這種情況，qmq用了兩個cursor來表示hashwheel載入到哪個delay_segment以及載入到對應segment的什麼offset了，這裡還是挺複雜的，這裡的**邏輯在wheeltickmanager這個類。
原始碼分析之LayoutInflater
簡介 inflate填充的過程 viewstub,merge,include的載入過程 layoutinflater系統服務的註冊過程 systemserviceregistry類有個靜態 塊，完成了常用服務的註冊，如下 static 註冊am registerservice context.act...
原始碼分析之HashMap
首先hashmap繼承了abstractmap，並且實現了map cloneable和serializable三個介面。cloneable和serializable是比較常規的兩個介面，在這裡並不作為重點。重點將會放在abstractmap和map兩個規範上。其中abstractmap是乙個抽象類，...
原始碼分析之String
先看屬性 底層是char陣列，一目了然 可以看到，value是儲存string的內容的，即當使用string str abc 的時候，本質上，abc 是儲存在乙個char型別的陣列中的。string底層的儲存結構是乙個字元型別的陣列，同樣也是被final修飾，因此一旦這個字元陣列被建立後，value...