php後端研發一面面經,後端開發面經

本文目錄一覽：

• 1、php後端開發主要會哪些技術
• 2、php後端開發主要有哪些要學習的
• 3、前端開發和 後端開發（如PHP或python）的職業前景，差異如何？想自學並作為終身職業該如何選擇？
• 4、【面經】字節跳動-後端開發-2019秋招
• 5、想做程序員做後端都需要掌握哪些知識

php後端開發主要會哪些技術

後端開發首頁你要會PHP，其次你要了解PHP 框架。然後你要會HTML、CSS、JS 這個是基礎

其次你要會GIT、SVN 等代碼倉庫的使用

還有就是你要會xshell

php後端開發主要有哪些要學習的

主動學習能力 說是後台開發，但是非常有可能前台的很多工作都要懂要會用，所以需要比較強的學習能力

後台語言(php，java，asp)得用熟一樣吧 ，敞丁搬股植噶邦拴鮑莖前台的css，html，javascript也得懂

吃得苦、耐得煩、霸得蠻。

前端開發和 後端開發（如PHP或python）的職業前景，差異如何？想自學並作為終身職業該如何選擇？

個人感覺兩者任何一個都是可以做為終身職業的，不過還要結合人的本身素質和愛好來選擇哪個更好一些。

關於是學前端好還是後端開發好，我真的不敢斷言，但是根據前端和後台的特點，可以知道有些人適合前端有些人適合後台，但是這也不是絕對，而且這些特點也是我自己的一些個人見解。

1、前端開發

有些人認為前端開發無非就是寫網站的頁面，但是現在的前端開發絕對不是你想的這麼簡單，現在前端開發不僅僅是頁面，還有有些深層次的網站交互，甚至前端頁面也需要web性能。另外現在很火的移動端網站開發，需要精通html5+css3等技術，更甚者前端還有做webapp的也就是使用前端的技術來開發手機應用，做安卓和ios做的事，這就使得前端也需要編程。

總的來說學習前端技術需要的是要不斷的學習新的技術，因為其技術更新遠遠要比純編程語言快，另外是前端設計的知識面比較寬，需要學各種知識、框架等，而且前端職位很有發展前景。

2、後台開發

後台開發技術現在一般是比較成熟的，如jsp、php等都是使用的很長時間沒有太大變動的技術了，相對於前端開發來講，如果是自學或者是沒有基礎，這些語言入門可能是有難度的，入門門檻高但是就業也卻不是很好，因為這種成熟的技術初級或者中級的開發人員基本已經飽和，試想一般大學的計算機不就是學Java、jsp等技術嘛，所以這些後台語言如果不精通工作是不太容易的，但是要想精通確實需要智力和毅力的同時作用。

總結：無論是前端開始後台，學習都是需要好好學習，只要到一定的水平都是可以的作為終身的職業的，前端相對於後台的優勢就是入門門檻低，前期就業好一些，但是如果以後不深入學習同樣也是不行的，後台作為成熟的技術是需要精通的，否則是不好找工作的，就業前景，個人感覺還是差不多的，還是要看個人的愛好的和努力，技術沒有止境，只要達到普通人達不到的境界都是有前景。

【面經】字節跳動-後端開發-2019秋招

因為每個人的理解不太一樣，所以我在這裡就不給出所謂的答案了，大家可以根據自己的理解加以描述，我只在一些地方做出一些提示。有的問題已經忘了，大概也就這些了。

線程用於小任務，而進程用於更多的’重量級’的任務- 應用基本執行。 一個線程和進程之間的另一個區別是，在同一進程中的線程共享相同的地址空間，而不同的進程沒有。 因此線程可以讀寫同樣的數據結構和變量，便於線程之間的通信。 

定義方面：進程是程序在某個數據集合上的一次運行活動；線程是進程中的一個執行路徑。

進程間的通信主要是指多個進程間的數據交互。

同步主要指維護多個進程或者線程之間數據的準確性和一致性。

進程通信方式：管道（Pipe）、信號（signal）、信號量（semophere）、消息隊列（message queue）、共享內存（shared memory）、套接字（socket）。

同步方式：將線程串行化（wait notify方法來睡眠和喚醒線程）、互斥鎖（加鎖 mutex）、管程、臨界區、信號量

TCP的優點： 可靠，穩定。TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開連接用來節約系統資源。TCP的邏輯通信信道是全雙工的可靠信道。 

TCP的缺點： 慢，效率低，佔用系統資源高，易被攻擊 TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接，事實上，每個連接都會佔用系統的CPU、內存等硬件資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。

UDP的優點： 快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……

UDP的缺點： 不可靠，不穩定。因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。

面向數據報： 不能夠靈活的控制讀寫數據的次數和數量，應用層交給UDP多長的報文, UDP原樣發送, 既不會拆分, 也不會合併。但是不會存在粘包的問題。

三次握手：為了保證接收方和發送方的接收能力和發送能力都正常。

四次揮手：為了釋放全雙工的信道。所以是單獨釋放和確認的。

這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方是否現在關閉發送數據通道，需要上層應用來決定，因此，己方ACK和FIN一般都會分開發送。

TCP通過序列號、確認應答、超時重傳、擁塞控制來保證傳輸的可靠性

確認應答機制序列號

TCP將每個字節的數據都進行了編號，即為序列號。

每一個ACK都帶有對應的確認序列號，意思是告訴發送者，我已經收到了哪些數據;；下一次你從哪裡開始發。

超時重傳序列號

主機A發送數據給B之後, 可能因為網絡擁堵等原因, 數據無法到達主機B; 如果主機A在一個特定時間間隔內沒有收到B發來的確認應答, 就會進行重發；主機A未收到B發來的確認應答，也可能是因為ACK丟失了，因此主機B會收到很多重複數據，這時候利用序列號可以使得主機B來實現數據報文的去重。

擁塞控制

每次發送數據包的時候, 將擁塞窗口和接收端主機反饋的窗口大小做比較, 取較小的值作為實際發送的窗口。

擁塞控制, 歸根結底是TCP協議想儘可能快的把數據傳輸給對方, 但是又要避免給網絡造成太大壓力的折中方案。

TCP通過滑動窗口、流量控制、延遲應答、捎帶應答來提升傳輸的效率

滑動窗口機制

1. 窗口大小指的是無需等待確認應答而可以繼續發送數據的最大值.

2. 發送窗口內字段的時候, 不需要等待任何ACK, 直接發送;

3. 收到第一個ACK後, 滑動窗口向後移動, 繼續發送下一個窗口字段的數據; 依次類推;

4. 操作系統內核為了維護這個滑動窗口, 需要開闢發送緩衝區來記錄當前還有哪些數據沒有應答; 只有確認應答過的數據, 才能從緩衝區刪掉;

5. 窗口越大, 則網絡的吞吐率就越高

流量控制

接收端處理數據的速度是有限的. 如果發送端發的太快, 導致接收端的緩衝區被打滿, 這個時候如果發送端繼續發送, 就會造成丟包, 繼而引起丟包重傳等等一系列連鎖反應。

1.接收端將自己可以接收的緩衝區大小放入TCP首部中的 “窗口大小” 字段, 通過ACK端通知發送端;

2.窗口大小字段越大, 說明網絡的吞吐量越⾼高;

3.接收端一旦發現自己的緩衝區快滿了, 就會將窗口大小設置成一個更小的值通知給發送端;

4.發送端接受到這個窗口之後, 就會減慢自己的發送速度;

5.如果接收端緩衝區滿了, 就會將窗口置為0; 這時發送⽅方不再發送數據, 但是需要定期發送一個窗口

延遲應答

如果接收數據的主機立刻返回ACK應答, 這時候返回的窗口可能比較小.

窗口越大, 網絡吞吐量就越大, 傳輸效率就越高. 我們的目標是在保證網絡不擁塞的情況下盡量提高傳輸效率;

捎帶應答

在延遲應答的基礎上, 我們發現, 很多情況下, 客戶端服務器在應用層也是 “一發一收” 的.

那麼客戶端在發送數據的同時，攜帶對方消息的報文序列號，來順帶通知對方，自己所接收到的報文情況

TCP擁塞控制主要有四種方法,滑動窗口機制、慢啟動機制、擁塞避免機制、快速重傳與恢復。

滑動窗口機制

在發送數據的時候，將發送窗口內的數據全部發送，才會停下來等待ACK，如果接收到對方的ACK信息，則滑動窗口前移。

慢啟動機制

在剛開始發送數據的時候，發送窗口取一個較小的值，來防止網絡擁塞，同時探測對方的接收能力。如果收到了對方的ACK回應，則按照對方要求的窗口大小來調整發送窗口，否則進行窗口的擴大。窗口大小一開始是1，之後進行指數級別擴大，其中ssthresh為估算的一個發送窗口閾值，當窗口大小超過這個閾值，則之後的窗口每次擴大1，不再是指數級別的擴大。

還有一個概念是 AIMD（加法增大乘法減小）：無論在慢啟動階段還是在擁塞控制階段，只要網絡出現超時，就是將發送端的擁塞窗口（cwnd）置為1，ssthresh置為cwnd的一半，然後開始執行慢啟動算法；當網絡頻發出現超時情況時，ssthresh就下降的很快，為了減少注入到網絡當中的分組數，而加法增大是執行擁塞避免算法後，使擁塞窗口緩慢的增大，以防止網絡過早出現擁塞。

快速重傳

快重傳算法要求首先接收方收到一個失序的報文段後立刻發出重複確認，而不要等待自己發送數據時才進行捎帶確認。當發送方收到ACK之後，進行相應的報文重傳。

快速恢復

當發送方連續收到三個重複確認時（代表丟了三個包），執行“乘法減小”算法，慢啟動門限減半，從而預防網絡發生阻塞。由於發送方現在認為網絡很可能沒有發生阻塞（因為沒有超時），因此現在不執行慢啟動算法，而是把擁塞窗口（cwnd）值設置為慢啟動門限減半後的值，然後開始執行擁塞避免算法，擁塞窗口cwnd值線性增大

TCP和UDP是傳輸層協議（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層）

UDP沒有擁塞解決措施，當網絡擁塞時，直接丟掉UDP的包。解決方式：在傳輸層之上，利用UDP並改造：如 RUDP(傳輸層)、RTP(應用層和傳輸層之間)、UDT(應用層)等

先把兩個鏈表按照奇偶性分成兩個鏈表（偶數構造成雙向鏈表）；然後一個鏈表從頭部開始，另一個鏈表從尾部開始，插入第一個鏈表即可。

創建一個class，利用雙向鏈表構造這個雙向隊列，實現 getHead() getTail() addToHead() addToTail() popHead() popTail()

假設二維矩陣 g，查找的數為 t

先往右找（二分查找），找到 g[0][i]=a t g[0][i+1]=b，（所有行的 i+1, … 的列的元素肯定全部小於 t，可以忽略），然後從 i 往下找（二分查找），找到 g[j][i] = c t g[j+1][i] = d，（說明 0~j 行的 0~i 列均大於 t，可以忽略），然後繼續往左找，再往下找，左下不斷交替，最終即可判斷是否存在 t

翻轉鏈表：三個指針解決。p c n 分別記錄 前一個節點，當前節點，後一個節點

初始化：前一個節點 p = NULL，當前節點 c = head，後一個節點 n = head.next；

運行：c.next = p; p = n.next ; n.next = c; c = p ; p = n; n = c.next; 注意判斷是不是null

結束：while(n != null)

redis有五種數據類型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

String（字符串）

string 是 redis 最基本的類型，你可以理解成與 Memcached 一模一樣的類型，一個 key 對應一個 value。

string 類型是二進制安全的。意思是 redis 的 string 可以包含任何數據。比如jpg圖片或者序列化的對象。

string 類型是 Redis 最基本的數據類型，string 類型的值最大能存儲 512MB。

常用命令：set、get、decr、incr、mget等。

注意：一個鍵最大能存儲512MB。

Hash（哈希）

Redis hash 是一個鍵值(key→value)對集合；是一個 string 類型的 field 和 value 的映射表，hash 特別適合用於存儲對象。

每個 hash 可以存儲 2^32 -1 鍵值對（40多億）。

常用命令：hget、hset、hgetall等。

應用場景：存儲一些結構化的數據，比如用戶的昵稱、年齡、性別、積分等，存儲一個用戶信息對象數據。

List（列表）

Redis 列表是簡單的字符串列表，按照插入順序排序。你可以添加一個元素到列表的頭部（左邊）或者尾部（右邊）。

list類型經常會被用於消息隊列的服務，以完成多程序之間的消息交換。

常用命令：lpush、rpush、lpop、rpop、lrange等。

列表最多可存儲 2^32 – 1 元素 (4294967295, 每個列表可存儲40多億)。

Set（集合）

Redis的Set是string類型的無序集合。和列表一樣，在執行插入和刪除和判斷是否存在某元素時，效率是很高的。集合最大的優勢在於可以進行交集並集差集操作。Set可包含的最大元素數量是4294967295。

集合是通過哈希表實現的，所以添加，刪除，查找的複雜度都是O(1)。

應用場景：

1、利用交集求共同好友

2、利用唯一性，可以統計訪問網站的所有獨立IP。

3、好友推薦的時候根據tag求交集，大於某個threshold（臨界值的）就可以推薦。

常用命令：sadd、spop、smembers、sunion, srem, srange, sinter等。

集合中最大的成員數為 232 – 1(4294967295, 每個集合可存儲40多億個成員)。

zset(sorted set：有序集合)

Redis zset 和 set 一樣也是string類型元素的集合,且不允許重複的成員。

不同的是每個元素都會關聯一個double類型的分數。redis正是通過分數來為集合中的成員進行從小到大的排序。

zset的成員是唯一的,但分數(score)卻可以重複。

sorted set是插入有序的，即自動排序。

常用命令：zadd、zrange、zrem、zcard等。

當你需要一個有序的並且不重複的集合列表時，那麼可以選擇sorted set數據結構。

應用舉例：

（1）例如存儲全班同學的成績，其集合value可以是同學的學號，而score就可以是成績。

（2）排行榜應用，根據得分列出topN的用戶等。

Redis對於hash衝突，採用的是鏈地址法（其他的解決衝突的方法是再哈希和開放地址（線性探測和二次探測））

Redis為了控制哈希表佔用內存的大小，採用雙哈希表結構，並逐步擴大哈希表容量的策略。

Redis存儲一個對象時，首先使用 zipmap又稱為small hash存儲。這樣會節省很多哈希自身所需要的元數據的存儲開銷。當域字段field的數量超過限制範圍，或者字段值value的長度大小超過系統限定的字節數，此時Redis將該zipmap轉化為正常的hash進行存儲。

參考   源碼分析：

結構

但是在 dict 擴容縮容時，需要分配新的 hashtable，然後進行漸進式搬遷，這時候兩個 hashtable 存儲的分別是舊的 hashtable 和新的 hashtable。待搬遷結束後，舊的 hashtable 被刪除，新的 hashtable 取而代之。

rehash

擴容：當 hash 表中元素的個數（即第一個hash表的used）等於第一維數組的長度（即第一個hash表的size）時，就會開始擴容，擴容的新數組是原數組大小的 2 倍。不過如果 Redis 正在做 bgsave，為了減少內存頁的過多分離 (Copy On Write)，Redis 盡量不去擴容 (dict_can_resize 標誌是否能夠擴容)，但是如果 hash 表已經非常滿了，元素的個數已經達到了第一維數組長度的 5 倍 (dict_force_resize_ratio)，說明 hash 表已經過於擁擠了，這個時候就會強制擴容。

縮容：當 hash 表因為元素的逐漸刪除變得越來越稀疏時，，Redis 會對 hash 表進行縮容來減少 hash 表的第一維數組空間佔用。縮容的條件是元素個數低於數組長度的 10%。縮容不會考慮 Redis 是否正在做 bgsave。

收縮或者擴展哈希表需要將ht[0]表中的所有鍵全部rehash到ht[1]中，但是rehash操作不是一次性、集中式完成的，而是分多次，漸進式，斷續進行的，這樣才不會對服務器性能造成影響

漸進式rehash(incremental rehashing)

漸進式rehash的關鍵：

1、字典結構dict中的一個成員rehashidx，當rehashidx為-1時表示不進行rehash，當rehashidx值為0時，表示開始進行rehash。

2、在rehash期間，每次對字典的添加（只加到 ht[1]）、刪除（ht[0] ht[1] 全部查找並刪除）、查找（先查找 ht[0]，如果未找到再查 ht[1]）、或更新操作時，都會判斷是否正在進行rehash操作，如果是，則順帶進行單步rehash（調用_dictRehashStep 函數，該函數調用 dictRehash(d, 1)），並將rehashidx+1。新添加到字典的key-val一律會被保存到ht[1]裡面，而ht[0]不再進行任何添加操作，這一措施保證了ht[0]包含的key-val對數量只增不減，並隨着rehash操作的執行而最終變成空表。

3、dictRehash(dict* d, int n) 函數每次 rehash 前進 n 步（順序訪問 n 個 ht[0].table 的非空 dictEntry），如果 dictEntry 一直為空，則訪問到 n*10 個空 dictEntry 之後，本次 rehash 結束。

4、啟動 redis 會啟動一個 cron 定時任務（定時任務默認每秒執行 server.h CONFIG_DEFAULT_HZ=10 次），每次定時任務運行 1ms 的 rehash，調用 dictRehash(d, 100)，執行100步rehash。

4、當rehash時進行完成時，將rehashidx置為-1，表示完成rehash。同時 ht[0]=ht[1]，ht[1]=Null，更換表指針。

http1.1 通過設定 Connection:keep-alive 字段來保持TCP的長連接，從而能夠在一次建立連接的情況下處理多個請求。

下一個請求需要在上一個請求的響應之後發送，因此會存在隊頭阻塞。

HTTP1.1進一步地支持在持久連接上使用管道化（pipelining）特性。管道化允許客戶端在已發送的請求收到服務端的響應之前發送下一個請求，藉此來減少等待時間提高吞吐率。但是需要響應的順序是按照請求順序進行，因此也會存在隊頭阻塞。

http2 開啟了完全的多路復用：一個連接被多個流復用。一個流表示一次請求-響應過程。

這個過程有兩個概念：流和幀。幀代表着最小的數據單位，每個幀會標識出該幀屬於哪個流，流也就是多個幀組成的數據流。

多路復用，就是在一個 TCP 連接中可以存在多條流。換句話說，也就是可以發送多個請求，對端可以通過幀中的標識知道屬於哪個請求。通過這個技術，可以避免 HTTP 舊版本中的隊頭阻塞問題，極大的提高傳輸性能。

掛掉，則一段時間之後，保活時間到期，則關閉。或者TCP等待時間結束，關閉TCP連接。或者採用應用層周期發送心跳包來檢測是否對方還在。

好處：

減少服務端連接壓力，減少佔用內存，提升連接吞吐量；

連接數的減少改善了網絡擁塞狀況，慢啟動時間減少，擁塞和丟包恢復速度更快；

避免連接頻繁創建和關閉（三次連接、四次揮手）；

四種方法

GET：獲取信息

POST：傳輸實體

PUT：上傳文件

DELETE：刪除文件

頭部信息：

Host (主機和端口號)

Connection (鏈接類型)

Upgrade-Insecure-Requests (升級為 HTTPS 請求)

User-Agent (瀏覽器名稱)

Accept (傳輸文件類型)

Referer (頁面跳轉處)

Accept-Encoding（文件編解碼格式）

Cookie （Cookie）

x-requested-with :XMLHttpRequest (是 Ajax 異步請求)

arp發出去之後，交換機會查找自己的 mac 緩存表，如果存在，則直接返回，不存在則按照 IP 選擇端口進行發送，如果不存在 IP 的端口，則廣播。之後每個路由器都有隔離廣播的作用，其也緩存了 IP 對應的端口，並向對應的端口進行發送。

java 相關

創建進程調用的是OS哪些方法？具體說說

我們聊聊JAVA吧，你了解JVM嗎？給我講講

JVM具體會在什麼時候進行垃圾回收？JMM具體說說？

垃圾回收算法具體說說？各種垃圾回收器了解嗎？什麼時候執行STOP THE WORLD？

感覺應該是總監，很高冷。

說說項目？（沒啥興趣）

我們聊聊JAVA吧，現在我要求設計一個容器，容器滿的時候生產者阻塞，容器空的時候消費者阻塞（我跟他講了一下BlockingQueue和Condition，然後用Condition來寫）

二叉樹的最大路徑。

好吧，今天就到這裡了（哈？？？）

三面面完一度覺得自己涼透了，過兩天收到offer call，然後就收到offer了。白菜價，很高興了。

總的來說，個人感覺頭條面試算法題不難（應該是給我放水了，謝謝面試官），不過絕對不能做不出來。基礎一定要牢固，一些細節問題一定要搞清楚，一般還會問一些設計問題，這種問題就要靠靈機一動了（其實主要還是看對各種原理的理解，例如說那道隊列的問題）。噢，對了，還有一件事，一面是要求自己寫測試用例運行的，所以coding一定要快准狠。

想做程序員做後端都需要掌握哪些知識

目前掌握的僅能：

1，研發（基本吧，產品總得有人來做）

2，調優（主要是Mysql調優，在符合業務需求的情況下儘可能提高TPS）

3，運維（小公司不會像大公司一樣還標配運維，通常後端兼任運維職能）

擴展下：

研發：php入行，選個好框架（推薦Yaf），然後研發過程中多注意下性能，多用php本身的函數來解決需求，php本身函數豐富，而且都是C擴展，性能非常可靠。

調優：這個我實在不知道該放到研發還是運維，所以就單獨拿出來說。因為其實對於服務器性能的調優本身兩邊都需要進行，一是研發時注意，二是各個軟件（主要是DB）的配置項。我的調優很粗暴，用阿里雲的壓力測試（耗費了公司一些錢財，罪過罪過）每次壓一分到5分鐘，然後看看瓶頸在哪裡，把配置項全部列出來，肉眼+自行判斷調整哪個參數看看能不能提升性能（233），我也會在代碼中把每個核心部分的消耗時間打入日誌，來判斷到底該進行哪裡的優化。

運維：主要分三部分，

快速部署：雖然是小公司，但是老闆有些資源，所以可以預計上線第一波的壓力不小，如果產品良好的情況下壓力只能會越來越大，所以要求如果感覺到系統有壓力後，需要快速進行橫向擴展系統，這裡我選用的Puppet，理由很簡單：老牌，使用廣泛，社區強大。

監控報警：這是運維的眼睛，我選用的zabbix，理由跟上面一樣：老牌，使用廣泛，社區強大。

日誌採集：因為是集群的原因，看日誌不方便，最開始是用nfs來收集，後來隨着日誌越來越分散，日誌越來越大，沒用多久就被我拋棄了，然後在朋友的推薦下使用ELK進行日誌採集和查看。理由只是因為沒有別的更好選擇（朋友強烈推薦這個，其他的都是沒有啥強大社區，這個看着更靠譜點）