什么是自旋鎖和互斥鎖？

由于CLH鎖是一種自旋鎖，那么我們先來看看自旋鎖是什么？

自旋鎖說白了也是一種互斥鎖，只不過沒有搶到鎖的線程會(huì)一直自旋等待鎖的釋放，處于busy-waiting的狀態(tài)，此時(shí)等待鎖的線程不會(huì)進(jìn)入休眠狀態(tài)，而是一直忙等待浪費(fèi)CPU周期。因此自旋鎖適用于鎖占用時(shí)間短的場(chǎng)合。

這里談到了自旋鎖，那么我們也順便說下互斥鎖。這里的互斥鎖說的是傳統(tǒng)意義的互斥鎖，就是多個(gè)線程并發(fā)競(jìng)爭(zhēng)鎖的時(shí)候，沒有搶到鎖的線程會(huì)進(jìn)入休眠狀態(tài)即sleep-waiting，當(dāng)鎖被釋放的時(shí)候，處于休眠狀態(tài)的一個(gè)線程會(huì)再次獲取到鎖。缺點(diǎn)就是這一些列過程需要線程切換，需要執(zhí)行很多CPU指令，同樣需要時(shí)間。如果CPU執(zhí)行線程切換的時(shí)間比鎖占用的時(shí)間還長(zhǎng)，那么可能還不如使用自旋鎖。因此互斥鎖適用于鎖占用時(shí)間長(zhǎng)的場(chǎng)合。

1、為什么要使用消息隊(duì)列?

分析:一個(gè)用消息隊(duì)列的人，不知道為啥用，有點(diǎn)尷尬。沒有復(fù)習(xí)這點(diǎn)，很容易被問蒙，然后就開始胡扯了。

回答:這個(gè)問題,咱只答三個(gè)最主要的應(yīng)用場(chǎng)景(不可否認(rèn)還有其他的，但是只答三個(gè)主要的),即以下六個(gè)字:解耦、異步、削峰

(1)解耦

傳統(tǒng)模式:

傳統(tǒng)模式的缺點(diǎn)：

• 系統(tǒng)間耦合性太強(qiáng)，如上圖所示，系統(tǒng)A在代碼中直接調(diào)用系統(tǒng)B和系統(tǒng)C的代碼，如果將來D系統(tǒng)接入，系統(tǒng)A還需要修改代碼，過于麻煩！

中間件模式:

中間件模式的的優(yōu)點(diǎn)：

• 將消息寫入消息隊(duì)列，需要消息的系統(tǒng)自己從消息隊(duì)列中訂閱，從而系統(tǒng)A不需要做任何修改。

(2)異步

傳統(tǒng)模式:

傳統(tǒng)模式的缺點(diǎn)：

• 一些非必要的業(yè)務(wù)邏輯以同步的方式運(yùn)行，太耗費(fèi)時(shí)間。

中間件模式:

中間件模式的的優(yōu)點(diǎn)：

• 將消息寫入消息隊(duì)列，非必要的業(yè)務(wù)邏輯以異步的方式運(yùn)行，加快響應(yīng)速度

(3)削峰

傳統(tǒng)模式

傳統(tǒng)模式的缺點(diǎn)：

• 并發(fā)量大的時(shí)候，所有的請(qǐng)求直接懟到數(shù)據(jù)庫，造成數(shù)據(jù)庫連接異常

中間件模式:

中間件模式的的優(yōu)點(diǎn)：

• 系統(tǒng)A慢慢的按照數(shù)據(jù)庫能處理的并發(fā)量，從消息隊(duì)列中慢慢拉取消息。在生產(chǎn)中，這個(gè)短暫的高峰期積壓是允許的。

2、使用了消息隊(duì)列會(huì)有什么缺點(diǎn)?

分析:一個(gè)使用了MQ的項(xiàng)目，如果連這個(gè)問題都沒有考慮過，就把MQ引進(jìn)去了，那就給自己的項(xiàng)目帶來了風(fēng)險(xiǎn)。

我們引入一個(gè)技術(shù)，要對(duì)這個(gè)技術(shù)的弊端有充分的認(rèn)識(shí)，才能做好預(yù)防。要記住，不要給公司挖坑！

回答:回答也很容易，從以下兩個(gè)個(gè)角度來答

• 系統(tǒng)可用性降低:

  你想啊，本來其他系統(tǒng)只要運(yùn)行好好的，那你的系統(tǒng)就是正常的。

  現(xiàn)在你非要加個(gè)消息隊(duì)列進(jìn)去，那消息隊(duì)列掛了，你的系統(tǒng)不是呵呵了。因此，系統(tǒng)可用性降低

• 系統(tǒng)復(fù)雜性增加:

  要多考慮很多方面的問題，比如一致性問題、如何保證消息不被重復(fù)消費(fèi)，如何保證保證消息可靠傳輸。

  因此，需要考慮的東西更多，系統(tǒng)復(fù)雜性增大。

但是，我們?cè)撚眠€是要用的。

3、消息隊(duì)列如何選型?

先說一下，博主只會(huì)ActiveMQ,RabbitMQ,RocketMQ,Kafka，對(duì)什么ZeroMQ等其他MQ沒啥理解，因此只能基于這四種MQ給出回答。

分析:既然在項(xiàng)目中用了MQ，肯定事先要對(duì)業(yè)界流行的MQ進(jìn)行調(diào)研，如果連每種MQ的優(yōu)缺點(diǎn)都沒了解清楚，就拍腦袋依據(jù)喜好，用了某種MQ，還是給項(xiàng)目挖坑。

如果面試官問:"你為什么用這種MQ？。"你直接回答"領(lǐng)導(dǎo)決定的。"這種回答就很LOW了。

還是那句話，不要給公司挖坑。

我們可以看出，RabbitMQ版本發(fā)布比ActiveMq頻繁很多。至于RocketMQ和kafka就不帶大家看了，總之也比ActiveMQ活躍的多。詳情，可自行查閱。

再來一個(gè)性能對(duì)比表

綜合上面的材料得出以下兩點(diǎn):

(1)中小型軟件公司，建議選RabbitMQ.

一方面，erlang語言天生具備高并發(fā)的特性，而且他的管理界面用起來十分方便。

正所謂，成也蕭何，敗也蕭何！他的弊端也在這里，雖然RabbitMQ是開源的，然而國(guó)內(nèi)有幾個(gè)能定制化開發(fā)erlang的程序員呢？

所幸，RabbitMQ的社區(qū)十分活躍，可以解決開發(fā)過程中遇到的bug，這點(diǎn)對(duì)于中小型公司來說十分重要。

不考慮rocketmq和kafka的原因是，一方面中小型軟件公司不如互聯(lián)網(wǎng)公司，數(shù)據(jù)量沒那么大，選消息中間件，應(yīng)首選功能比較完備的，所以kafka排除。

不考慮rocketmq的原因是，rocketmq是阿里出品，如果阿里放棄維護(hù)rocketmq，中小型公司一般抽不出人來進(jìn)行rocketmq的定制化開發(fā)，因此不推薦。

(2)大型軟件公司，根據(jù)具體使用在rocketMq和kafka之間二選一

一方面，大型軟件公司，具備足夠的資金搭建分布式環(huán)境，也具備足夠大的數(shù)據(jù)量。

針對(duì)rocketMQ,大型軟件公司也可以抽出人手對(duì)rocketMQ進(jìn)行定制化開發(fā)，畢竟國(guó)內(nèi)有能力改JAVA源碼的人，還是相當(dāng)多的。

至于kafka，根據(jù)業(yè)務(wù)場(chǎng)景選擇，如果有日志采集功能，肯定是首選kafka了。具體該選哪個(gè)，看使用場(chǎng)景。

4、如何保證消息隊(duì)列是高可用的？

分析:在第二點(diǎn)說過了，引入消息隊(duì)列后，系統(tǒng)的可用性下降。在生產(chǎn)中，沒人使用單機(jī)模式的消息隊(duì)列。

因此，作為一個(gè)合格的程序員，應(yīng)該對(duì)消息隊(duì)列的高可用有很深刻的了解。

如果面試的時(shí)候，面試官問，你們的消息中間件如何保證高可用的？

如果你的回答只是表明自己只會(huì)訂閱和發(fā)布消息，面試官就會(huì)懷疑你是不是只是自己搭著玩，壓根沒在生產(chǎn)用過。

因此，請(qǐng)做一個(gè)愛思考，會(huì)思考，懂思考的程序員。

回答:這問題，其實(shí)要對(duì)消息隊(duì)列的集群模式要有深刻了解，才好回答。

以rcoketMQ為例，他的集群就有多master 模式、多master多slave異步復(fù)制模式、多 master多slave同步雙寫模式。

多master多slave模式部署架構(gòu)圖(網(wǎng)上找的,偷個(gè)懶，懶得畫):

其實(shí)博主第一眼看到這個(gè)圖，就覺得和kafka好像，只是NameServer集群，在kafka中是用zookeeper代替，都是用來保存和發(fā)現(xiàn)master和slave用的。

通信過程如下:

Producer 與 NameServer集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長(zhǎng)連接，定期從 NameServer 獲取 Topic 路由信息，并向提供 Topic 服務(wù)的 Broker Master 建立長(zhǎng)連接，且定時(shí)向 Broker 發(fā)送心跳。

Producer 只能將消息發(fā)送到 Broker master，但是 Consumer 則不一樣，它同時(shí)和提供 Topic 服務(wù)的 Master 和 Slave建立長(zhǎng)連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。

那么kafka呢,為了對(duì)比說明直接上kafka的拓補(bǔ)架構(gòu)圖(也是找的，懶得畫)

如上圖所示，一個(gè)典型的Kafka集群中包含若干Producer（可以是web前端產(chǎn)生的Page View，或者是服務(wù)器日志，系統(tǒng)CPU、Memory等），若干broker（Kafka支持水平擴(kuò)展，一般broker數(shù)量越多，集群吞吐率越高），若干Consumer Group，以及一個(gè)Zookeeper集群。

Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance。

Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費(fèi)消息。

至于rabbitMQ,也有普通集群和鏡像集群模式，自行去了解，比較簡(jiǎn)單，兩小時(shí)即懂。

要求，在回答高可用的問題時(shí)，應(yīng)該能邏輯清晰的畫出自己的MQ集群架構(gòu)或清晰的敘述出來。

5、如何保證消息不被重復(fù)消費(fèi)？

分析:這個(gè)問題其實(shí)換一種問法就是，如何保證消息隊(duì)列的冪等性?

這個(gè)問題可以認(rèn)為是消息隊(duì)列領(lǐng)域的基本問題。換句話來說，是在考察你的設(shè)計(jì)能力，這個(gè)問題的回答可以根據(jù)具體的業(yè)務(wù)場(chǎng)景來答，沒有固定的答案。

回答:先來說一下為什么會(huì)造成重復(fù)消費(fèi)?

其實(shí)無論是那種消息隊(duì)列，造成重復(fù)消費(fèi)原因其實(shí)都是類似的。

正常情況下，消費(fèi)者在消費(fèi)消息時(shí)候，消費(fèi)完畢后，會(huì)發(fā)送一個(gè)確認(rèn)信息給消息隊(duì)列，消息隊(duì)列就知道該消息被消費(fèi)了，就會(huì)將該消息從消息隊(duì)列中刪除。只是不同的消息隊(duì)列發(fā)送的確認(rèn)信息形式不同

例如RabbitMQ是發(fā)送一個(gè)ACK確認(rèn)消息，RocketMQ是返回一個(gè)CONSUME_SUCCESS成功標(biāo)志，kafka實(shí)際上有個(gè)offset的概念

簡(jiǎn)單說一下(如果還不懂，出門找一個(gè)kafka入門到精通教程),就是每一個(gè)消息都有一個(gè)offset，kafka消費(fèi)過消息后，需要提交offset，讓消息隊(duì)列知道自己已經(jīng)消費(fèi)過了。

那造成重復(fù)消費(fèi)的原因?

就是因?yàn)榫W(wǎng)絡(luò)傳輸?shù)鹊裙收?#xff0c;確認(rèn)信息沒有傳送到消息隊(duì)列，導(dǎo)致消息隊(duì)列不知道自己已經(jīng)消費(fèi)過該消息了，再次將該消息分發(fā)給其他的消費(fèi)者。

如何解決?這個(gè)問題針對(duì)業(yè)務(wù)場(chǎng)景來答分以下幾點(diǎn)

(1)比如，你拿到這個(gè)消息做數(shù)據(jù)庫的insert操作。

那就容易了，給這個(gè)消息做一個(gè)唯一主鍵，那么就算出現(xiàn)重復(fù)消費(fèi)的情況，就會(huì)導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫出現(xiàn)臟數(shù)據(jù)。

(2)再比如，你拿到這個(gè)消息做redis的set的操作

那就容易了，不用解決。因?yàn)槟銦o論set幾次結(jié)果都是一樣的，set操作本來就算冪等操作。

(3)如果上面兩種情況還不行，上大招。

準(zhǔn)備一個(gè)第三方介質(zhì),來做消費(fèi)記錄。以redis為例，給消息分配一個(gè)全局id，只要消費(fèi)過該消息，將以K-V形式寫入redis。那消費(fèi)者開始消費(fèi)前，先去redis中查詢有沒消費(fèi)記錄即可。

6、如何保證消費(fèi)的可靠性傳輸?

分析:我們?cè)谑褂孟㈥?duì)列的過程中，應(yīng)該做到消息不能多消費(fèi)，也不能少消費(fèi)。如果無法做到可靠性傳輸，可能給公司帶來千萬級(jí)別的財(cái)產(chǎn)損失。

同樣的，如果可靠性傳輸在使用過程中，沒有考慮到，這不是給公司挖坑么，你可以拍拍屁股走了，公司損失的錢，誰承擔(dān)。

還是那句話，認(rèn)真對(duì)待每一個(gè)項(xiàng)目，不要給公司挖坑

回答:其實(shí)這個(gè)可靠性傳輸，每種MQ都要從三個(gè)角度來分析:生產(chǎn)者弄丟數(shù)據(jù)、消息隊(duì)列弄丟數(shù)據(jù)、消費(fèi)者弄丟數(shù)據(jù)

RabbitMQ

(1)生產(chǎn)者丟數(shù)據(jù)

從生產(chǎn)者弄丟數(shù)據(jù)這個(gè)角度來看，RabbitMQ提供transaction和confirm模式來確保生產(chǎn)者不丟消息。

transaction機(jī)制就是說，發(fā)送消息前，開啟事物(channel.txSelect())，然后發(fā)送消息，如果發(fā)送過程中出現(xiàn)什么異常，事物就會(huì)回滾(channel.txRollback())，如果發(fā)送成功則提交事物(channel.txCommit())。

然而缺點(diǎn)就是吞吐量下降了。因此，按照博主的經(jīng)驗(yàn)，生產(chǎn)上用confirm模式的居多。

一旦channel進(jìn)入confirm模式，所有在該信道上面發(fā)布的消息都將會(huì)被指派一個(gè)唯一的ID(從1開始)

一旦消息被投遞到所有匹配的隊(duì)列之后，rabbitMQ就會(huì)發(fā)送一個(gè)Ack給生產(chǎn)者(包含消息的唯一ID)

這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了.如果rabiitMQ沒能處理該消息，則會(huì)發(fā)送一個(gè)Nack消息給你，你可以進(jìn)行重試操作。

處理Ack和Nack的代碼如下所示（說好不上代碼的，偷偷上了）:

channel.addConfirmListener(new ConfirmListener() {@Overridepublic void handleNack(long deliveryTag, boolean multiple) throws IOException {System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);}@Overridepublic void handleAck(long deliveryTag, boolean multiple) throws IOException {System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);} });

(2)消息隊(duì)列丟數(shù)據(jù)

處理消息隊(duì)列丟數(shù)據(jù)的情況，一般是開啟持久化磁盤的配置。

這個(gè)持久化配置可以和confirm機(jī)制配合使用，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個(gè)Ack信號(hào)。

這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那么生產(chǎn)者收不到Ack信號(hào)，生產(chǎn)者會(huì)自動(dòng)重發(fā)。

那么如何持久化呢，這里順便說一下吧，其實(shí)也很容易，就下面兩步

1、將queue的持久化標(biāo)識(shí)durable設(shè)置為true,則代表是一個(gè)持久的隊(duì)列

2、發(fā)送消息的時(shí)候?qū)eliveryMode=2

這樣設(shè)置以后，rabbitMQ就算掛了，重啟后也能恢復(fù)數(shù)據(jù)

(3)消費(fèi)者丟數(shù)據(jù)

消費(fèi)者丟數(shù)據(jù)一般是因?yàn)椴捎昧俗詣?dòng)確認(rèn)消息模式。

這種模式下，消費(fèi)者會(huì)自動(dòng)確認(rèn)收到信息。這時(shí)rahbitMQ會(huì)立即將消息刪除，這種情況下如果消費(fèi)者出現(xiàn)異常而沒能處理該消息，就會(huì)丟失該消息。

至于解決方案，采用手動(dòng)確認(rèn)消息即可。

kafka

Producer在發(fā)布消息到某個(gè)Partition時(shí)，先通過ZooKeeper找到該P(yáng)artition的Leader

然后無論該Topic的Replication Factor為多少（也即該P(yáng)artition有多少個(gè)Replica），Producer只將該消息發(fā)送到該P(yáng)artition的Leader。

Leader會(huì)將該消息寫入其本地Log。每個(gè)Follower都從Leader中pull數(shù)據(jù)。
針對(duì)上述情況，得出如下分析

(1)生產(chǎn)者丟數(shù)據(jù)

在kafka生產(chǎn)中，基本都有一個(gè)leader和多個(gè)follwer。follwer會(huì)去同步leader的信息。

因此，為了避免生產(chǎn)者丟數(shù)據(jù)，做如下兩點(diǎn)配置

第一個(gè)配置要在producer端設(shè)置acks=all。這個(gè)配置保證了，follwer同步完成后，才認(rèn)為消息發(fā)送成功。

在producer端設(shè)置retries=MAX，一旦寫入失敗，這無限重試

(2)消息隊(duì)列丟數(shù)據(jù)

針對(duì)消息隊(duì)列丟數(shù)據(jù)的情況，無外乎就是，數(shù)據(jù)還沒同步，leader就掛了，這時(shí)zookpeer會(huì)將其他的follwer切換為leader,那數(shù)據(jù)就丟失了。

針對(duì)這種情況，應(yīng)該做兩個(gè)配置。

replication.factor參數(shù)，這個(gè)值必須大于1，即要求每個(gè)partition必須有至少2個(gè)副本

min.insync.replicas參數(shù)，這個(gè)值必須大于1，這個(gè)是要求一個(gè)leader至少感知到有至少一個(gè)follower還跟自己保持聯(lián)系

這兩個(gè)配置加上上面生產(chǎn)者的配置聯(lián)合起來用，基本可確保kafka不丟數(shù)據(jù)

(3)消費(fèi)者丟數(shù)據(jù)

這種情況一般是自動(dòng)提交了offset，然后你處理程序過程中掛了。kafka以為你處理好了。

再?gòu)?qiáng)調(diào)一次offset是干嘛的

offset：指的是kafka的topic中的每個(gè)消費(fèi)組消費(fèi)的下標(biāo)。

簡(jiǎn)單的來說就是一條消息對(duì)應(yīng)一個(gè)offset下標(biāo)，每次消費(fèi)數(shù)據(jù)的時(shí)候如果提交offset，那么下次消費(fèi)就會(huì)從提交的offset加一那里開始消費(fèi)。

比如一個(gè)topic中有100條數(shù)據(jù)，我消費(fèi)了50條并且提交了，那么此時(shí)的kafka服務(wù)端記錄提交的offset就是49(offset從0開始)，那么下次消費(fèi)的時(shí)候offset就從50開始消費(fèi)。

解決方案也很簡(jiǎn)單，改成手動(dòng)提交即可。

ActiveMQ和RocketMQ

大家自行查閱吧

7、如何保證消息的順序性？

分析:其實(shí)并非所有的公司都有這種業(yè)務(wù)需求，但是還是對(duì)這個(gè)問題要有所復(fù)習(xí)。

回答:針對(duì)這個(gè)問題，通過某種算法，將需要保持先后順序的消息放到同一個(gè)消息隊(duì)列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一個(gè)消費(fèi)者去消費(fèi)該隊(duì)列。

有的人會(huì)問:那如果為了吞吐量，有多個(gè)消費(fèi)者去消費(fèi)怎么辦？

這個(gè)問題，沒有固定回答的套路。比如我們有一個(gè)微博的操作，發(fā)微博、寫評(píng)論、刪除微博，這三個(gè)異步操作。如果是這樣一個(gè)業(yè)務(wù)場(chǎng)景，那只要重試就行。

比如你一個(gè)消費(fèi)者先執(zhí)行了寫評(píng)論的操作，但是這時(shí)候，微博都還沒發(fā)，寫評(píng)論一定是失敗的，等一段時(shí)間。等另一個(gè)消費(fèi)者，先執(zhí)行寫評(píng)論的操作后，再執(zhí)行，就可以成功。

總之，針對(duì)這個(gè)問題，我的觀點(diǎn)是保證入隊(duì)有序就行，出隊(duì)以后的順序交給消費(fèi)者自己去保證，沒有固定套路。

最后

小編利用空余時(shí)間整理了一份《MySQL性能調(diào)優(yōu)手冊(cè)》，初衷也很簡(jiǎn)單，就是希望能夠幫助到大家，減輕大家的負(fù)擔(dān)和節(jié)省時(shí)間。

關(guān)于這個(gè)，給大家看一份學(xué)習(xí)大綱（PDF）文件，每一個(gè)分支里面會(huì)有詳細(xì)的介紹。

這里都是以圖片形式展示介紹，如要下載原文件以及更多的性能調(diào)優(yōu)筆記（MySQL+Tomcat+JVM）可以直接【點(diǎn)擊 “性能調(diào)優(yōu)”】免費(fèi)下載！

就可以成功。

總之，針對(duì)這個(gè)問題，我的觀點(diǎn)是保證入隊(duì)有序就行，出隊(duì)以后的順序交給消費(fèi)者自己去保證，沒有固定套路。

最后

小編利用空余時(shí)間整理了一份《MySQL性能調(diào)優(yōu)手冊(cè)》，初衷也很簡(jiǎn)單，就是希望能夠幫助到大家，減輕大家的負(fù)擔(dān)和節(jié)省時(shí)間。

關(guān)于這個(gè)，給大家看一份學(xué)習(xí)大綱（PDF）文件，每一個(gè)分支里面會(huì)有詳細(xì)的介紹。

[外鏈圖片轉(zhuǎn)存中…(img-4JyE6rxr-1623850686005)]

這里都是以圖片形式展示介紹，如要下載原文件以及更多的性能調(diào)優(yōu)筆記（MySQL+Tomcat+JVM）可以直接【點(diǎn)擊 “性能調(diào)優(yōu)”】免費(fèi)下載！

總結(jié)

以上是生活随笔為你收集整理的【工作经验分享】不会真有人觉得mybatis很难学吧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。