序
本文屬於奈學教育rocketmq學習筆記。主講老師陳東。
推薦在線觀看，效果更好。因爲不但講理論，更從實踐觸發，踩過哪些坑。
1.目錄
應用場景分析：
使用topic管理。概念理解。
例子：運營活動靈活，修改頻繁。硬編碼頻繁修改不適用業務場景。
改進：使用mq統一訂閱，抽取出專門的businesslogic 專門調用核心業務。提升系統的穩定性。
當然，老師額外講了一個優化點：從這個點來看，的確是乾貨。
怎麼實現一個連續5天登錄送獎勵的優化。
如果默認：每次登錄都記錄。那麼記錄很多，而且判斷複雜。
優化1：想辦法每天記錄爲一條。
優化2： 使用bimmap:每天1位，累計使用：位運算《1+1. 推薦16進制。
使用mq:解耦。各個業務訂閱自己業務關注的topic。進而處理
三大場景： 業務解耦、異步調用、流量削峯
提升穩定性，但不是替代rpc,因爲mq有全局性問題。
對於下單業務場景：
對於必須同步的場景：風控攔截、扣減庫存是必須的rpc. 後面的非必要的同步，可以走異步mq。
秒殺的業務場景：
綜合考慮：
該同步同步，該異步就異步，不能完全替代RPC。
影響點： 系統複雜度、可用性。排查問題難度：（根據mq能追蹤到消費者）推薦調用鏈
這塊是評估問題的點，就是權衡的維度。對於擴展思路很有用。
所謂成熟就是大廠發展了幾年，坑都踩過了，渠去 哪裏查資料。
老師額外提了下：順序性如何實現，就是放到一個隊列。單線程消費。是個取巧的實現。
上面的圖：有主從master\slave, 有分佈式：master1,master2 ,體現了災備；
註冊信息在nameserver。
這個圖的nameserver獨立的，所以沒法選主。
刷盤指flush操作，真正落盤。
同步刷盤+同步雙寫。 最可靠。
topic-->broker->matser
commitlog 順序追加寫
怎麼消費呢？有 dispatch線程讀取後按照topic放到 consumerQueue，
隊列裏面存儲的不是消息的內容，而是commitlog的offset,跟大小，這樣就能找到對應的內容。
maxoffset用於寫入新的。
consomeoffset 指消費的位置。
順序寫，隨機讀，如何保證消費性能？
kafka 順序寫，順序讀，所以性能很高。
切分，就是縮小隨機讀的範圍。mmap 使用虛擬內存。ssd提升硬件性能。
生產方式：
同步、異步、單向
根據也無需求提供多種方式去選擇。
push:實時性高，但是可能積壓。
pull:實時性不好，可能有大量無效請求。
group內競爭，group間廣播
前提：每個隊列自能一個消費者，不能多個消費者都消費同一個隊列。
這個圖體現了上次分配結果對比，紅色是沒有的去掉，綠色是已經有的，白色是新分配的，最後生成新的隊列。
新的問題：新加入的consumer如何實現？
老師的講解還是不錯的，快速入門，從總體上熟悉mq的架構，有個整體印象更容易串起來。