知識點

1 . apache 與 nginx 

Nginx

1. 輕量級，採用 C 進行編寫，一樣的 web 服務，會佔用更少的內存及資源

2. 抗併發，nginx 以 epoll and kqueue 做爲開發模型，處理請求是異步非阻塞的，負載能力比 apache 高不少，而 apache 則是阻塞型的。在高併發下 nginx 能保持低資源低消耗高性能 ，而 apache 在 PHP 處理慢或者前端壓力很大的狀況下，很容易出現進程數飆升，從而拒絕服務的現象。

3. nginx 處理靜態文件好，靜態處理性能比 apache 高三倍以上

4. nginx 的設計高度模塊化，編寫模塊相對簡單

5. nginx 配置簡潔，正則配置讓不少事情變得簡單，並且改完配置能使用 -t 測試配置有沒有問題，apache 配置複雜 ，重啓的時候發現配置出錯了，會很崩潰

6. nginx 做爲負載均衡服務器，支持 7 層負載均衡

7. nginx 自己就是一個反向代理服務器，並且能夠做爲很是優秀的郵件代理服務器

8. 啓動特別容易, 而且幾乎能夠作到 7*24 不間斷運行，即便運行數個月也不須要從新啓動，還可以不間斷服務的狀況下進行軟件版本的升級

9. 社區活躍，各類高性能模塊出品迅速

Apache

1. apache 的 rewrite 比 nginx 強大，在 rewrite 頻繁的狀況下，用 apache

2. apache 發展到如今，模塊超多，基本想到的均可以找到

3. apache 更爲成熟，少 bug ，nginx 的 bug 相對較多

4. apache 超穩定

5. apache 對 PHP 支持比較簡單，nginx 須要配合其餘後端用

6. apache 在處理動態請求有優點，nginx 在這方面是雞肋，通常動態請求要 apache 去作，nginx 適合靜態和反向。

7. apache 仍然是目前的主流，擁有豐富的特性，成熟的技術和開發社區

總結

二者最核心的區別在於 apache 是同步多進程模型，一個鏈接對應一個進程，而 nginx 是異步的，多個鏈接（萬級別）能夠對應一個進程

通常來講，須要性能的 web 服務，用 nginx 。若是不須要性能只求穩定，更考慮 apache ，後者的各類功能模塊實現得比前者，例如 ssl 的模塊就比前者好，可配置項多。epoll(freebsd 上是 kqueue ) 網絡 IO 模型是 nginx 處理性能高的根本理由，但並非全部的狀況下都是 epoll 大獲全勝的，若是自己提供靜態服務的就只有寥寥幾個文件，apache 的 select 模型或許比 epoll 更高性能。固然，這只是根據網絡 IO 模型的原理做的一個假設，真正的應用仍是須要實測了再說的。

更爲通用的方案是，前端 nginx 抗併發，後端 apache 集羣，配合起來會更好。

 

2 . redis 特色及使用場景  緩存穿透 緩存雪崩 及對應解決方案

 關於redis，更多

緩存穿透

通常的緩存系統，都是按照key去緩存查詢，若是不存在對應的value，就應該去後端系統查找（好比DB）。若是key對應的value是必定不存在的，而且對該key併發請求量很大，就會對後端系統形成很大的壓力。這就叫作緩存穿透

a. 對查詢結果爲空的狀況也進行緩存，緩存時間設置短一點，或者該key對應的數據insert了以後清理緩存

b. 對必定不存在的key進行過濾。能夠把全部的可能存在的key放到一個大的Bitmap中，查詢時經過該bitmap過濾

 

緩存雪崩

當緩存服務器重啓或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(好比DB)帶來很大壓力。

a. 在緩存失效後，經過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。好比對某個key只容許一個線程查詢數據和寫緩存，其餘線程等待

b. 不一樣的key，設置不一樣的過時時間，讓緩存失效的時間點儘可能均勻

c. 作二級緩存，A1爲原始緩存，A2爲拷貝緩存，A1失效時，能夠訪問A2，A1緩存失效時間設置爲短時間，A2設置爲長期

 

緩存預熱

緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣避免，用戶請求的時候，再去加載相關的數據。

解決思路：

a. 直接寫個緩存刷新頁面，上線時手工操做下。

b. 數據量不大，能夠在WEB系統啓動的時候加載。

c. 定時刷新緩存，

緩存更新

緩存淘汰的策略有兩種：

a. 定時去清理過時的緩存。

b. 當有用戶請求過來時，再判斷這個請求所用到的緩存是否過時，過時的話就去底層系統獲得新數據並更新緩存。 

二者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較複雜，具體用哪一種方案，你們能夠根據本身的應用場景來權衡。1. 預估失效時間 2. 版本號（必須單調遞增，時間戳是最好的選擇）3. 提供手動清理緩存的接口。

 

 

3. mysql sql語句優化原則  性能優化方案 主從複製 讀寫分離 分表分庫

a. 儘可能避免在列上進行運算，這樣會致使索引失效。

b. 使用JOIN時，應該用小結果集驅動大結果集。同時把複雜的JOIN查詢拆分紅多個Query。由於JOIN多個表時，可能致使更多的鎖定和堵塞

c. 注意LIKE模糊查詢的使用，避免%%。

例如：

SELECT * FROM table WHERE name LIKE '%de%';

優化： 

SELECT * FROM table WHERE name >= 'de' AND name < 'df';  

d. 僅列出須要查詢的字段，這對速度不會有明顯的影響，主要考慮節省內存

e. 使用批量插入語句節省交互

f. LIMIT 的基數比較大時使用 BETWEEN

例如：

SELECT * FROM article ORDER BY id LIMIT 100000,10

優化：

SELECT * FROM article WHERE id BETWEEN 100000 AND 100010 ORDER BY id;

BETWEEN 限定比 LIMIT 快，因此在海量數據訪問時，建議用 BETWEEN 或是 WHERE 替換掉 LIMIT 。可是 BETWEEN 也有缺陷，若是 id 中間有斷行或是部分 id 不讀取的狀況，總讀取的數量會少於預計數量！ 在讀取比較後面的數據時，經過 DESC 方式把數據反向查找，以減小對前端數據的掃描，讓 LIMIT 的基數越少越好！

g. 不要使用 RAND 函數獲取多條隨機記錄

例如：

SELECT * FROM table ORDER BY RAND() LIMIT 20;

使用下面的語句代替：

SELECT * FROM table AS t1
JOIN (
　　SELECT ROUND(RAND() * ((SELECT MAX(id) FROM table) - (SELECT MIN(id) FROM table)) + (SELECT MIN(id) FROM table)) AS id
) AS t2
WHERE t1.id >= t2.id ORDER BY t1.id LIMIT 1;

這是獲取一條隨機記錄，這樣即便執行 20 次，也比原來的語句高效。或者先用PHP產生隨機數，把這個字符串傳給MySQL，MySQL裏用IN查詢。

h. 避免使用NULL

i. 不要使用 COUNT(id) ，而應該是 COUNT(*)

j. 不要作無謂的排序操做，而應儘量在索引中完成排序。

 

 

4. session 與 cookie 

cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

cookie不是很安全，別人能夠分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session。

session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie。

單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

能夠考慮將登錄信息等重要信息存放爲session，其餘信息若是須要保留，能夠放在cookie中。

 

5. php新特性

 php7新特性

6. php應用的完成請求過程

在瀏覽器中輸入一個http地址，如：http://localhost/
——>瀏覽器會請求DNS服務器，獲取到對應的IP地址
——>經過IP地址找對應的服務器（如：Apache服務器）
——>服務器接到請求，解析Url字符，獲得URL中IP地址後的文件路徑名
——>1.在服務器的web目錄下查找是否有對應html、css、xml文件，若是有直接返回給瀏覽器，瀏覽器顯示解析返回的數據並顯示
——>2.若是請求的php方件，如http://localhost/info.php的話，由於Apache處理不了，會將這個轉給PHP程序處理而後PHP將處理結果以html的形式返回給Apache，Apache再返回給瀏覽器。

因此，在安裝Apache與PHP時，須要將Apache與PHP關聯起來，當Apache遇到是請求php文件時，將其轉給php程序處理

7. 魔術方法

__construct()構造方法

執行時機：在使用 new關鍵字使用類實例化一個對象時自動執行

功能做用：一般用於對對象的屬性進行初始化

 

__destruct()析構方法

執行時機：在對象被銷燬（unset或PHP執行結束）時自動執行

功能做用：一般用於釋放對象佔用的第三方資源（如：數據庫）

 

__toString()轉換字符串

執行時機：在對象被當成字符串使用時自動執行

功能做用：兼容對象的字符串調用形式，根據用戶需求顯示出對象的字符串形態

 

__invoke()函數調用方法

執行時機：在對象被當成函數使用時自動執行

功能做用：兼容對象的函數調用形式，容許用戶像使用函數同樣使用對象

 

__clone()克隆方法

執行時機：在克隆（clone）對象時自動執行

功能做用：在克隆對象時能夠同時執行一些其它操做，甚至能夠阻止對象被克隆

 

__call()   

魔術方法__call()在調用不存在或不可訪問的方法時會被調用。

它接收兩個參數，一個是調用的方法的名字，一個是包含函數參數的數組。咱們可使用這種方法調用子對象中得同名函數

 

__callStatic()

魔術方法__callStatic()與__call()的功能同樣，惟一不一樣的是，該方法在嘗試訪問一個不存在或不可訪問的靜態方法時會被調用

 

__set()

__set()魔術方法在咱們嘗試修改一個不可訪問的屬性時會被調用，它接收兩個參數，一個表示屬性的名字，一個表示屬性的值

 

__isset()

__isset()魔術方法在對一個不可訪問的屬性調用isset()方法時會被調用，它接收一個參數，表示屬性的名字。它應該返回一個布爾值，用來表示該屬性是否存在

8. php生命週期

咱們從未手動開啓過PHP的相關進程，它是隨着Apache的啓動而運行的；

PHP經過mod_php5.so模塊和Apache相連（具體說來是SAPI，即服務器應用程序編程接口）；

PHP總共有三個模塊：內核、Zend引擎、以及擴展層；

PHP內核用來處理請求、文件流、錯誤處理等相關操做；

Zend引擎（ZE）用以將源文件轉換成機器語言，而後在虛擬機上運行它；

擴展層是一組函數、類庫和流，PHP使用它們來執行一些特定的操做。好比，咱們須要mysql擴展來鏈接MySQL數據庫；

當ZE執行程序時可能會須要鏈接若干擴展，這時ZE將控制權交給擴展，等處理完特定任務後再返還；

最後，ZE將程序運行結果返回給PHP內核，它再將結果傳送給SAPI層，最終輸出到瀏覽器上。

Apache啓動，PHP解釋程序也隨之啓動，PHP經過SAPI（服務器應用程序編程接口）和Apache相連。PHP的啓動首先是PHP調用各個拓展MINT方法，使這些拓展切換到可用狀態，也就是初始化一些環境變量，做用於整個SAPI生命週期。而後當一個頁面請求發生時SAPI層將控制權交給PHP層，因而PHP設置了用於回覆本次請求的環境變量，同時他還產生了一個變量表，用於存放執行過程當中產生的變量名和值，PHP調用各個模塊的RINT方法，RINIT方法能夠看做是一個準備過程，在程序執行時就會自動啓動。一旦頁面執行完畢，PHP就會啓動清理程序。它會按順序調用各個模塊的RSHUTDOWN方法，RSHUTDOWN用以清除程序運行時產生的符號表，也就是對每一個變量調用unset函數，最後，全部的請求都已處理完畢，SAPI也準備關閉了，PHP調用每一個擴展的MSHUTDOWN方法，這是各個模塊最後一次釋放內存的機會。

請求-->DNS服務器-->Apache-->SAPI-->PHP內核-->zend引擎-->PHP內核-->SAPI-->Apache-->瀏覽器

 

 更多

9. 事務的使用及使用場景

10. mvc

mvc分爲了三個層次，並且三個層次各司其職，互不干擾，首先簡單介紹下，各個層次，view便是視圖，也就是web頁面，control便是控制器 向系統發出指令的工具，model 簡單說是從數據庫中取出數據進行處理。

Mvc的工做流程：第一步 瀏覽者->調用控制器，對此發出指令

第二步 控制器->按指令選取一個合適的模型

第三步 模型->按照控制器指令選取相應的數據

第四步 控制器->按指令選取相應的視圖

第五步 視圖->把第三步取到的數據按用戶想要的樣子顯示出來

11. 開發調試

 PHP調試方式

12. linux 命令 文本查看 文本處理  head tail  awk sed   |   crontab

head 

head命令的做用就像它的名字同樣，用於顯示文件的開頭部分文本。

head -n 100 file #顯示file的前100行
head -n -100 file #顯示file的除最後100行之外的內容。

tail

tail命令顯示文件尾部的內容

tail -100 file  #顯示file最後100行內容
tail -n +100 file  #從第100行開始顯示file內容

用於實時文本更新內容。好比說，有一個日誌文件正在寫，而且實時在更新，就能夠用命令：

tail -f note.log

awk

awk 「樣式」 文件： 把符合樣式的數據行顯示出來。
awk { 操做 } 文件： 對每一行都執行{}中的操做。
awk " 樣式 { 操做 }" 文件： 對符合樣式的數據行，執行{}中的操做

# 每行按空格或TAB分割，輸出文本中的一、4項
awk '{print $1,$4}' log.txt

 

 

sed

sed是一個很好的文件處理工具，自己是一個管道命令，主要是以行爲單位進行處理，能夠將數據行進行替換、刪除、新增、選取等特定工做，下面先了解一下sed的用法
sed命令行格式爲：

sed [-nefri] ‘command’ 輸入文本        

查看 必定時間段的 文件內容

sed -n '/2018-12-20T19:15:00+08:00/,/2018-12-20T19:15:28+08:00/p'   20.log

 sed和awk

 

13. 阻塞 非阻塞 異步 同步

同步：
所謂同步，就是在發出一個功能調用時，在沒有獲得結果以前，該調用就不返回。也就是必須一件一件事作,等前一件作完了才能作下一件事。
例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能幹任何事
異步：
異步的概念和同步相對。當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。
例如
ajax請求（異步）: 請求經過事件觸發->服務器處理（這是瀏覽器仍然能夠做其餘事情）->處理完畢
阻塞
阻塞調用是指調用結果返回以前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在獲得結果以後纔會返回。
有人也許會把阻塞調用和同步調用等同起來，實際上他是不一樣的。對於同步調用來講，不少時候當前線程仍是激活的，只是從邏輯上當前函數沒有返回而已。 例如，咱們在socket中調用recv函數，若是緩衝區中沒有數據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各類各樣的消息。
非阻塞
非阻塞和阻塞的概念相對應，指在不能馬上獲得結果以前，該函數不會阻塞當前線程，而會馬上返回。
對象的阻塞模式和阻塞函數調用
對象是否處於阻塞模式和函數是否是阻塞調用有很強的相關性，可是並非一一對應的。阻塞對象上能夠有非阻塞的調用方式，咱們能夠經過必定的API去輪詢狀 態，在適當的時候調用阻塞函數，就能夠避免阻塞。而對於非阻塞對象，調用特殊的函數也能夠進入阻塞調用。函數select就是這樣的一個例子。
1. 同步，就是我調用一個功能，該功能沒有結束前，我死等結果。
2. 異步，就是我調用一個功能，不須要知道該功能結果，該功能有結果後通知我（回調通知）
3. 阻塞， 就是調用我（函數），我（函數）沒有接收完數據或者沒有獲得結果以前，我不會返回。
4. 非阻塞， 就是調用我（函數），我（函數）當即返回，經過select通知調用者
同步IO和異步IO的區別就在於：數據拷貝的時候進程是否阻塞！
阻塞IO和非阻塞IO的區別就在於：應用程序的調用是否當即返回！
對於舉個簡單c/s 模式：
同步：提交請求->等待服務器處理->處理完畢返回這個期間客戶端瀏覽器不能幹任何事
異步：請求經過事件觸發->服務器處理（這是瀏覽器仍然能夠做其餘事情）->處理完畢
同步和異步都只針對於本機SOCKET而言的。
同步和異步,阻塞和非阻塞,有些混用,其實它們徹底不是一回事,並且它們修飾的對象也不相同。
阻塞和非阻塞是指當進程訪問的數據若是還沒有就緒,進程是否須要等待,簡單說這至關於函數內部的實現區別,也就是未就緒時是直接返回仍是等待就緒;
而同步和異步是指訪問數據的機制,同步通常指主動請求並等待I/O操做完畢的方式,當數據就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數據後即可以繼續處理其它任務,隨後等待I/O,操做完畢的通知,這可使進程在數據讀寫時也不阻塞。(等待"通知")

 進程線程

14. git 衝突解決

保留本地的修改 的改法

1）直接commit本地的修改 ----也通常不用這種方法

2）經過git stash  ---- 一般用這種方法

git stash

git pull

git stash pop

經過git stash將工做區恢復到上次提交的內容，同時備份本地所作的修改，以後就能夠正常git pull了，git pull完成後，執行git stash pop將以前本地作的修改應用到當前工做區。

git stash: 備份當前的工做區的內容，從最近的一次提交中讀取相關內容，讓工做區保證和上次提交的內容一致。同時，將當前的工做區內容保存到Git棧中。

git stash pop: 從Git棧中讀取最近一次保存的內容，恢復工做區的相關內容。因爲可能存在多個Stash的內容，因此用棧來管理，pop會從最近的一個stash中讀取內容並恢復。

git stash list: 顯示Git棧內的全部備份，能夠利用這個列表來決定從那個地方恢復。

git stash clear: 清空Git棧。此時使用gitg等圖形化工具會發現，原來stash的哪些節點都消失了。

放棄本地修改 的改法  ----這種方法會丟棄本地修改的代碼，並且不可找回

git reset --hard

git pull<br><br><br><br><br><br>

15.swoole簡介

 swoole &&官方文檔

16.xss csrf 說明與防護

 WEB安全----XSS和CSRF

17. HTTP  HTTPS  TCP  IP   ‘三次握手四次揮手’

HTTP  （Hyper Text Transfer Protocol）  超文本傳輸協議，創建在TCP上的無狀態鏈接，HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另外一端收到發端發出的全部包，而且順序與發出順序一致。TCP有可靠，面向鏈接的特色。

 

HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）

HTTP（80）協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以，HTTP協議不適合傳輸一些敏感信息，好比：信用卡號、密碼等支付信息。爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS（443），爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。

 

所謂三次握手（Three-Way Handshake）即創建TCP鏈接，是指創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程以下圖所示：

（1）第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

（2）第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack (number )=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

（3）第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

 

四次揮手（Four-Way Wavehand）即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程以下圖所示：

 

因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉，上圖描述的便是如此。

（1）第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

（2）第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

（3）第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

 

上面是一方主動關閉，另外一方被動關閉的狀況，實際中還會出現同時發起主動關閉的狀況，具體流程以下圖：

 HTTP更多