PHP有哪些關(guān)于高并發(fā)的面試題

PHP有哪些關(guān)于高并發(fā)的面試題？相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

1、什么是rabbitmq

采用AMQP高級(jí)消息隊(duì)列協(xié)議的一種消息隊(duì)列技術(shù),最大的特點(diǎn)就是消費(fèi)并不需要確保提供方存在,實(shí)現(xiàn)了服務(wù)之間的高度解耦

2、為什么要使用rabbitmq

1. 在分布式系統(tǒng)下具備異步,削峰,負(fù)載均衡等一系列高級(jí)功能;

2. 擁有持久化的機(jī)制，進(jìn)程消息，隊(duì)列中的信息也可以保存下來(lái)。

3. 實(shí)現(xiàn)消費(fèi)者和生產(chǎn)者之間的解耦。

4. 對(duì)于高并發(fā)場(chǎng)景下，利用消息隊(duì)列可以使得同步訪問(wèn)變?yōu)榇性L問(wèn)達(dá)到一定量的限流，利于數(shù)據(jù)庫(kù)的操作。

可以使用消息隊(duì)列達(dá)到異步下單的效果，排隊(duì)中，后臺(tái)進(jìn)行邏輯下單

3、使用rabbitmq的場(chǎng)景

1. 服務(wù)間異步通信

2. 順序消費(fèi)

3. 定時(shí)任務(wù)

4. 請(qǐng)求削峰

4、如何確保消息正確地發(fā)送至RabbitMQ？ 如何確保消息接收方消費(fèi)了消息？

發(fā)送方確認(rèn)模式

將信道設(shè)置成confirm模式（發(fā)送方確認(rèn)模式），則所有在信道上發(fā)布的消息都會(huì)被指派一個(gè)唯一的ID。

一旦消息被投遞到目的隊(duì)列后，或者消息被寫入磁盤后（可持久化的消息），信道會(huì)發(fā)送一個(gè)確認(rèn)給生產(chǎn)者（包含消息唯一ID）。

如果RabbitMQ發(fā)生內(nèi)部錯(cuò)誤從而導(dǎo)致消息丟失，會(huì)發(fā)送一條nack（not acknowledged，未確認(rèn)）消息。

發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時(shí)，可以繼續(xù)發(fā)送消息。當(dāng)確認(rèn)消息到達(dá)生產(chǎn)者應(yīng)用程序，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會(huì)被觸發(fā)來(lái)處理確認(rèn)消息。

接收方確認(rèn)機(jī)制

接收方消息確認(rèn)機(jī)制

消費(fèi)者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個(gè)不同操作）。只有消費(fèi)者確認(rèn)了消息，RabbitMQ才能安全地把消息從隊(duì)列中刪除。

這里并沒(méi)有用到超時(shí)機(jī)制，RabbitMQ僅通過(guò)Consumer的連接中斷來(lái)確認(rèn)是否需要重新發(fā)送消息。也就是說(shuō)，只要連接不中斷，RabbitMQ給了Consumer足夠長(zhǎng)的時(shí)間來(lái)處理消息。保證數(shù)據(jù)的最終一致性；

下面羅列幾種特殊情況

如果消費(fèi)者接收到消息，在確認(rèn)之前斷開(kāi)了連接或取消訂閱，RabbitMQ會(huì)認(rèn)為消息沒(méi)有被分發(fā)，然后重新分發(fā)給下一個(gè)訂閱的消費(fèi)者。（可能存在消息重復(fù)消費(fèi)的隱患，需要去重）

如果消費(fèi)者接收到消息卻沒(méi)有確認(rèn)消息，連接也未斷開(kāi)，則RabbitMQ認(rèn)為該消費(fèi)者繁忙，將不會(huì)給該消費(fèi)者分發(fā)更多的消息。

5.如何避免消息重復(fù)投遞或重復(fù)消費(fèi)？

在消息生產(chǎn)時(shí)，MQ內(nèi)部針對(duì)每條生產(chǎn)者發(fā)送的消息生成一個(gè)inner-msg-id，作為去重的依據(jù)（消息投遞失敗并重傳），避免重復(fù)的消息進(jìn)入隊(duì)列；

在消息消費(fèi)時(shí)，要求消息體中必須要有一個(gè)bizId（對(duì)于同一業(yè)務(wù)全局唯一，如支付ID、訂單ID、帖子ID等）作為去重的依據(jù)，避免同一條消息被重復(fù)消費(fèi)。

6、消息基于什么傳輸？

由于TCP連接的創(chuàng)建和銷毀開(kāi)銷較大，且并發(fā)數(shù)受系統(tǒng)資源限制，會(huì)造成性能瓶頸。RabbitMQ使用信道的方式來(lái)傳輸數(shù)據(jù)。信道是建立在真實(shí)的TCP連接內(nèi)的虛擬連接，且每條TCP連接上的信道數(shù)量沒(méi)有限制。

7、消息如何分發(fā)？

若該隊(duì)列至少有一個(gè)消費(fèi)者訂閱，消息將以循環(huán)（round-robin）的方式發(fā)送給消費(fèi)者。每條消息只會(huì)分發(fā)給一個(gè)訂閱的消費(fèi)者（前提是消費(fèi)者能夠正常處理消息并進(jìn)行確認(rèn)）。 通過(guò)路由可實(shí)現(xiàn)多消費(fèi)的功能

8、消息怎么路由？

消息提供方->路由->一至多個(gè)隊(duì)列 消息發(fā)布到交換器時(shí)，消息將擁有一個(gè)路由鍵（routing key），在消息創(chuàng)建時(shí)設(shè)定。 通過(guò)隊(duì)列路由鍵，可以把隊(duì)列綁定到交換器上。

消息到達(dá)交換器后，RabbitMQ會(huì)將消息的路由鍵與隊(duì)列的路由鍵進(jìn)行匹配（針對(duì)不同的交換器有不同的路由規(guī)則）；

常用的交換器主要分為一下三種

· fanout：如果交換器收到消息，將會(huì)廣播到所有綁定的隊(duì)列上

· direct：如果路由鍵完全匹配，消息就被投遞到相應(yīng)的隊(duì)列

· topic：可以使來(lái)自不同源頭的消息能夠到達(dá)同一個(gè)隊(duì)列。 使用topic交換器時(shí)，可以使用通配符

9、如何確保消息不丟失？

消息持久化，當(dāng)然前提是隊(duì)列必須持久化 RabbitMQ確保持久性消息能從服務(wù)器重啟中恢復(fù)的方式是，將它們寫入磁盤上的一個(gè)持久化日志文件，當(dāng)發(fā)布一條持久性消息到持久交換器上時(shí)，Rabbit會(huì)在消息提交到日志文件后才發(fā)送響應(yīng)。

一旦消費(fèi)者從持久隊(duì)列中消費(fèi)了一條持久化消息，RabbitMQ會(huì)在持久化日志中把這條消息標(biāo)記為等待垃圾收集。如果持久化消息在被消費(fèi)之前RabbitMQ重啟，那么Rabbit會(huì)自動(dòng)重建交換器和隊(duì)列（以及綁定），并重新發(fā)布持久化日志文件中的消息到合適的隊(duì)列。

10、使用RabbitMQ有什么好處？

1、服務(wù)間高度解耦

2、異步通信性能高

3、流量削峰

11、rabbitmq的集群

鏡像集群模式

你創(chuàng)建的queue，無(wú)論元數(shù)據(jù)還是queue里的消息都會(huì)存在于多個(gè)實(shí)例上，然后每次你寫消息到queue的時(shí)候，都會(huì)自動(dòng)把消息到多個(gè)實(shí)例的queue里進(jìn)行消息同步。

好處在于，你任何一個(gè)機(jī)器宕機(jī)了，沒(méi)事兒，別的機(jī)器都可以用。壞處在于，第一，這個(gè)性能開(kāi)銷也太大了吧，消息同步所有機(jī)器，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！第二，這么玩兒，就沒(méi)有擴(kuò)展性可言了，如果某個(gè)queue負(fù)載很重，你加機(jī)器，新增的機(jī)器也包含了這個(gè)queue的所有數(shù)據(jù)，并沒(méi)有辦法線性擴(kuò)展你的queue

12.mq的缺點(diǎn)

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

系統(tǒng)引入的外部依賴越多，越容易掛掉，本來(lái)你就是A系統(tǒng)調(diào)用BCD三個(gè)系統(tǒng)的接口就好了，人ABCD四個(gè)系統(tǒng)好好的，沒(méi)啥問(wèn)題，你偏加個(gè)MQ進(jìn)來(lái)，萬(wàn)一MQ掛了咋整？MQ掛了，整套系統(tǒng)崩潰了，你不就完了么。

系統(tǒng)復(fù)雜性提高

硬生生加個(gè)MQ進(jìn)來(lái)，你怎么保證消息沒(méi)有重復(fù)消費(fèi)？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問(wèn)題一大堆，痛苦不已

13.一致性問(wèn)題

A系統(tǒng)處理完了直接返回成功了，人都以為你這個(gè)請(qǐng)求就成功了；但是問(wèn)題是，要是BCD三個(gè)系統(tǒng)那里，BD兩個(gè)系統(tǒng)寫庫(kù)成功了，結(jié)果C系統(tǒng)寫庫(kù)失敗了，咋整？你這數(shù)據(jù)就不一致了。

所以消息隊(duì)列實(shí)際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對(duì)它帶來(lái)的壞處做各種額外的技術(shù)方案和架構(gòu)來(lái)規(guī)避掉，最好之后，你會(huì)發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個(gè)數(shù)量級(jí)，也許是復(fù)雜了10倍。但是關(guān)鍵時(shí)刻，用，還是得用的

14. 分布式事務(wù)

分段提交。會(huì)有一個(gè)仲裁者，然后給所有節(jié)點(diǎn)來(lái)發(fā)消息。當(dāng)所有節(jié)點(diǎn)都ack之后，才會(huì)成功。否則就得等待重發(fā)。

15.針對(duì)直播這種突然大流量的情況，該怎么設(shè)計(jì)。

1. NGINX加機(jī)器

2. cdn緩存靜態(tài)頁(yè)面

3. redis隊(duì)列，讓用戶慢點(diǎn)進(jìn)來(lái)。

4. 加緩存。緩存用戶數(shù)據(jù)，比如用戶信息。

5. 數(shù)據(jù)庫(kù)使用主從

6. 彈性擴(kuò)容

7. 限流熔斷

看完上述內(nèi)容，你們掌握PHP有哪些關(guān)于高并發(fā)的面試題的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！