一、消息隊列
（1）應用場景
1.1 解耦和
看這麼個場景。A 系統發送數據到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個數據呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰…
在這個場景中，A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產生一條比較關鍵的數據，很多系統都需要 A 系統將這個數據發送過來。A 系統要時時刻刻考慮 BCDE 四個系統如果掛了該咋辦？要不要重發，要不要把消息存起來？頭髮都白了啊！
如果使用 MQ，A 系統產生一條數據，發送到 MQ 裏面去，哪個系統需要數據自己去 MQ 裏面消費。如果新系統需要數據，直接從 MQ 裏消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗超時等情況。
總結：通過一個 MQ，Pub/Sub 發佈訂閱消息這麼一個模型，A 系統就跟其它系統徹底解耦了。
面試技巧：你需要去考慮一下你負責的系統中是否有類似的場景，就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很複雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦，也是可以的，你就需要去考慮在你的項目裏，是不是可以運用這個 MQ 去進行系統的解耦。在簡歷中體現出來這塊東西，用 MQ 作解耦。
1.2 異步處理
再來看一個場景，A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什麼東西，慢死了慢死了。用戶通過瀏覽器發起請求，等待個 1s，這幾乎是不可接受的。
一般互聯網類的企業，對於用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內完成，對用戶幾乎是無感知的。
如果使用 MQ，那麼 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms，對於用戶而言，其實感覺上就是點個按鈕，8ms 以後就直接返回了，爽！網站做得真好，真快！
1.3 流量削峯
每天 0:00 到 12:00，A 系統風平浪靜，每秒併發請求數量就 50 個。結果每次一到 12:00 ~ 13:00 ，每秒併發請求數量突然會暴增到 5k+ 條。但是系統是直接基於 MySQL 的，大量的請求湧入 MySQL，每秒鐘對 MySQL 執行約 5k 條 SQL。
一般的 MySQL，扛到每秒 2k 個請求就差不多了，如果每秒請求到 5k 的話，可能就直接把 MySQL 給打死了，導致系統崩潰，用戶也就沒法再使用系統了。
但是高峯期一過，到了下午的時候，就成了低峯期，可能也就 1w 的用戶同時在網站上操作，每秒中的請求數量可能也就 50 個請求，對整個系統幾乎沒有任何的壓力。
如果使用 MQ，每秒 5k 個請求寫入 MQ，A 系統每秒鐘最多處理 2k 個請求，因爲 MySQL 每秒鐘最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峯期的時候，A 系統也絕對不會掛掉。而 MQ 每秒鐘 5k 個請求進來，就 2k 個請求出去，結果就導致在中午高峯期（1 個小時），可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。
這個短暫的高峯期積壓是 ok 的，因爲高峯期過了之後，每秒鐘就 50 個請求進 MQ，但是 A 系統依然會按照每秒 2k 個請求的速度在處理。所以說，只要高峯期一過，A 系統就會快速將積壓的消息給解決掉。
（2）消息隊列缺點
2.1 系統可用性降低
系統引入的外部依賴越多，越容易掛掉。本來你就是 A 系統調用 BCD 三個系統的接口就好了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整，MQ 一掛，整套系統崩潰的，你不就完了？如何保證消息隊列的高可用
2.2 系統複雜度提高
硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的情況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
2.3 一致性問題
A 系統處理完了直接返回成功了，人都以爲你這個請求就成功了；但是問題是，要是 BCD 三個系統那裏，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。
所以消息隊列實際是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，做好之後，你會發現，媽呀，系統複雜度提升了一個數量級，也許是複雜了 10 倍。但是關鍵時刻，用，還是得用的。
（3）Kafka、ActiveMQ、RabbitMQ、RocketMQ有什麼優缺點？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日誌採集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 儘量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分佈式架構 | 非常高，分佈式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，併發能力很強，性能極好，延時很低 | MQ 功能較爲完善，還是分佈式的，擴展性好 | 功能較爲簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日誌採集被大規模使用 |
中小型公司，技術實力較爲一般，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。如果是大數據領域的實時計算、日誌採集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範。
二、緩存
（1）緩存的意義
1.1 爲什麼使用緩存？
高性能，高併發
1.2 高性能
假設這麼個場景，你有個操作，一個請求過來，吭哧吭哧你各種亂七八糟操作 mysql，半天查出來一個結果，耗時 600ms。但是這個結果可能接下來幾個小時都不會變了，或者變了也可以不用立即反饋給用戶。那麼此時咋辦？
緩存啊，折騰 600ms 查出來的結果，扔緩存裏，一個 key 對應一個 value，下次再有人查，別走 mysql 折騰 600ms 了，直接從緩存裏，通過一個 key 查出來一個 value，2ms 搞定。性能提升 300 倍。
就是說對於一些需要複雜操作耗時查出來的結果，且確定後面不怎麼變化，但是有很多讀請求，那麼直接將查詢出來的結果放在緩存中，後面直接讀緩存就好。
1.3 高併發
mysql 這麼重的數據庫，壓根兒設計不是讓你玩兒高併發的，雖然也可以玩兒，但是天然支持不好。mysql 單機支撐到 2000QPS 也開始容易報警了。
所以要是你有個系統，高峯期一秒鐘過來的請求有 1萬，那一個 mysql 單機絕對會死掉。你這個時候就只能上緩存，把很多數據放緩存，別放 mysql。緩存功能簡單，說白了就是 key-value 式操作，單機支撐的併發量輕鬆一秒幾萬十幾萬，支撐高併發 so easy。單機承載併發量是 mysql 單機的幾十倍。
緩存是走內存的，內存天生就是支撐高併發的
（2）用了緩存之後會有什麼不良後果？
2.1 緩存和數據庫雙寫不一致
2.2 緩存雪崩、穿透、擊穿
2.3 緩存併發競爭
（3）redis和memcached區別
3.1 redis 支持複雜的數據結構
redis 相比 memcached 來說，擁有更多的數據結構，能支持更豐富的數據操作。如果需要緩存能夠支持更復雜的結構和操作， redis 會是不錯的選擇。
3.2 redis 原生支持集羣模式
在 redis3.x 版本中，便能支持 cluster 模式，而 memcached 沒有原生的集羣模式，需要依靠客戶端來實現往集羣中分片寫入數據。
3.3 性能對比
由於 redis 只使用單核，而 memcached 可以使用多核，所以平均每一個核上 redis 在存儲小數據時比 memcached 性能更高。而在 100k 以上的數據中，memcached 性能要高於 redis。雖然 redis 最近也在存儲大數據的性能上進行優化，但是比起 memcached，還是稍有遜色。
3.4 redis 的線程模型
redis 內部使用文件事件處理器 file event handler，這個文件事件處理器是單線程的，所以 redis 才叫做單線程的模型。它採用 IO 多路複用機制同時監聽多個 socket，將產生事件的 socket 壓入內存隊列中，事件分派器根據 socket 上的事件類型來選擇對應的事件處理器進行處理。
文件事件處理器的結構包含 4 個部分：
多個 socket
IO 多路複用程序
文件事件分派器
事件處理器（連接應答處理器、命令請求處理器、命令回覆處理器）
多個 socket 可能會併發產生不同的操作，每個操作對應不同的文件事件，但是 IO 多路複用程序會監聽多個 socket，會將產生事件的 socket 放入隊列中排隊，事件分派器每次從隊列中取出一個 socket，根據 socket 的事件類型交給對應的事件處理器進行處理。
來看客戶端與 redis 的一次通信過程：
要明白，通信是通過 socket 來完成的，不懂的同學可以先去看一看 socket 網絡編程。
首先，redis 服務端進程初始化的時候，會將 server socket 的 AE_READABLE 事件與連接應答處理器關聯。
客戶端 socket01 向 redis 進程的 server socket 請求建立連接，此時 server socket 會產生一個 AE_READABLE 事件，IO 多路複用程序監聽到 server socket 產生的事件後，將該 socket 壓入隊列中。文件事件分派器從隊列中獲取 socket，交給連接應答處理器。連接應答處理器會創建一個能與客戶端通信的 socket01，並將該 socket01 的 AE_READABLE 事件與命令請求處理器關聯。
假設此時客戶端發送了一個 set key value 請求，此時 redis 中的 socket01 會產生 AE_READABLE 事件，IO 多路複用程序將 socket01 壓入隊列，此時事件分派器從隊列中獲取到 socket01 產生的 AE_READABLE 事件，由於前面 socket01 的 AE_READABLE 事件已經與命令請求處理器關聯，因此事件分派器將事件交給命令請求處理器來處理。命令請求處理器讀取 socket01 的 key value 並在自己內存中完成 key value 的設置。操作完成後，它會將 socket01 的 AE_WRITABLE 事件與命令回覆處理器關聯。
如果此時客戶端準備好接收返回結果了，那麼 redis 中的 socket01 會產生一個 AE_WRITABLE 事件，同樣壓入隊列中，事件分派器找到相關聯的命令回覆處理器，由命令回覆處理器對 socket01 輸入本次操作的一個結果，比如 ok，之後解除 socket01 的 AE_WRITABLE 事件與命令回覆處理器的關聯。
這樣便完成了一次通信。關於 Redis 的一次通信過程，推薦讀者閱讀《Redis 設計與實現——黃健宏》進行系統學習。
3.5 爲啥redis單線程模型也能效率這麼高？
- 純內存操作。
- 核心是基於非阻塞的 IO 多路複用機制。
- C 語言實現，一般來說，C 語言實現的程序“距離”操作系統更近，執行速度相對會更快。
- 單線程反而避免了多線程的頻繁上下文切換問題，預防了多線程可能產生的競爭問題。
（4）緩存數據類型以及應用場景
redis 有以下幾種數據類型：
- string
- hash
- list
- set
- sorted set
string
這是最簡單的類型，就是普通的 set 和 get，做簡單的 key value 緩存。
set college szu
hash
這個是類似 map 的一種結構，這個一般就是可以將結構化的數據，比如一個對象（前提是這個對象沒嵌套其他的對象）給緩存在 redis 裏，然後每次讀寫緩存的時候，可以就操作 hash 裏的某個字段。
hset person name bingo
hset person age 20
hset person id 1
hget person name
person = {
“name”: “bingo”,
“age”: 20,
“id”: 1
}
list
list 是有序列表，這個可以玩兒出很多花樣。
比如可以通過 list 存儲一些列表型的數據結構，類似粉絲列表、文章的評論列表之類的東西。
比如可以通過 lrange 命令，讀取某個閉區間內的元素，可以基於 list 實現分頁查詢，這個是很棒的一個功能，基於 redis 實現簡單的高性能分頁，可以做類似微博那種下拉不斷分頁的東西，性能高，就一頁一頁走。
0開始位置，-1結束位置，結束位置爲-1時，表示列表的最後一個位置，即查看所有。
lrange mylist 0 -1
比如可以搞個簡單的消息隊列，從 list 頭懟進去，從 list 尾巴那裏弄出來。
lpush mylist 1
lpush mylist 2
lpush mylist 3 4 5
rpop mylist
set
set 是無序集合，自動去重。
直接基於 set 將系統裏需要去重的數據扔進去，自動就給去重了，如果你需要對一些數據進行快速的全局去重，你當然也可以基於 jvm 內存裏的 HashSet 進行去重，但是如果你的某個系統部署在多臺機器上呢？得基於 redis 進行全局的 set 去重。
可以基於 set 玩兒交集、並集、差集的操作，比如交集吧，可以把兩個人的粉絲列表整一個交集，看看倆人的共同好友是誰？對吧。
把兩個大 V 的粉絲都放在兩個 set 中，對兩個 set 做交集。
#-------操作一個set-------
#添加元素
sadd mySet 1
#查看全部元素
smembers mySet
#判斷是否包含某個值
sismember mySet 3
#刪除某個/些元素
srem mySet 1
srem mySet 2 4
#查看元素個數
scard mySet
#隨機刪除一個元素
spop mySet
#-------操作多個set-------
#將一個set的元素移動到另外一個set
smove yourSet mySet 2
#求兩set的交集
sinter yourSet mySet
#求兩set的並集
sunion yourSet mySet
#求在yourSet中而不在mySet中的元素
sdiff yourSet mySet
sorted set
sorted set 是排序的 set，去重但可以排序，寫進去的時候給一個分數，自動根據分數排序。
zadd board 85 zhangsan
zadd board 72 lisi
zadd board 96 wangwu
zadd board 63 zhaoliu
#獲取排名前三的用戶（默認是升序，所以需要 rev 改爲降序）
zrevrange board 0 3
#獲取某用戶的排名
zrank board zhaoliu