PHP有哪些關于高并發的面試題

PHP有哪些關于高并發的面試題？相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

1、什么是rabbitmq

采用AMQP高級消息隊列協議的一種消息隊列技術,最大的特點就是消費并不需要確保提供方存在,實現了服務之間的高度解耦

2、為什么要使用rabbitmq

1. 在分布式系統下具備異步,削峰,負載均衡等一系列高級功能;

2. 擁有持久化的機制，進程消息，隊列中的信息也可以保存下來。

3. 實現消費者和生產者之間的解耦。

4. 對于高并發場景下，利用消息隊列可以使得同步訪問變為串行訪問達到一定量的限流，利于數據庫的操作。

可以使用消息隊列達到異步下單的效果，排隊中，后臺進行邏輯下單

3、使用rabbitmq的場景

1. 服務間異步通信

2. 順序消費

3. 定時任務

4. 請求削峰

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.針對直播這種突然大流量的情況，該怎么設計。

1. NGINX加機器

2. cdn緩存靜態頁面

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

4. 加緩存。緩存用戶數據，比如用戶信息。

5. 數據庫使用主從

6. 彈性擴容

7. 限流熔斷

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