系統背景： 生產者往redis丟訊息，消費者從redis取訊息傳送 redis使用list作為訊息佇列，佇列數N個 每種接入系統分配2種（傳送，重發），分別3個固定佇列，優先順序高中低，該3個佇列由一個執行緒處理，通過分配的時間片大小去體現優先順序 不同接入系統的執行緒之間沒有優先順序之分，交給CPU去排程 1、禁用keys XXXX 即使你再牛逼，這個都不能用，記住它的時間複雜度是O(N)，N是key的數量，你還敢用嗎？？？？用了會腎疼 2、redis操作LPUSH    BRPOP   時間複雜度都是O(1) BRPOP 是一個阻塞的列表彈出原語。 它是 RPOP 的阻塞版本，因為這個命令會在給定list無法彈出任何元素的時候阻塞連線。 該命令會按照給出的 key 順序檢視 list，並在找到的第一個非空 list 的尾部彈出一個元素。 當沒有元素可以被彈出時返回一個 nil 的多批量值，並且 timeout 過期。 當有元素彈出時會返回一個雙元素的多批量值，其中第一個元素是彈出元素的 key，第二個元素是 value。 起始用的RPOP命令，後臺monitor  redis，rpop命令從早刷到晚，雖然說redis機器沒出現什麼瓶頸，但是總感覺這樣頻繁的去刷redis不太理智，所以改為BRPOP，阻塞讀取，超時1秒，這樣減少客戶端對redis的請求 3、重發佇列優化 起初重發是pop完沒達到傳送條件，push回去，一旦出現大量重發資料，這樣的操作會對redis造成一定的影響，讀寫太頻繁，從業務上因為重發時間間隔都是秒為單位的，所以這裡每次取到資料後會休眠一秒，這裡犧牲點邏輯也是合理的，因為系統不會依靠重發去提高TPS和可靠性的，做好監控，重發佇列資料激增，必然是系統出現問題了；這樣一來重發對redis的IO請求也減少了 4、黑白名單 通過定時任務，每隔一段時間，將資料庫裡的資料重新整理到JVM記憶體裡，通過HASHSET儲存，畢竟黑白名單資料量不會很大，這樣減少對redis和mysql的訪問； 此方法可以遷移到別的場景