No.0

算法類

1.快速排序算法 
2.樹的非遞歸後序排序算法 
3.希爾排序 
4.冒泡排序 
5.鏈表和鏈表轉向 
6.其餘

 

設計模式

1.單例模式 
2.工廠模式 
3.抽象工廠模式 
4.面向對象設計，ooa，ood，oop

 

PHP

1.PHP FastCGI 
2.php-fpm

web server（好比說nginx）只是內容的分發者。好比，若是請求/index.html，那麼web server會去文件系統中找到這個文件，發送給瀏覽器，這裏分發的是靜態數據。好了，若是如今請求的是/index.php，
根據配置文件，nginx知道這個不是靜態文件，須要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些數據給PHP解析器呢？url要有吧，查詢字符串也得有吧，POST數據也要有，
HTTP header不能少吧，好的，CGI就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。仔細想一想，你在PHP代碼中使用的用戶從哪裏來的。
當web server收到/index.php這個請求後，會啓動對應的CGI程序，這裏就是PHP的解析器。接下來PHP解析器會解析php.ini文件，初始化執行環境，而後處理請求，再以規定CGI規定的格式返回處理後的結果，退出進程。
web server再把結果返回給瀏覽器。 提升性能，那麼CGI程序的性能問題在哪呢？"PHP解析器會解析php.ini文件，初始化執行環境"，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理每一個時間的時間會比較長。
這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，而後當即能夠接受下一個請求。
這樣就避免了重複的勞動，效率天然是高。並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。 你們都知道，PHP的解釋器是php-cgi。php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離
出來的spawn-fcgi。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。

3.數組或字符串函數 
4.php命令行命令

php -l linux在當前目錄檢測php語法錯誤
php –v查看當前php的版本
php -m 會顯示當前php加載的有效模塊 php -i 則輸出無html格式的phpinfo php -S localhost:80 php5.4以後提供測試服務器

5.file_get_content和fread區別

fread() 最大一次性能讀取8k長度的字節數，因此不能一次性讀取大文件去做下載。 優點在於，操做更加靈活，每次讀取指定字節的內容，用於下載時方便控制服務器的流量。
file_get_contents() 函數把整個文件讀入一個字符串中。 與 函數file()不一樣的是 file_get_contents() 把文件讀入一個字符串，而file()把整個文件讀入一個數組中。
file_get_contents() 函數是用於將文件的內容讀入到一個字符串中的首選方法。若是操做系統支持，還會使用內存映射技術來加強性能。在讀取小文本內容到字符串變量時，這個函數最適合使用，簡單，更快。

 

6.比較兩個文件中url的不一樣，而後問執行速度，文件大於300G

能夠估計每一個文件的大小爲5G*64=300G，遠大於4G。因此不可能將其徹底加載到內存中處理。考慮採起分而治之的方法。遍歷文件a，對每一個url求取hash(url)%1000，而後根據所得值將url分別存儲到1000個小文件（設爲a0,a1,...a999）當中。
這樣每一個小文件的大小約爲300M。遍歷文件b，採起和a相同的方法將url分別存儲到1000個小文件(b0,b1....b999)中。這樣處理後，全部可能相同的url都在對應的小文件(a0 vs b0, a1 vs b1....a999 vs b999)當中，不對應的小文件（好比a0 vs b99）
不可能有相同的url。而後咱們只要求出1000對小文件中相同的url便可。 好比對於a0 vs b0，咱們能夠遍歷a0，將其中的url存儲到hash_map當中。而後遍歷b0，若是url在hash_map中，則說明此url在a和b中同時存在，保存到文件中便可。若是分紅的小文件
不均勻，致使有些小文件太大（好比大於2G），能夠考慮將這些太大的小文件再按相似的方法分紅小小文件便可。

 

7.for與foreach那個更快 
8.是否讀過源碼 
9.PHP7的新特徵 
10.PHP-FPM的進程控制方式

php-fpm進程管理的三種模式：
一、`ondemand`，在php-fpm啓動的時候，不會給這個pool啓動任何一個worker，是按需啓動，當有鏈接過來纔會啓動。 優勢：按流量需求建立，不浪費系統資源（在硬件如此便宜的時代，這個優勢略顯雞肋） 缺點：因爲php-fpm是短鏈接的，因此每次請求都會先創建鏈接，創建鏈接的過程必然會觸發上圖的執行步驟，因此，在大流量的系統上master進程會變得繁忙，佔用系統cpu資源，不適合大流量環境的部署 二、`dynamic`，在php-fpm啓動時，會初始啓動一些worker，在運行過程當中動態調整worker數量，worker的數量受限於pm.max_children配置，同時受限全局配置process.max 優勢：動態擴容，不浪費系統資源，master進程設置的1秒定時器對系統的影響忽略不計； 缺點：若是全部worker都在工做，新的請求到來只能等待master在1秒定時器內再新建一個worker，這時可能最長等待1s； 三、`static`,php-fpm啓動採用固定大小數量的worker，在運行期間也不會擴容，雖然也有1秒的定時器，僅限於統計一些狀態信息，例如空閒worker個數，活動worker個數，網絡鏈接隊列長度等信息。

11.高併發等PHP的原理 
12.php底層實現

 

數據庫

1.設計分表（基因法） 

 
2.數據庫最左前綴原則 
3.Mysql集羣 
4.Redis的五種對象類型及其底層實現(跳躍表) 
5.MySQL雙機雙備 
6.分表，系統運行時如何修改表結構

1 建立一個和你要執行 alter 操做的表同樣的空表結構。
2 執行表結構修改，而後從原表中的數據到copy到 表結構修改後的表， 3 在原表上建立觸發器將 copy 數據的過程當中，在原表的更新操做 更新到新表. 注意:若是表中已經定義了觸發器這個工具就不能工做了。 4 copy 完成之後，用rename table 新表代替原表，默認刪除原表。

7.Redis的持久化機制

RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤(默認)。
優點：
1、一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這樣很是方便進行備份。好比你可能打算沒1天歸檔一些數據。 方便備份，咱們能夠很容易的將一個一個RDB文件移動到其餘的存儲介質上 2、RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。 三、RDB 能夠最大化 Redis 的性能：父進程在保存 RDB 文件時惟一要作的就是 fork 出一個子進程，而後這個子進程就會處理接下來的全部保存工做，父進程無須執行任何磁盤 I/O 操做。 劣勢： 一、若是你須要儘可能避免在服務器故障時丟失數據，那麼 RDB 不適合你。 雖然 Redis 容許你設置不一樣的保存點（save point）來控制保存 RDB 文件的頻率， 可是， 由於RDB 文件須要保存整個數據集的狀態， 因此它並非一個輕鬆的操做。
 所以你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種狀況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。 2、每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工做。 在數據集比較龐大時， fork() 可能會很是耗時，形成服務器在某某毫秒內中止處理客戶端； 若是數據集很是巨大，而且 CPU 時間很是緊張
的話，那麼這種中止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也須要進行 fork() ，但不管 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失。 AOF，redis會將每個收到的寫命令都經過write函數追加到文件中(默認是 appendonly.aof)。 優點 1、使用 AOF 持久化會讓 Redis 變得很是耐久（much more durable）：你能夠設置不一樣的 fsync 策略，好比無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，
Redis 仍然能夠保持良好的性能，而且就算髮生故障停機，也最多隻會丟失一秒鐘的數據（ fsync 會在後臺線程執行，因此主線程能夠繼續努力地處理命令請求）。 二、AOF 文件是一個只進行追加操做的日誌文件（append only log）， 所以對 AOF 文件的寫入不須要進行 seek ， 即便日誌由於某些緣由而包含了未寫入完整的命令（好比寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具
也能夠輕易地修復這種問題。 3、Redis 能夠在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操做是絕對安全的，由於 Redis 在建立新 AOF 文件的過程當中，會繼續將命令追加到現
有的 AOF 文件裏面，即便重寫過程當中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件建立完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操做。 3、AOF 文件有序地保存了對數據庫執行的全部寫入操做， 這些寫入操做以 Redis 協議的格式保存， 所以 AOF 文件的內容很是容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也很是簡單： 舉個例子， 若是你
不當心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要中止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就能夠將數據集恢復到 FLUSHALL 執行以前的狀態。 劣勢 1、對於相同的數據集來講，AOF 文件的體積一般要大於 RDB 文件的體積。 2、根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在通常狀況下， 每秒 fsync 的性能依然很是高， 而關閉 fsync 可讓 AOF 的速度和 RDB 同樣快， 即便在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 能夠提供
更有保證的最大延遲時間（latency）。 三、AOF 在過去曾經發生過這樣的 bug ： 由於個別命令的緣由，致使 AOF 文件在從新載入時，沒法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引發過這樣的 bug 。） 測試套件裏爲這種狀況添加了測試： 它們會
自動生成隨機的、複雜的數據集， 並經過從新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中並不常見， 可是對比來講， RDB 幾乎是不可能出現這種 bug 的。

8.數據庫中事務的四大特性

原子性（全部操做要麼所有成功，要麼所有失敗回滾）
一致性 (一個事務執行以前和執行以後都必須處於一致性狀態)
隔離性 (隔離性是當多個用戶併發訪問數據庫時, 多個併發事務之間要相互隔離) 持久性 (持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的，即使是在數據庫系統遇到故障的狀況下也不會丟失提交事務的操做)

9.不考慮隔離性會出現的問題

髒讀
　　髒讀是指在一個事務處理過程裏讀取了另外一個未提交的事務中的數據。
不可重複讀
　　不可重複讀是指在對於數據庫中的某個數據，一個事務範圍內屢次查詢卻返回了不一樣的數據值，這是因爲在查詢間隔，被另外一個事務修改並提交了
虛讀(幻讀)
　　幻讀是事務非獨立執行時發生的一種現象。例如事務T1對一個表中全部的行的某個數據項作了從「1」修改成「2」的操做，這時事務T2又對這個表中插入了一行數據項，而這個數據項的數值仍是爲「1」而且提交給數據庫。
　　而操做事務T1的用戶若是再查看剛剛修改的數據，會發現還有一行沒有修改，其實這行是從事務T2中添加的，就好像產生幻覺同樣，這就是發生了幻讀。

 

10.MySQL數據庫爲咱們提供的四種隔離級別

Serializable (串行化)：可避免髒讀、不可重複讀、幻讀的發生。（鎖表）
Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。
Read committed (讀已提交)：可避免髒讀的發生。（一個事務只能看見已經提交事務所作的改變）
Read uncommitted (讀未提交)：最低級別，任何狀況都沒法保證。（髒讀）
在MySQL數據庫中默認的隔離級別爲Repeatable read (可重複讀)
可重複讀隔離級別是最嚴格的隔離級別。在該隔離級別下，一個事務的影響徹底與其餘併發事務隔離，髒讀、不可重複的讀、幻像讀現象都不會發生。當使用可重複讀隔離級別時，在事務執行期間會鎖定該事務以任何方式引用的全部行。
所以，若是在同一個事務中發出同一個SELECT語句兩次或更屢次，那麼產生的結果數據集老是相同的。所以，使用可重複讀隔離級別的事務能夠屢次檢索同一行集，並對它們執行任意操做，直到提交或回滾操做終止該事務。可是，在事務
存在期間，不容許其餘事務執行會影響這個事務正在訪問的任何行的插入、更新或刪除操做。爲了確保這種行爲不會發生，鎖定該事務所引用的每一行-- 而不是僅鎖定被實際檢索或修改的那些行。所以，若是一個事務掃描了1000行，但
只檢索10行，那麼它所掃描的1000行(而不只是被檢索的10行)都會被鎖定

 

11.快速找到MySQL語句是否命中索引（EXPLAIN）

 

其餘

1.http code

449
    出現499的緣由大致都是說服務端處理時間過長，客戶端主動關閉了鏈接；upstream_response_time和request_time過長；客戶端請求速度過快，觸發了nginx保護機制，直接返回499狀態碼；第二種狀況就是客戶端主動關閉了鏈接；證書錯誤
    解決方式：
    proxy_ignore_client_abort on;# 告訴nginx不要主動關閉鏈接
    proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; 502 502優化，php-cgi進程數不夠用、php執行時間長、或者是php-cgi進程死掉，都會出現502錯誤 a、查看當前的PHP FastCGI進程數是否夠用netstat -anpo | grep "php-cgi"| wc -l 若是實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，須要增大。 b、部分PHP程序的執行時間超過了Nginx的等待時間 fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; c、max-children和max-requests php-fpm有一個參數 max_requests，該參數指明瞭，每一個children最多處理多少個請求後便會被關閉，默認的設置是500。由於php是把請求輪詢給每一個children，在大流量下，每一個childre到達max_requests所用的時間都差很少，這樣就形成全部的
　　children基本上在同一時間被關閉。在這期間，nginx沒法將php文件轉交給php-fpm處理，因此cpu會降至很低(不用處理php，更不用執行sql)，而負載會升至很高(關閉和開啓children、nginx等待php-fpm)，網卡流量也降至很低(nginx沒法生成數據傳輸給客戶端) 增長children的數量，而且將 max_requests 設置爲0或者一個比較大的值 d、增長緩衝區容量大小 大意是nginx緩衝區有一個bug形成的,增長了緩衝區容量大小設置 e、request_terminate_timeout 若是主要是在一些post或者數據庫操做的時候出現502這種狀況，而不是在靜態頁面操做中常見，那麼能夠查看一下php-fpm.conf設置中的一項：request_terminate_timeout 這個值是max_execution_time，就是fast-cgi的執行腳本時間。 0s爲關閉，就是無限執行下去。 優化fastcgi中，還能夠改改這個值5s 看看效果。 504 錯誤通常是與nginx.conf配置有關了。主要與如下幾個參數有關：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、
fastcgi_intercept_errors。特別是前三個超時時間。若是fastcgi緩衝區過小會致使fastcgi進程被掛起從而演變爲504錯誤。 首先，談談499，它區別於500+系列，是Nginx端返回的，是客戶端（即鏈接nginx的前段客戶）主動斷開鏈接。 500 502 504 都是後臺服務錯誤致使。 500:很明顯的程序內部錯誤，很常見的出現是因爲程序的內部語法邏輯出錯致使。 502:Bad gateway!常出現的一種場景，好比咱們用nginx作代理，當upstream到後端的某一個服務，這個服務沒任何響應。nginx就會return 502的響應。 504:Gareway timeout! 表示後端的服務能接收請求，可是遲遲未能完成整個代碼邏輯，後臺服務只能主動超時斷開請求，這個時候return 504.

2.http1.0和1.1區別

一、HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理
Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持鏈接；Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉鏈接。HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。 2.HTTP 1.1增長host字段 隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機，HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。 三、100(Continue) Status(節約帶寬) 客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，就回送響應碼401（Unauthorized） 四、HTTP/1.1中引入了Chunked transfer-coding來解決上面這個問題，發送方將消息分割成若干個任意大小的數據塊，每一個數據塊在發送時都會附上塊的長度，最後用一個零長度的塊做爲消息結束的標誌。這種方法容許發送方只緩衝消息的一個片斷，避免緩衝整個消息帶來的過載。 五、HTTP/1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變爲stale對象，cache不須要直接拋棄stale對象，而是與源服務器進行從新激活（revalidation）。

3.http和https區別

1、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。 3、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。 四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。 HTTPS的工做原理： （1）客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接。 （2）Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。 （3）客戶端的瀏覽器與Web服務器開始協商SSL鏈接的安全等級，也就是信息加密的等級。 （4）客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。 （5）Web服務器利用本身的私鑰解密出會話密鑰。 （6）Web服務器利用會話密鑰加密與客戶端之間的通訊。 HTTPS的優勢： （1）使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器； （2）HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。 （3）HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。 （4）谷歌曾在2014年8月份調整搜索引擎算法，並稱「比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高」。 HTTPS的缺點： （1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增長10%到20%的耗電； （2）HTTPS鏈接緩存不如HTTP高效，會增長數據開銷和功耗，甚至已有的安全措施也會所以而受到影響； （3）SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。 （4）SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。 （5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

4.進程之間如何通訊

1無名管道( pipe )：管道是一種半雙工的通訊方式，數據只能單向流動，並且只能在具備親緣關係的進程間使用。進程的親緣關係一般是指父子進程關係。
2高級管道(popen)：將另外一個程序當作一個新的進程在當前程序進程中啓動，則它算是當前程序的子進程，這種方式咱們成爲高級管道方式。 3有名管道 (named pipe) ： 有名管道也是半雙工的通訊方式，可是它容許無親緣關係進程間的通訊。 4消息隊列( message queue ) ： 消息隊列是由消息的鏈表，存放在內核中並由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節流以及緩衝區大小受限等缺點。 5信號量( semophore ) ： 信號量是一個計數器，能夠用來控制多個進程對共享資源的訪問。它常做爲一種鎖機制，防止某進程正在訪問共享資源時，其餘進程也訪問該資源。所以，主要做爲進程間以及同一進程內不一樣線程之間的同步手段。 6信號 ( sinal ) ： 信號是一種比較複雜的通訊方式，用於通知接收進程某個事件已經發生。 7共享內存( shared memory ) ：共享內存就是映射一段能被其餘進程所訪問的內存，這段共享內存由一個進程建立，但多個進程均可以訪問。共享內存是最快的 IPC 方式，它是針對其餘進程間通訊方式運行效率低而專門設計的。它每每與其餘通訊機制，如信號兩，配合使用，來實現進程間的同步和通訊。 8套接字( socket ) ： 套解口也是一種進程間通訊機制，與其餘通訊機制不一樣的是，它可用於不一樣機器間的進程通訊。

5.消息中間件（kafka等） 
6.nginx和apache的區別

nginx相對於apache的優勢： 
輕量級，一樣起web 服務，比apache 佔用更少的內存及資源 
抗併發，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高併發下nginx 能保持低資源低消耗高性能 
Nginx自己就是一個反向代理服務器
高度模塊化的設計，編寫模塊相對簡單 
社區活躍，各類高性能模塊出品迅速啊 
apache 相對於nginx 的優勢： 
rewrite ，比nginx 的rewrite 強大 
模塊超多，基本想到的均可以找到 
少bug ，nginx 的bug 相對較多 
超穩定 
最核心的區別在於apache是同步多進程模型，一個鏈接對應一個進程；nginx是異步的，多個鏈接（萬級別）能夠對應一個進程 

7.break，last的區別 8.負載均衡的實現 9.11種運行模式 10.nginx-lua插件