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

答：
if else

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

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

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

答：

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

2. 什么是索引？什么時(shí)候用索引？

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

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

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

2.2 追問：如何實(shí)時(shí)的查看日志

答：
tail -f

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

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

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

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

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

答：redis

4. 什么是AOP？怎么在項(xiàng)目中運(yùn)用AOP

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

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

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

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

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

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

答：

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

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

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

6. 介紹一下緩存雪崩

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

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

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

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

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

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

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

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

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

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

第二個(gè)是開啟持久化功能，確保消息未消費(fèi)前在隊(duì)列中不會(huì)丟失，其中的交換機(jī)、隊(duì)列、和消息都要做持久化
詳細(xì)的：

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

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

channel.basicAck(deliveryTag,true);

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

channel.basicReject(deliveryTag, true);

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

channel.basicNack(deliveryTag, false, true);

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

channel.basicRecover(true);

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

8.2 追問：多個(gè)消費(fèi)者消費(fèi)同一個(gè)消息如何實(shí)現(xiàn)

發(fā)布訂閱模式

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

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

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

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

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