服務器部分

一、Apache與Nginx的優缺點比較 
一、nginx相對於apache的優勢： 
輕量級，比apache 佔用更少的內存及資源。高度模塊化的設計，編寫模塊相對簡單 
抗併發，nginx 處理請求是異步非阻塞，多個鏈接（萬級別）能夠對應一個進程，而apache 則是阻塞型的，是同步多進程模型，一個鏈接對應一個進程，在高併發下nginx 能保持低資源低消耗高性能 

nginx處理靜態文件好，Nginx 靜態處理性能比 Apache 高 3倍以上 

二、apache 相對於nginx 的優勢： 
apache 的rewrite 比nginx 的rewrite 強大 ，模塊很是多，基本想到的均可以找到 ，比較穩定，少bug ，nginx 的bug 相對較多 

 

3：緣由：這得益於Nginx使用了最新的epoll（Linux 2.6內核）和kqueue（freebsd）網絡I/O模型，而Apache則使用的是傳統的select模型。目前Linux下可以承受高併發訪問的 Squid、Memcached都採用的是epoll網絡I/O模型。 處理大量的鏈接的讀寫，Apache所採用的select網絡I/O模型很是低效。

 

 

二、cgi 與fastcgi的區別

cgi在2000年或更早的時候用得比較多， 之前web服務器通常只處理靜態的請求，web服務器會根據此次請求的內容，而後會fork一個新進程來運行外部c程序 （或perl腳本...）， 這個進程會把處理完的數據返回給web服務器，最後web服務器把內容發送給用戶，剛纔fork的進程也隨之退出。 若是下次用戶還請求改動態腳本，那麼web服務器又再次fork一個新進程，周而復始的進行。

後來出現了一種更高級的方式是， web服務器能夠內置perl解釋器或php解釋器。 也就是說這些解釋器作成模塊的方式，web服務器會在啓動的時候就啓動這些解釋器。 當有新的動態請求進來時，web服務器就是本身解析這些perl或php腳本，免得從新fork一個進程，效率提升了。

fastcgi的方式是，web服務器收到一個請求時，他不會從新fork一個進程（由於這個進程在web服務器啓動時就開啓了，並且不會退 出），web服務器直接把內容傳遞給這個進程（進程間通訊，但fastcgi使用了別的方式，tcp方式通訊），這個進程收到請求後進行處理，把結果返回 給web服務器，最後本身接着等待下一個請求的到來，而不是退出。 
fastcgi跟cgi的區別是：
                  在web服務器方面                                                         在對數據進行處理的進程方面
cgi         fork一個新的進程進行處理                                           讀取參數，處理數據，而後就結束生命期
fastcgi   用tcp方式跟遠程機子上的進程或本地進程創建鏈接       要開啓tcp端口，進入循環，等待數據的到來，處理數據

舉個例子: 服務端如今有個10萬個字單詞， 客戶每次會發來一個字符串，問以這個字符串爲前綴的單詞有多少個。 那麼能夠寫一個程序，這個程序會建一棵trie樹，而後每次用戶請求過來時能夠直接到這個trie去查找。 可是若是以cgi的方式的話，此次請求結束後這課trie也就沒了，等下次再啓動該進程時，又要新建一棵trie樹，這樣的效率就過低下了。   而用fastcgi的方式的話，這課trie樹在進程啓動時創建，之後就能夠直接在trie樹上查詢指定的前綴了。

 

三、select, poll和epoll的區別

select

select最先於1983年出如今4.2BSD中，它經過一個select()系統調用來監視多個文件描述符的數組，當select()返回後，該數組中就緒的文件描述符便會被內核修改標誌位，使得進程能夠得到這些文件描述符從而進行後續的讀寫操做。

select目前幾乎在全部的平臺上支持，其良好跨平臺支持也是它的一個優勢，事實上從如今看來，這也是它所剩很少的優勢之一。

select的一個缺點在於單個進程可以監視的文件描述符的數量存在最大限制，在Linux上通常爲1024，不過能夠經過修改宏定義甚至從新編譯內核的方式提高這一限制。

另外，select()所維護的存儲大量文件描述符的數據結構，隨着文件描述符數量的增大，其複製的開銷也線性增加。同時，因爲網絡響應時間的延遲 使得大量TCP鏈接處於非活躍狀態，但調用select()會對全部socket進行一次線性掃描，因此這也浪費了必定的開銷。

poll

poll在1986年誕生於System V Release 3，它和select在本質上沒有多大差異，可是poll沒有最大文件描述符數量的限制。 

poll和select一樣存在一個缺點就是，包含大量文件描述符的數組被總體複製於用戶態和內核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨着文件描述符數量的增長而線性增大。 

另外，select()和poll()將就緒的文件描述符告訴進程後，若是進程沒有對其進行IO操做，那麼下次調用select()和poll() 的時候將再次報告這些文件描述符，因此它們通常不會丟失就緒的消息，這種方式稱爲水平觸發（Level Triggered）。

epoll

直到Linux2.6纔出現了由內核直接支持的實現方法，那就是epoll，它幾乎具有了以前所說的一切優勢，被公認爲Linux2.6下性能最好的多路I/O就緒通知方法。

epoll能夠同時支持水平觸發和邊緣觸發（Edge Triggered，只告訴進程哪些文件描述符剛剛變爲就緒狀態，它只說一遍，若是咱們沒有采起行動，那麼它將不會再次告知，這種方式稱爲邊緣觸發），理論上邊緣觸發的性能要更高一些，可是代碼實現至關複雜。

epoll一樣只告知那些就緒的文件描述符，並且當咱們調用epoll_wait()得到就緒文件描述符時，返回的不是實際的描述符，而是一個表明 就緒描述符數量的值，你只須要去epoll指定的一個數組中依次取得相應數量的文件描述符便可，這裏也使用了內存映射（mmap）技術，這樣便完全省掉了 這些文件描述符在系統調用時複製的開銷。

另外一個本質的改進在於epoll採用基於事件的就緒通知方式。在select/poll中，進程只有在調用必定的方法後，內核纔對全部監視的文件描 述符進行掃描，而epoll事先經過epoll_ctl()來註冊一個文件描述符，一旦基於某個文件描述符就緒時，內核會採用相似callback的回調 機制，迅速激活這個文件描述符，當進程調用epoll_wait()時便獲得通知。

 

四、Memcache和Redis區別

1:  Redis中，並非全部的數據都一直存儲在內存中的，這是和Memcached相比一個最大的區別。(虛擬內存--Redis當物理內存用完時，能夠將一些好久沒用到的value 交換到磁盤)

2:  Redis在不少方面具有數據庫的特徵，或者說就是一個數據庫系統，而Memcached只是簡單的K/V緩存。

3:  他們的擴展都須要作集羣；實現方式：master-slave、Hash。

4:  在100k以上的數據中，Memcached性能要高於Redis。

5:  若是要說內存使用效率，使用簡單的key-value存儲的話，Memcached的內存利用率更高，而若是Redis採用hash結構來作key-value存儲，因爲其組合式的壓縮，其內存利用率會高於Memcached。固然，這和你的應用場景和數據特性有關。

6:  若是你對數據持久化和數據同步有所要求，那麼推薦你選擇Redis，由於這兩個特性Memcached都不具有。即便你只是但願在升級或者重啓系統後緩存數據不會丟失，選擇Redis也是明智的。(memcache掛掉後，數據沒了；redis能夠按期保存到磁盤（持久化）災難恢復--memcache掛掉後，數據不可恢復; redis數據丟失後能夠經過aof恢復)

7:  Redis和Memcache在寫入性能上面差異不大，讀取性能上面尤爲是批量讀取性能上面Memcache更強