15個PHP關於高併發的面試題（總結）

相關文章推薦：《深入探討「高並發大流量」存取的解決想法與方案》

1、什麼是rabbitmq

採用AMQP高階訊息佇列協定的一種訊息佇列技術,最大的特點就是消費並不需要確保提供方存在,實現了服務之間的高度解耦

2、為什麼要使用rabbitmq

• 在分散式系統下具備非同步,削峰,負載平衡等一系列高階功能;

• 擁有持久化的機制，進程訊息，佇列中的資訊也可以保存下來。

• 實作消費者和生產者之間的解耦。

• 對於高並發場景下，利用訊息佇列可以使得同步存取變成串列存取達到一定量的限流，利於資料庫的操作。

• 可以使用訊息佇列達到非同步下單的效果，排隊中，後台進行邏輯下單。

3、使用rabbitmq的場景

• 服務間非同步通訊

• 順序消費

• 定時任務

• #請求削峰

##4、如何確保訊息正確地傳送至RabbitMQ？如何確保訊息接收方消費了訊息？

發送方確認模式

#將頻道設為confirm模式（發送方確認模式），則所有在頻道上發布的訊息都會被指派一個唯一的ID。

一旦訊息被投遞到目的佇列後，或訊息被寫入磁碟後（可持久化的訊息），頻道會傳送一個確認給生產者（包含訊息唯一ID）。

如果RabbitMQ發生內部錯誤而導致訊息遺失，會發送nack（not acknowledged，未確認）訊息。

發送方確認模式是非同步的，生產者應用程式在等待確認的同時，可以繼續發送訊息。當確認訊息到達生產者應用程序，生產者應用程式的回調方法就會被觸發來處理確認訊息。

接收者確認機制

#接收方訊息確認機制

消費者接收每一則訊息後都必須進行確認（訊息接收和訊息確認是兩個不同操作）。只有消費者確認了訊息，RabbitMQ才能安全地把訊息從佇列中刪除。

這裡並沒有用到逾時機制，RabbitMQ僅透過Consumer的連線中斷來確認是否需要重新傳送訊息。也就是說，只要連線不中斷，RabbitMQ給了Consumer足夠長的時間來處理訊息。保證資料的最終一致性；

下面羅列幾種特殊情況

• #如果消費者接收到訊息，在確認之前斷開了連結或取消訂閱，RabbitMQ會認為訊息沒有被分發，然後重新分發給下一個訂閱的消費者。 （可能有訊息重複消費的隱患，需要去重）

• 如果消費者接收到訊息卻沒有確認訊息，連結也未斷開，則RabbitMQ認為該消費者繁忙，將不會給該消費者分發更多的訊息。

5.如何避免訊息重複投遞或重複消費？

在訊息生產時，MQ內部針對每個生產者發送的訊息產生一個inner-msg-id，作為去重的依據（訊息投遞失敗並重傳），避免重複的訊息進入佇列；

在訊息消費時，要求訊息體中必須有一個bizId（對於同一業務全域唯一，如支付ID、訂單ID、貼文ID等）作為去重的依據，避免同一則訊息重複消費。

6、訊息基於什麼傳輸？

由於TCP連線的建立和銷毀開銷較大，且並發數受系統資源限制，會造成效能瓶頸。 RabbitMQ使用通道的方式來傳輸資料。頻道是建立在真實的TCP連接內的虛擬連接，且每個TCP連接上的頻道數量沒有限制。

7、訊息如何分發？

若該佇列至少有一個消費者訂閱，訊息將以循環（round-robin）的方式傳送給消費者。每個訊息只會分發給一個訂閱的消費者（前提是消費者能夠正常處理訊息並進行確認）。透過路由可實現多消費的功能

8、訊息怎麼路由？ #

訊息提供者->路由->一至多個佇列 當訊息發佈到交換器時，訊息將擁有一個路由鍵（routing key），在訊息建立時設定。透過佇列路由鍵，可以把佇列綁定到交換器上。

訊息到達交換器後，RabbitMQ會將訊息的路由鍵與佇列的路由鍵進行比對（針對不同的交換器有不同的路由規則）；

常用的交換器主要分成三種

• fanout：如果交換器收到訊息，將會廣播到所有綁定的佇列上

• direct：如果路由鍵完全匹配，訊息就會被投遞到對應的佇列

• topic：可以讓來自不同來源的訊息能夠到達同一個佇列。使用topic交換器時，可以使用通配符

9、如何確保訊息不遺失？

訊息持久化，當然前提是佇列必須持久化RabbitMQ確保持久性訊息能從伺服器重新啟動中恢復的方式是，將它們寫入磁碟上的一個持久化日誌文件，當發布一條持久性訊息到持久性交換器上時，Rabbit會在訊息提交到日誌檔案後才發送回應。

一旦消費者從持久佇列中消費了一條持久化訊息，RabbitMQ會在持久化日誌中把這則訊息標記為等待垃圾收集。如果持久化訊息在被消費之前RabbitMQ重啟，那麼Rabbit會自動重建交換器和佇列（以及綁定），並重新發布持久化日誌檔案中的訊息到適當的佇列。

10、使用RabbitMQ有什麼好處？

1、服務間高度解耦 

2、非同步通訊效能高 

3、流量削峰

11、rabbitmq的叢集

鏡像叢集模式

你建立的queue，無論元資料或queue裡的消息都會存在於多個實例上，然後每次你寫訊息到queue的時候，都會自動把訊息到多個實例的queue裡進行訊息同步。

好處在於，你任何一個機器宕機了，沒事，別的機器都可以用。壞處在於，第一，這個效能開銷也太大了吧，訊息同步所有機器，導致網路頻寬壓力和消耗很重！第二，這麼玩兒，就沒有擴展性可言了，如果某個queue負載很重，你加機器，新增的機器也包含了這個queue的所有數據，並沒有辦法線性擴展你的queue

12.mq的缺點

系統可用性降低

系統引入的外部依賴越多，越容易掛掉，本來你就是A系統呼叫BCD三個系統的介面就好了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？ MQ掛了，整套系統崩潰了，你不就結束了。

系統複雜度提高

硬生加個MQ進來，你怎麼保證訊息沒有重複消費？怎麼處理訊息遺失的情況？怎麼保證訊息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已

#13.一致性問題

A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那裡，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。

所以訊息佇列實際上是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，最好之後，你會發現，媽呀，系統複雜度提升了一個數量級，也許是複雜了10倍。但是關鍵時刻，用，還是得用的

14. 分散式交易

分段提交。會有一個仲裁者，然後給所有節點來發送訊息。當所有節點都ack之後，才會成功。否則就得等待重發。

15.針對直播這種突然大流量的情況，該怎麼設計。

• NGINX加上機器

• #cdn快取靜態頁面

• redis隊列，讓用戶慢點進來。

• 加上快取。快取用戶數據，例如用戶資訊。

• 資料庫使用主從

• 彈性擴充功能

• ##限流熔斷

相關教學推薦：《

PHP教學》

以上是15個PHP關於高併發的面試題（總結）的詳細內容。更多資訊請關注PHP中文網其他相關文章！