1. 策略模式怎么控制策略的選取

答：
if else

1.1 追問：如果有100種策略呢？

答：
使用Map來做字段和策略的映射

1.2 追問：什么情況下初始化Map

答：

1. 在項目運行的時候去初始化Map,相當(dāng)于提前加載
2. 如果策略很多，在用戶使用的時候再去加載，相當(dāng)于懶加載，之后需要再次使用的時候去讀取初始化的策略就可以了

2. 什么是索引？什么時候用索引？

答：
索引在MySQL中也叫做“鍵”，它是一個特殊的文件，它保存著數(shù)據(jù)表里所有記錄的位置信息，更通俗的來說，數(shù)據(jù)庫索引好比是一本書前面的目錄，能加快數(shù)據(jù)庫的查詢速度。
當(dāng)數(shù)據(jù)庫中數(shù)據(jù)量很大時，查找數(shù)據(jù)會變得很慢，我們就可以通過索引來提高數(shù)據(jù)庫的查詢效率

2.1 追問：怎么判斷系統(tǒng)什么時候用量比較少

答：
看日志、看負載、看CPU、看接口調(diào)用量

2.2 追問：如何實時的查看日志

答：
tail -f

3. 怎么實現(xiàn)發(fā)送短信功能

答：
第三方運營商服務(wù)，引入對應(yīng)的包，填寫對應(yīng)的參數(shù)（一般都有ak,sk），更具示例代碼編寫自己的邏輯就可以

3.1 追問：怎么防止短信被刷

答：
驗證碼+限制短信發(fā)送頻率

3.2 追問：怎么實現(xiàn)限制短信發(fā)送頻率

答：redis

4. 什么是AOP？怎么在項目中運用AOP

4.1 追問：Spring AOP是怎么實現(xiàn)的

4.2 追問：Spring AOP是基于哪一種動態(tài)代理

詳情見文章：Spring AOP（概念、實戰(zhàn)、原理）

5. MySQL讀寫分離怎么實現(xiàn)

答：
定義主服務(wù)器和從服務(wù)器，主服務(wù)器負責(zé)寫數(shù)據(jù)，從服務(wù)器只負責(zé)讀數(shù)據(jù)

5.1 追問：主從節(jié)點是如何同步的

答：

5.2 追問：有幾種同步模式，分別介紹一下

有兩種同步模式
異步同步模式
異步同步模式是MySQL默認的同步策略模式，客戶端向服務(wù)端發(fā)送請求后，master處理完之后，直接返回客戶端結(jié)果，接著在將對應(yīng)的log信息發(fā)送給slave節(jié)點
半同步模式

1. master處理完自身操作，將對應(yīng)的binary log 發(fā)送從服務(wù)器，從服務(wù)器通過io thread線程寫入到relay log中，然后將結(jié)果返回給master，master在收到salve的響應(yīng)之后返回給客戶端
2. 半同步模式是基于異步復(fù)制的基礎(chǔ)上進行的，無非是半同步模式需要安裝異步插件完成

6. 介紹一下緩存雪崩

原因：同一時間段key大量過期
解決：
4. 設(shè)置不同過期時間（一個固定值，一個隨機值）
5. 多級緩存
6. 降級處理（最簡單的拋出異常,也可以返回一些簡化的內(nèi)容或者靜態(tài)頁面）

7. redis緩存和數(shù)據(jù)庫不一致的問題

采用redisson實現(xiàn)的讀寫鎖，在讀的時候添加共享鎖，可以保證讀讀不互斥，讀寫互斥。當(dāng)我們更新數(shù)據(jù)的時候，添加排他鎖，它是讀讀，讀寫都互斥，這樣就能保證在寫數(shù)據(jù)的同時是不會讓其他線程讀數(shù)據(jù)的，避免了臟數(shù)據(jù)。這里面需要注意的是讀方法和寫方法上需要使用同一鎖才行。
注意：這種情況只有必須保證強一致性的時候才會使用

開發(fā)中大部分是允許短暫的不一致的，這個時候采用異步的方案
● 使用MQ中間件，更新數(shù)據(jù)之后，通知緩存刪除
● 利用canal中間件，不需要修改業(yè)務(wù)代碼，偽裝為MySQL的一個從節(jié)點，canal通過讀取binlog數(shù)據(jù)更新緩存

7.1 追問：為什么不適用延遲雙刪

延遲雙刪，如果是寫操作，我們先把緩存中的數(shù)據(jù)刪除，然后更新數(shù)據(jù)庫，最后再延時刪除緩存中的數(shù)據(jù)，其中這個延時多久不太好確定，在演示的過程中可能會出現(xiàn)臟數(shù)據(jù)，并不能保證強一致性，所以沒有采用

8. RabbitMQ重復(fù)消費問題

7. 給每一個消息攜帶一個全局唯一id
   ● 消費者監(jiān)聽到消息后獲取id，先去查詢這個id是否存在
   ● 如果不存在，則正常消費消息，并將消息的id存入數(shù)據(jù)庫或者redis中
   ● 如果存在則丟棄此消息
8. 分布式鎖
   ● 以唯一的消息id為鍵加鎖，消費過后就上鎖，下次消息再過來就判斷

8.1 追問：如何保證消息不丟失

第一個是開啟生產(chǎn)者確認機制，確保生產(chǎn)者的消息能到達隊列，如果報錯可 以先記錄到日志中，再去修復(fù)數(shù)據(jù)
詳細的：
RabbitMQ提供了publisher confirm機制來避免消息發(fā)送到MQ過程中丟失。消息發(fā)送到MQ以后，會返回一個結(jié)果給發(fā)送者，表示消息是否處理成功
如果到達消費者，則會返回publish-confirm ack，如果到交換機失敗，則返回publish-confirm nack，如果到隊列失敗了，則返回publish-return ack

第二個是開啟持久化功能，確保消息未消費前在隊列中不會丟失，其中的交換機、隊列、和消息都要做持久化
詳細的：

第三個是開啟消費者確認機制
1. auto
自動ACK。Spring AMQP提供了一種自動的消息確認機制。它利用AOP（面向切面編程）對消息處理邏輯做了環(huán)繞增強。當(dāng)業(yè)務(wù)正常執(zhí)行時，Spring AMQP會自動返回ACK。當(dāng)業(yè)務(wù)出現(xiàn)異常時，根據(jù)異常判斷返回不同結(jié)果：業(yè)務(wù)異常，自動返回NACK；消息處理或校驗異常，自動返回REJECT。

2. manual
手動ACK。消費者接收到消息后需要手動發(fā)送確認給發(fā)送者，發(fā)送者才會繼續(xù)發(fā)送下一條消息。在這種模式下，如果消費者處理消息失敗，可以手動發(fā)送NACK給發(fā)送者，告訴發(fā)送者這條消息處理失敗，以便發(fā)送者重新發(fā)送消息。這種模式可以保證消息的可靠性，但需要消費者手動處理確認和NACK。
Channel.basicAck()方法

channel.basicAck(deliveryTag,true);

肯定確認，消費成功，可以刪除
Channel.basicreject()方法

channel.basicReject(deliveryTag, true);

拒絕deliveryTag對應(yīng)的消息，第二個參數(shù)是否requeue，true則重新入隊列，否則丟棄或者進入死信隊列。
該方法reject后，該消費者還是會消費到該條被reject的消息。
Channel.basicnack()方法

channel.basicNack(deliveryTag, false, true);

為不確認deliveryTag對應(yīng)的消息，第二個參數(shù)是否應(yīng)用于多消息，第三個參數(shù)是否requeue
與basic.reject區(qū)別就是同時支持多個消息，可以nack該消費者先前接收未ack的所有消息。nack后的消息也會被自己消費到。
Channel.basicrecover()方法

channel.basicRecover(true);

是否恢復(fù)消息到隊列，參數(shù)是是否requeue，true則重新入隊列，并且盡可能的將之前recover的消息投遞給其他消費者消費，而不是自己再次消費。false則消息會重新被投遞給自己。

8.2 追問：多個消費者消費同一個消息如何實現(xiàn)

發(fā)布訂閱模式

8.3 追問：RabbitMQ有哪幾種工作模型

一、簡單模式
簡單模式是最基本的消息隊列模式，適用于一個生產(chǎn)者和一個消費者的場景。生產(chǎn)者發(fā)送消息到隊列，消費者從隊列中獲取消息進行處理。這種模式的優(yōu)點是簡單易用，但缺點是消息只能被一個消費者消費，且沒有消息的確認機制，可能會出現(xiàn)消息丟失的情況。
二、工作隊列模式
工作隊列模式適用于多個消費者共同處理一個任務(wù)的情況。生產(chǎn)者將任務(wù)發(fā)布到隊列中，多個消費者監(jiān)聽同一個隊列，通過競爭獲取任務(wù)進行處理。這種模式的優(yōu)點是能夠充分利用多個處理器的計算能力，提高系統(tǒng)的吞吐量。但缺點是可能會導(dǎo)致多個消費者同時處理同一個任務(wù)，造成資源的浪費。
三、發(fā)布訂閱模式
發(fā)布訂閱模式是一種廣播模式，適用于一對多消息傳遞的場景。生產(chǎn)者將消息發(fā)布到交換機，交換機將消息轉(zhuǎn)發(fā)給所有綁定到該交換機的隊列，消費者從隊列中獲取消息進行處理。這種模式的優(yōu)點是能夠?qū)崿F(xiàn)一對多的消息傳遞，提高系統(tǒng)的擴展性。但缺點是可能會導(dǎo)致消息的重復(fù)傳遞和消費者的重復(fù)消費。
四、路由模式
路由模式是一種更靈活的消息傳遞方式，適用于多個業(yè)務(wù)系統(tǒng)的集成。生產(chǎn)者將消息發(fā)送到交換機，交換機根據(jù)routing key將消息路由到一個或多個隊列中，消費者從隊列中獲取消息進行處理。這種模式的優(yōu)點是能夠根據(jù)業(yè)務(wù)需求靈活地路由消息，提高系統(tǒng)的可擴展性和靈活性。但缺點是需要合理地設(shè)計routing key以避免消息的丟失或重復(fù)傳遞。
五、通配符模式
通配符模式是一種匹配規(guī)則的消息傳遞方式，適用于多級菜單的場景。生產(chǎn)者將消息發(fā)送到交換機，交換機根據(jù)通配符匹配規(guī)則將消息路由到對應(yīng)的隊列中，消費者從隊列中獲取消息進行處理。這種模式的優(yōu)點是能夠根據(jù)規(guī)則匹配到多個隊列，實現(xiàn)多級菜單的消息傳遞。但缺點是需要合理地設(shè)計通配符規(guī)則以避免消息的錯漏或重復(fù)傳遞。
六、主題模式
主題模式是一種基于關(guān)鍵字訂閱的消息傳遞方式，適用于多級分類的場景。生產(chǎn)者將消息發(fā)布到主題交換機，交換機將消息轉(zhuǎn)發(fā)給所有綁定到該主題交換機的隊列，消費者從隊列中獲取消息進行處理。這種模式的優(yōu)點是能夠根據(jù)關(guān)鍵字訂閱消息，實現(xiàn)多級分類的消息傳遞。但缺點是需要合理地設(shè)計主題和關(guān)鍵字以避免消息的錯漏或重復(fù)傳遞。

8.4 追問：多個消費者，如何保證只有一個消費者去消費一個消息（生產(chǎn)者消息來了是直接給所有的消費者的）

默認情況下，RabbitMq收到消息后，就向消費者全部推送。但是如果rabbitmq隊列里消息過多，且消息的數(shù)量超過了消費者處理能力, 就會導(dǎo)致客戶端超負荷崩潰。此時我們可以通過 prefetchCount 限制每個消費者在收到下一個確認回執(zhí)前一次可以最大接受多少條消息。即如果設(shè)置prefetchCount =1，RabbitMQ向這個消費者發(fā)送一個消息后，再這個消息的消費者對這個消息進行ack之前，RabbitMQ不會向這個消費者發(fā)送新的消息

 // 每個客戶端每次最后獲取N個消息
channel.basicQos(1);