《面試官別再問》Redis、Memecache這兩者有什麼區別？

Redis 支持更加豐富的數據存儲類型，String、Hash、List、Set 和Sorted Set。 Memcached 僅支持簡單的key-value 結構。
Memcached key-value存儲比Redis 採用hash 結構來做key-value 存儲的內存利用率更高。
Redis 提供了事務的功能，可以保證一系列命令的原子性
Redis 支持數據的持久化，可以將內存中的數據保持在磁盤中
Redis 只使用單核，而Memcached 可以使用多核，所以平均每一個核上Redis 在存儲小數據時比Memcached 性能更高。

Redis如何實現持久化？

RDB 持久化，將redis 在內存中的的狀態保存到硬碟中，相當於備份數據庫狀態。
AOF 持久化（Append-Only-File），AOF 持久化是通過保存Redis 服務器鎖執行的寫狀態來記錄數據庫的。相當於備份數據庫接收到的命令，所有被寫入AOF 的命令都是以redis 的協議格式來保存的。

基本命令

Memcached的命令或者説通訊協議非常簡單，Server所支持的命令基本就是對特定key的添加，刪除，替換，原子更新，讀取等，具體包括 Set, Get, Add, Replace, Append, Inc/Dec 等等

Memcached的通訊協議包括文本格式和二進制格式，用於滿足簡單網絡客户端工具（如telnet）和對性能要求更高的客户端的不同需求

Redis的命令在KV（String類型）上提供與Memcached類似的基本操作，在其它數據結構上也支持基本類似的操作（當然還有這些數據結構所特有的操作，如Set的union，List的pop等）而支持更多的數據結構，在一定程度上也就意味着更加廣泛的應用場合

除了多種數據結構的支持，Redis相比Memcached還提供了許多額外的特性，比如Subscribe/publish命令，以支持發佈/訂閲模式這樣的通知機制等等，這些額外的特性同樣有助於拓展它的應用場景

Redis的客户端-服務器通訊協議完全採用文本格式（在將來可能的服務器間通訊會採用二進制格式）

事務

redis通過Multi / Watch /Exec等命令可以支持事務的概念，原子性的執行一批命令。在2.6以後的版本中由於添加了對Script腳本的支持，而腳本固有的是以transaction事務的方式執行的，並且更加易於使用，所以不排除將來取消Multi等命令接口的可能性

Memcached的應用模式中，除了increment/decrement這樣的原子操作命令，不存在對事務的支持

數據備份，有效性，持久化等

memcached不保證存儲的數據的有效性，Slab內部基於LRU也會自動淘汰舊數據，客户端不能假設數據在服務器端的當前狀態，這應該説是Memcached的Feature設定，用户不必太多關心或者自己管理數據的淘汰更新工作，當然是否適合你的應用，取決於具體的需求，它也可能成為你需要精確自行控制Cache生命週期的一個障礙

 Memcached也不做數據的持久化工作，但是有許多基於memcached協議的項目實現了數據的持久化，例如memcacheDB使用BerkeleyDB進行數據存儲，但本質上它已經不是一個Cache Server，而只是一個兼容Memcached的協議key-valueData Store了

Redis可以以master-slave的方式配置服務器，Slave節點對數據進行replica備份，Slave節點也可以充當Read only的節點分擔數據讀取的工作

《面試官別再問》Laravel 模組

服務提供者是什麼？
服務提供者是所有Laravel 應用程序引導啟動的中心, Laravel 的核心服務器、註冊服務容器綁定、事件監聽、中間件、路由註冊以及我們的應用程序都是由服務提供者引導啟動的。
Contract的原理？
Contract（契約）是laravel 定義框架提供的核心服務的接口。 Contract 和Facades 並沒有本質意義上的區別，其作用就是使接口低耦合、更簡單。
IoC容器是什麼？

IoC（Inversion of Control）譯為「控制反轉」，也被叫做「依賴注入」(DI)。什麼是「控制反轉」？對象A 功能依賴於對象B，但是控制權由對象A 來控制，控制權被顛倒，所以叫做「控制反轉」，而「依賴注入」是實現IoC 的方法，就是由IoC 容器在運行期間，動態地將某種依賴關係注入到對象之中。
其作用簡單來講就是利用依賴關係注入的方式，把複雜的應用程序分解為互相合作的對象，從而降低解決問題的複雜度，實現應用程序代碼的低耦合、高擴展。

Laravel中的服務容器是用於管理類的依賴和執行依賴注入的工具。
參考網址

依賴注入的原理？

@overtrue一句話解釋：依賴注入只是一種模式：把當前類依賴的第三方實例通過參數傳入的形式引入，但是如果手寫依賴注入會比較費勁，管理起來也比較麻煩，因為要關心那麼多類的依賴，於是就有了一個容器來自動解決這個問題，利用反射API檢查類型，然後遞歸解決依賴。
Facade是什麼？
Facades（一種設計模式，通常翻譯為外觀模式）提供了一個"static"（靜態）接口去訪問註冊到IoC 容器中的類。提供了簡單、易記的語法，而無需記住必須手動注入或配置的長長的類名。此外，由於對PHP 動態方法的獨特用法，也使測試起來非常容易。
了解過Composer？實現原理是什麼？
Composer 是PHP 的一個依賴管理工具。工作原理就是將已開發好的擴展包從packagist.org composer 倉庫下載到我們的應用程序中，並聲明依賴關係和版本控制。

《面試官別再問》HTTP狀態碼有哪些？區別？

---

深入解析 HTTP 狀態碼：協定溝通的語言

HTTP 狀態碼（HTTP Status Codes）是網路世界中，客戶端（通常是瀏覽器或應用程式）與伺服器之間溝通的關鍵訊息。每一次 HTTP 請求的往返，伺服器都會回傳一個三位數的數字狀態碼，用以告知客戶端該請求的處理結果。這些狀態碼不僅是單純的回應，更是診斷網路問題、優化應用程式效能以及確保網站安全的重要依據。

狀態碼的第一位數字定義了回應的類別，從而提供對請求結果的初步判斷。以下將詳細闡述 HTTP 狀態碼的五大類別及其核心區別。

---

1xx 資訊回應 (Informational Responses)

• 意義：表示伺服器已收到請求的初始部分，並正在繼續處理。這些回應通常是臨時性的，旨在指示客戶端應繼續發送請求的其餘部分，或作為一種進度指示。它們通常不會攜帶實際的響應主體。

• 常見範例：

  • 100 Continue：伺服器已收到請求的頭部，並且客戶端應該繼續發送請求的其餘部分。

  • 101 Switching Protocols：伺服器同意客戶端的請求，將協定從一個版本升級到另一個版本（例如從 HTTP/1.1 升級到 WebSocket）。

• 區別：1xx 狀態碼主要用於伺服器與客戶端之間在請求開始階段的協商，對使用者而言是透明的，主要影響底層連線行為。

---

2xx 成功 (Successful Responses)

• 意義：表示客戶端的請求已成功被伺服器接收、理解、接受並處理。這是最期望的結果，意味著所請求的操作已按預期完成。

• 常見範例：

  • 200 OK：最常見的成功狀態碼。表示請求已成功，且伺服器已返回所請求的資源。對於 GET 請求，資源內容在響應主體中；對於 POST 請求，響應主體通常包含操作結果。

  • 201 Created：請求已成功，並且由於該請求而建立了一個新的資源。通常是 POST 或 PUT 請求的結果，響應中的 Location 標頭會指向新建立資源的 URI。

  • 202 Accepted：請求已被接受處理，但處理尚未完成。這表示請求已被放入佇列，伺服器可能在稍後完成操作。

  • 204 No Content：伺服器已成功處理請求，但響應中不包含任何內容（例如 PUT 或 DELETE 請求，僅需確認操作完成）。

• 區別：2xx 狀態碼明確表示操作成功，客戶端可以依賴響應內容或操作完成的確認。

---

3xx 重新導向 (Redirection Messages)

• 意義：表示為了完成請求，客戶端需要採取進一步的動作。這通常涉及將客戶端重定向到不同的 URI，以獲取所需的資源。

• 常見範例：

  • 301 Moved Permanently：所請求的資源已永久性地移動到新的 URI。客戶端應更新其書籤或快取，並在未來的請求中使用新的 URI。這對於搜尋引擎優化（SEO）至關重要，因為它傳遞了頁面排名權重。

  • 302 Found (原名 "Moved Temporarily")：所請求的資源已暫時性地移動到不同的 URI。客戶端應在未來繼續使用原始 URI。

  • 303 See Other：指示客戶端應使用 GET 方法在另一個 URI 上檢索資源。常在 POST 請求後使用，以避免重新提交表單。

  • 304 Not Modified：表示客戶端條件式 GET 請求的資源自上次請求以來沒有被修改。伺服器不需要返回資源本身，客戶端應使用其快取副本。

• 區別：3xx 狀態碼的核心在於指示資源位置的變更。理解其「永久性」與「暫時性」的差異，對於快取策略、SEO 和用戶體驗至關重要。

---

4xx 客戶端錯誤 (Client Error Responses)

• 意義：表示客戶端發出的請求存在錯誤，導致伺服器無法處理。這些錯誤通常由客戶端提供不正確的語法、無效的參數、缺少必要的身份驗證或權限不足引起。

• 常見範例：

  • 400 Bad Request：伺服器無法理解請求，因為其語法無效或格式不正確。

  • 401 Unauthorized：請求需要客戶端進行身份驗證。客戶端應使用有效的憑證（例如 WWW-Authenticate 標頭）重新發送請求。

  • 403 Forbidden：伺服器理解請求，但拒絕執行。這表示客戶端沒有訪問所請求資源的權限，即使提供了有效的身份驗證憑證也可能被拒絕。

  • 404 Not Found：伺服器找不到所請求的資源。這是最常見的錯誤碼之一，通常發生在資源已被移除或 URI 不正確時。

  • 405 Method Not Allowed：請求中使用的方法（如 GET, POST, PUT, DELETE）不被目標資源或 URI 所支援。

  • 429 Too Many Requests：客戶端在給定時間內發送了過多的請求（頻率限制）。

• 區別：4xx 狀態碼明確指出問題的根源在於客戶端的請求。對於開發者而言，這意味著需要檢查請求的結構、參數、認證或權限。

---

5xx 伺服器錯誤 (Server Error Responses)

• 意義：表示伺服器在處理客戶端合法請求的過程中發生了內部錯誤，導致無法完成請求。這些錯誤與客戶端的請求本身無關，而是伺服器端應用程式或基礎設施層面的問題。

• 常見範例：

  • 500 Internal Server Error：一個通用的伺服器錯誤訊息，表示伺服器遇到了一個意外情況，阻止其完成請求。具體原因通常需要檢查伺服器端的應用程式日誌。

  • 501 Not Implemented：伺服器不支援完成請求所需的功能或方法。

  • 502 Bad Gateway：伺服器作為閘道器或代理，從上游伺服器（例如另一個網頁伺服器或應用程式伺服器）接收到無效的響應。

  • 503 Service Unavailable：伺服器目前無法處理請求，通常是因為伺服器過載或正在進行維護。這通常是暫時性的情況，響應中可能包含 Retry-After 標頭以指示何時可以再次嘗試。

  • 504 Gateway Timeout：伺服器作為閘道器或代理，沒有在規定的時間內從上游伺服器收到回應。

• 區別：5xx 狀態碼表明問題出在伺服器端，客戶端通常無法直接解決。這些錯誤需要後端開發者或系統管理員介入，檢查伺服器應用程式、資料庫、網路配置或硬體狀況。

---

總結

精準理解 HTTP 狀態碼是每位網路開發者、系統管理員和 SRE（站點可靠性工程師）的必備技能。它們不僅是診斷問題的利器，更是構建高效、可靠和安全網路應用的基石。透過對這些數字背後語義的掌握，我們可以更迅速地定位問題、優化系統行為，並為使用者提供更流暢的網路體驗。