1、redis、kafka 消息中間鍵的作用、優點

解藕、異步、削峰

2、缺點

系統可用性降低。解決方案，try catch 捕捉異常，數據庫操作，進行兜底。搭建集群。

提高復雜度。例如：消息重復；消息丟失（主要集中在RabbitMQ）；消息順序（多線程搶資源。如何解決？kafka/RocketMQ:單個消費、一個主題下。）

一致性問題。A和B系統寫成功了，C系統沒有成功。分布式事務，RocketMQ 提供了。其他的用seta。redis Lua腳本來做原子性。

3、比對一下，常用的 MQ！??！RabbitMQ、Kafka、RocketMQ

性能角度（單臺）：Rabbit 1.2W、Kafka 100w、Rocket 10W
集群拓展支持：Rabbit 集群很弱（確保高可用 不能拓展性能）、Kafka 和 Rocket 天生分布式 動態支持拓展
功能：Rabbitmq 比較豐富（死信消息、延遲消息） 、Kafka 比較弱，RocketMQ 比較豐富（死信、延遲、消息回溯、消息的過濾）

Rabbitmq 基于主從模式做集群，RocketMQ、Kafka基于分布式做集群

4、為啥性能這么高？

 6、消息丟失場景，如何解決？

在生產的時候丟失、消費的時候丟失、宕機的時候沒有主從拷貝丟失

怎么丟失的？

生產者：網絡異常波動未能生產成功；遠程服務宕機未能接收成功（一句話概括：沒生產成功；生產成功了，服務端沒接收到。）

broker：數據沒有持久化，宕機，重啟數據丟失；未能及時同步消息

消費者：網絡異常波動，未能從服務端拉取成功消息；消費者宕機，消費者未能正常消費

生產的時候丟失：事務回滾機制，確保提交成功。但是是同步阻塞，效率性能低。RabbitMQ 的異步confirm機制，如果RabbitMQ接受到這個消息，寫入磁盤，給生產者返回ack。

宕機的時候，RabbitMQ數據丟失：開啟數據持久化。Kafka topic保證至少2個副本；每個領導者leader 必須有一個跟隨者follower跟自己保持聯系；消息寫入所有副本。

消費者數據丟失：RabbitMQ關閉自動ack，手動進行ack。Kafka 關閉自動offset，手動提交offset。

7、kafka 架構

可以設置多個topic，每個topic 下可以有多個分區， 每個分區是一個有序隊列，數據進到隊列，會分配一個有序的 offset。一臺kafka服務就是一個broker，一個broker 可以容納多個topic，

broker 接收到生產者的發送消息，并向生產者發送確認消息，消費者消費成功后，給broker發送確認消息，broker更新偏移量，以便下次從正確的位置進行消費。

ZooKeeper 協調kafka 組件之間的協作，例如主從晉升。后來引入Controller，承擔ZooKeeper的部分功能，簡化Kafka 集群的部署和管理。

8、kafka的工作流程

• producer 先從 zookeeper 的 "/brokers/.../state" 節點找到該 partition 的 leader
• producer 將消息發送給該 leader
• leader 將消息寫入本地 log
• followers 從 leader pull 消息
• 寫入本地 log 后向 leader 發送 ACK
• leader 收到所有 ISR 中的 replication 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset）并向 producer 發送 ACK

9、RabbitMQ 的設計架構

生產者生產消息，建立長鏈接，鏈接到broker 服務，交換機將消息發送給隊列，消費者拉取數據進行消費，消費成功后將數據刪除。

10、RabbitMQ 解決消息丟失的機制

生產者：comfirm消息確認機制。生產者生產消息后，exchange 將消息放入綁定的queue，返回ack給生產者。只要這個環節沒有完成，就返回nack。

RabbitMQ：數據持久化，存儲到磁盤。如果有需要就開啟數據持久化，應用場景不在意消息丟失，可以關閉，因為開啟會影響性能。

消費者：ACK機制。消費者成功消費，發送ack給RabbitMQ，RabbitMQ 將消費的消息進行刪除，如果消費者消費成功了但是因為異常沒有成功通知Rabbit，會出現重復消費，此時要把成功消費和通知刪除放在同一事務中。

11、RabbitMQ 怎么確保消息不被重復消費

生產者：接口冪等性

消費者：消費完成沒來得及發送ack給RabbitMQ

RabbitMQ：接收到ack，還沒來的及刪除，掛掉

解決方案

數據庫唯一約束。對于RabbitMQ，到達數據庫層面才能被限制住，性能效率低。

樂觀鎖，版本號。對于RabbitMQ，隊列中有相同版本號的有很多，只能成功消費一次，剩下的無法被消費。

redis 的setnx + 過期時間

12、Rabbit 如何解決消息堆積

出現的原因

生產的速度遠大于消費的速度；消費者出現異?；蛘邩I務復雜，導致消費時間過長；隊列容量太小。

解決

控制生產與消費的速度；負載均衡，提高消費能力；優化消費者代碼；控制消費者一次性取的數據；將無法處理的消息放在死信隊列，防止阻塞；大消息分割片段處理

13、redis 的過期策略、內存淘汰機制

有定期過期、惰性過期。定期過期，每隔一段時間，清理過期的數據。惰性過期，只有訪問的時候才判斷是否過期，不訪問即使過期也不刪除。

如果定期和惰性過期，都沒有刪除過期的數據，大量數據堆積，導致內存溢出。

內存淘汰機制，內存不足時，主動刪除一些數據，釋放空間。

淘汰機制的策略：選不常使用的；選快要過期的；從過期數據中，隨機刪除

14、什么是redis 的哨兵機制

搭建了redis的主從集群，master 掛了，需要從slever 中選一個當master。redis 哨兵的作用 就是自動恢復主從故障。

原理是，心跳機制，檢測集群ping ，是否掛了

15、redis 的數據持久化方案

RDB（redis data base）內存快照，全量備份。性能高，但是宕機，會丟失最近一次修改的的數據。觸發方式：手動觸發、自動觸發。手動觸發save, 阻塞redis進程，直到持久化數據完成；bgsave 主進程創建子進程，由子進程完成數據數據持久化，阻塞時間短。自動觸發，shutdown 命令將redis 服務關閉，會觸發自動備份。

redis默認開啟的是RDB持久化

AOF（append only file）增量日志。存的是命令，數據更加完整可靠，缺點文件大，redis重啟，數據恢復慢。

混合持久化：RDB+AOF

16、rabbitMQ 交換機的類型：定向、廣播、話題（類似于定向，區別可以支持通配符）

17、rabbitMQ中，如何保證生產者的可靠性

生產者重連

由于網絡波動，與MQ沒有一次性連接成功，配置重試機制。

生產者確認

生產者將消息投遞到交換機，交換機沒有成功路由到隊列，會返回錯誤信息，然后返回ack。這種情況一般是交換機與隊列沒有綁定正確。

生產者將消息投遞到交換機，交換機成功路由到隊列，給生產者發送ack

生產者將消息投遞到交換機，交換機成功路由到隊列，如果設置數據持久化，就持久化完成后，給生產者發送ack

18、rabbitMQ中，如何保證MQ的可靠性

MQ 宕機，內存中的消息會丟失；MQ內存空間有限，當消費者消費過慢，導致消息積壓，引發MQ阻塞。

數據持久化：配置消息持久化、交換機持久化、隊列持久化

什么是pageout？MQ消息過多達到內存閾值，會轉移到磁盤進行保存。大量的 Pageout 操作會使系統花費更多時間在數據的內存與磁盤交換上，從而降低了消息的處理速度和吞吐量，由于 Pageout 導致系統性能下降，生產者需要更長時間才能得到消息發送成功的確認響應，消費者也會延遲。沒有配置持久化，大部分數據會存在內存，達到閾值，會將數據轉移到磁盤，會出現pageout；

配置了數據持久化，數據一開始在磁盤與內存的數量差不多，然后逐漸內存變少，磁盤增多，減少pageout 的發生。

方法二：惰性隊列

3.6版本引入惰性隊列。大部分直接寫入磁盤，在頁面上的表現是，直接寫到paged out，不卡的原因做了磁盤IO優化。

19、rabbitMQ中，如何保證消費者的可靠性

消費者確認機制。消費者消費成功，給rabbitMQ發消息，rabbitMQ進行刪除，消費失敗，發送失敗消息，rabbitMQ會再次發送消息。

消費者失敗處理。消費失敗，rabbitMQ會重新發送，會陷入循環，配置重試機制，重試后還是失敗要么重新入列、要么刪除、要么放入新的隊列，交由人工處理。

業務冪等性。加消息唯一ID，將消費成功的ID存入數據庫，再次消費時，查看該消費是否在數據庫，如果在則為重復消費。

21、延遲消息的實現

死信交換機。綁定一個正常交換機，不綁定消費，設置時間，達到一定時間沒人消費，進入死信交換機，給死信交換機綁定消費者。實現延遲消費。

延遲消息插件。是對交換機做的改造，消息投遞給交換機，交換機設置時間，時間到了，再將消息投遞給隊列。適合時間短的延遲場景，不適合并發+延遲長的場景，cpu占用高。

取消超時訂單