laravel開發總結（2）

1、避免使用select *

在laravel中，提供了Model::get()方法來獲取實體對象，但是get()方法默認是使用的select *，我們知道，一條sql語句的時間一般由兩部分組成，查詢語句執行時間和結果傳輸時間。如果數據表的列比較多，且每一列的數據都不小，那麼傳輸時間往往決定着整條sql語句的性能，減少不必要的字段傳輸，從而減少整個結果的傳輸量可以大大減少sql的總時間，進而提升性能。get()方法接受一個array來確定查詢的字段。

$params = [
	'user_name',
	'email'
];
$users = User::where('delete_mark',false)->get(params);

那麼此時返回的就只包含查詢的$user\_name$和$email$兩個字段。

2、修改了fpm的php.ini和fpm的配置文件後，最好使用fpm自帶的語句啓動一次

先使用php-fpm的方法運行，如果沒有報錯，轉而使用service的方法
使用service的方法，如果php.ini配置出錯，是不會有報錯信息的，會讓人誤以爲fpm啓動成功了（本質上fpm確實啓動成功了），
不過有很多必要的模塊沒有被加載進來。一般方法是直接找到Fpm的運行程序，例如：ubuntu在 /usr/sbin下面，然後執行

php-fpm7.3 -c /etc/php/7.3/fpm/php.ini
# -c 指定php配置文件位置(php.ini的位置) 
# -y 指定fpm配置文件位置
# 完整的例子如下
php-fpm7.3 -y /etc/php/7.3/fpm/php-fpm.conf -c /etc/php/7.3/fpm/php.ini

執行結果沒有任何報錯，那麼可以確定php.ini是沒有問題的。然後。執行

rm -f /run/php/php7.3-fpm.sock

中止fpm的運行，然後使用fpm服務打開

3、mysql設置自增id的起始值

這個方法在導數據的時候用得比較多，當甲方對數據不明確，導入的數據會被反覆替換的時候，就可以使用此方法，重置自增的id。

alter table xxx_table AUTO_INCRMENT = 1;

4、緩存的生命週期

參考自 http緩存機制
主要在於cache-control這個header中起作用
在response的header中配置cache-control這個字段：可以告訴瀏覽器應該怎麼去做

字段值	含義
no-cache	緩存必須重新校驗
no-store	不存儲緩存
no-transform	緩存內容時不能對改變任何數據
public	響應可被任何緩存區緩存
private	只在本地緩存，不允許任何中繼緩存對其進行緩存（例如，瀏覽器可以緩存，但是CDN不能緩存）
must-revalidate	如果緩存的內容失效，請求必須發送到服務器以進行重新驗證（請求失敗返回504，而非中間緩存CDN）
proxy-revalidate	與must-revalidate類似，僅能用於共享緩存（如：CDN）
max-age	只接受 Age 值小於 max-age 值，並且沒有過期的資源
s-maxage	僅能用於共享緩存，一般用在cache服務器上(如：CDN)

在request中header的配置cache-control字段，告訴服務器，我的緩存機制是如何的

字段值	含義
max-age	可以接收緩存最長時間
max-stale	可以接收過期的資源，但是過期時間必須小於 max-stale 值
min-fresh	可以接收一個更新過的資源，fresh生命期大於其當前 Age 跟 min-fresh 值之和
no-cache	在源服務器返回成功的驗證之前不能使用緩存響應
no-store	直接禁止瀏覽器和所有中繼緩存存儲返回的任何版本的響應
no-transform	獲取沒有被轉換過（比如壓縮）的資源
only-if-cached	希望獲取緩存內容而不發起請求

laravel中添加所有接口cache-control的方法

可以在中間件中加一個全局攔截添加cache-control的操作

nginx對緩存會做什麼

利用請求的局部性原理，將請求過的內容在本地建立一個副本，下次訪問時不再連接到後端服務器，直接響應本地內容
Nginx服務器啓動後，會對本地磁盤上的緩存文件進行掃描，在內存中建立緩存索引，並有專門的進程對緩存文件進行過期判斷、更新等進行管理
要使用緩存，首先要使用 proxy_cache_path 這個指令（必須放在 http 上下文的頂層位置），然後在目標上下文中使用 proxy_cache 指令
proxy_cache_path 有兩個必填參數，第一個參數爲 緩存目錄，第二個參數keys_zone指定緩存名稱和佔用內存空間的大小

5、如何打印php到nginx的所有輸出日誌，方便定位錯誤（即監控php項目）

查看nginx中配置的access.log和error.log
php的錯誤可以在php.ini中查找路徑，然後找到即可

從http請求的過程我們知道，一個http請求來到nginx之後，被nginx包裝fastcgi協議傳給php的sapi（例如php-fpm），fpm將fastcgi解析出來，發給php內核去執行，
然後php內核將執行後的結果直接返回給Nginx。從這一點可以得出，nginx的error日誌產生於php執行內核，如果php執行內核出錯，那麼nginx就會出錯。
也就是說，error.log出現的後端的問題，就是php內核執行拋出的。

那麼，我該從哪裏找到php收到了哪些請求呢？主要是不確定，nginx是否會把一些請求直接做緩存處理，從而不給php內核處理。

6、各種sapi裏面的php.ini在啓動的時候是如何相互運作的

理論上是使用的自己的php.ini。即自己目錄下的，php的cgi擴展和fpm擴展是不同的存在

PHP-CGI

是 CGI 協議 php 的一個實現版。PHP-CGI 會爲每個請求 fork 一個進程處理，處理完成後退出。
(這個模式叫做 fork-and-execute)。這樣的模式不符合現在動不動大規模的流量，所以已退出歷史舞臺。

PHPFPM

當發現 PHP-CGI 性能不佳時，又恰好出現了 FastCGI 協議。所以 PHP 實現了一個 php 版本的 FastCGI，名字叫做 PHPFPM（FastCGI Process Manager）。
PHPFPM 啓動時會開啓 一個 master 進程和若干個 work 進程。master 進程監聽請求，並轉發給 work 進程處理，每一個 work 進程
都有一個 php 解釋器，你的代碼在每一個 work 進程中都有一份，work 進程是真正執行代碼的地方。

有個情況是：cgi下面的php.ini什麼擴展都沒打開，fpm下面把該打開的擴展都打開了。當運行cgi的時候，卻能正常使用這些擴展，原因何在?

7、文件句柄究竟如何工作

產生文件句柄的地方：
open系統調用打開文件（path_openat內核函數)
打開一個目錄（dentry_open函數)
共享內存attach （do_shmat函數）
socket套接字（sock_alloc_file函數）
管道（create_pipe_files函數）
epoll/inotify/signalfd等功能用到的匿名inode文件系統（anon_inode_getfile函數)

查看線程佔句柄數：ulimit -a
查看系統打開句柄最大數量：more /proc/sys/fs/file-max
查看打開句柄總數：lsof|awk ‘{print 2}’|wc -l 根據打開文件句柄的數量降序排列，其中第二列爲進程ID：lsof|awk ‘{print2}’|sort|uniq -c|sort -nr|more
根據獲取的進程ID查看進程的詳情：ps -ef |grep pid
修改linux單進程最大文件連接數:

修改linux系統參數。vi /etc/security/limits.conf 添加
*　　soft　　nofile　　65536
*　　hard　　nofile　　65536
修改以後保存，註銷當前用戶，重新登錄，執行ulimit -a ,ok ,參數生效了：

8、fastcgi協議內容

借鑑於FastCGI 協議規範中文版

fastcgi是web服務器（如nginx/apache）和處理程序之間的一種通信協議，它是與HTTP類似的一種應用層通信協議。

cgi是通用網關接口

FastCGI 和 CGI 應用實現上的最大的區別是，FastCGI 應用實現模塊中會有一個常駐服務進程。一個 CGI 應用的典型實現是，每次響應一個 Web 服務器發送過來的請求時，都會創建和初始化一個新的處理進程，使用這個進程來產生此請求對應的響應數據，最後在處理結束之後，關閉此進程。FastCGI 應用的初始化要比 CGI/1.1 的簡化很多，其進程是固定常駐的，不需要管理生命週期，不需要初始化標準輸入輸出流 stdin、stdout、stderr，也不需要讀取大量的環境變量。此初始化的核心部分是監聽一個 socket（套接字），通過這個 socket 來接收 Web 服務器發來的請求。可以讓多個 HTTP 請求使用同一個連接進行數據交互，這樣應用的實現就可以採用事件驅動編程模型或者多線程編程模型。
同一個請求的多個數據流的傳輸可以複用同一個連接。

fastcgi並不是屬於php的，它是一種協議，php只是實現了能以這種協議交互（主要是sapi，例如php-fpm）。因爲php並沒有實現http網絡模塊

9、fpm如何查看worker進程的數量和狀態

在終端通過ps aux | grep php查看到。
顯示php-fpm: pool www的代表work子進程（實際處理請求）
顯示php-fpm: process master的代表master主進程（負責管理work子進程）

10、fpm啓動配置

worker進程數的設置
監聽的端口
堅挺的socket
具體可以參考這一篇