服務器方面：

1、web服務器nginx和apache的對比分析

①nginx相對于apache的優(yōu)點：

輕量級，同樣起web 服務，比apache 占用更少的內(nèi)存及資源 ，抗并發(fā)，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高并發(fā)下nginx 能保持低資源低消耗高性能，高度模塊化的設計，編寫模塊相對簡單。

apache相對于nginx 的優(yōu)點：A.rewrite ，比nginx 的rewrite 強大；B.動態(tài)頁面，模塊超多，基本想到的都可以找到；C.少bug ，nginx 的bug 相對較多；D.超穩(wěn)定。

一般來說，需要性能的web 服務，用nginx 。如果不需要性能只求穩(wěn)定，那就apache.

②作為 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的并發(fā)連接，體現(xiàn)更高的效率。Nginx采用C進行編寫， 不論是系統(tǒng)資源開銷還是CPU使用效率都比 Perlbal 要好很多。

③Nginx 配置簡潔，Apache 復雜。Nginx 靜態(tài)處理性能比 Apache 高 3倍以上，Apache 對 PHP 支持比較簡單，Nginx 需要配合其他后端用。Apache 的組件比 Nginx 多，現(xiàn)在 Nginx 才是Web 服務器的首選。

④最核心的區(qū)別在于apache是同步多進程模型，一個連接對應一個進程；nginx是異步的，多個連接（萬級別）可以對應一個進程。

⑤nginx處理靜態(tài)文件好，耗費內(nèi)存少。但無疑apache仍然是目前的主流，有很多豐富的特性。所以還需要搭配著來。當然如果能確定nginx就適合需求，那么使用nginx會是更經(jīng)濟的方式。

⑥nginx處理動態(tài)請求是雞肋，一般動態(tài)請求要apache去做，nginx只適合靜態(tài)和反向。

⑦Nginx優(yōu)于apache的主要兩點：A.Nginx本身就是一個反向代理服務器 B.Nginx支持7層負載均衡；其他的當然，Nginx可能會比 apache支持更高的并發(fā)。

數(shù)據(jù)庫方面：

1、數(shù)據(jù)庫優(yōu)化：

①方法：MySQL可以建分表，讀寫分離，建索引，一般經(jīng)常更新的字段不適合建索引，建索引會降低數(shù)據(jù)非查詢操作的效率。主鍵是一種特殊的索引。

②導致索引失效的情況：

A、如果條件中有or，即使其中有條件帶索引也不會使用到。

B、對于多列索引，不是使用的第一部分，則不會使用索引。

C、like查詢是以%開頭，而不是以%結尾的。

D、如果索引列類型是字符串，一定要在條件中將數(shù)據(jù)使用引號引用起來，否則不使用索引。

E、如果mysql估計使用全表掃描要比使用索引快，則不使用索引。

2、MySQL引擎的種類和區(qū)別

①種類：MyISAM、InnoDB、MEMORY、MERGE、Archive、Blackhole、CSV、Federate、Merge、NDB集群引擎，第三方引擎：OLTP類引擎、面向列的存儲引擎、社區(qū)存儲引擎。

②區(qū)別：

A、MyISAM是MySQL5.1及之前的默認存儲引擎。MyISAM不支持事務、也不支持外鍵，但其訪問速度快，對事務完整性沒有要求。MyISAM表還支持3中不同的存儲格式：

1 靜態(tài)表

2 動態(tài)表

3 壓縮表

B、InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是比起MyISAM存儲引擎，InnoDB寫的處理效率差一些并且會占用更多的磁盤空間以保留數(shù)據(jù)和索引。 InnoDB存儲方式為兩種：1 使用共享表空間存儲 2 使用多表空間

C、MEMORY存儲引擎使用存在內(nèi)存中的內(nèi)容來創(chuàng)建表。每個MEMORY表只實際對應一個磁盤文件。MEMORY類型的表訪問非常得快，因為它的數(shù)據(jù)是放在內(nèi)存中的，并且默認使用HASH索引。但是一旦服務關閉，表中的數(shù)據(jù)就會丟失掉。

D、MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表必須結構完全相同。MERGE表本身沒有數(shù)據(jù)，對MERGE類型的表進行查詢、更新、刪除的操作，就是對內(nèi)部的MyISAM表進行的。

3、數(shù)據(jù)庫事務

（1）四個特性：ACID，原子性，一致性，隔離性，持久性。

（2）四個隔離級別：

Read Uncommitted（讀取未提交內(nèi)容）

在該隔離級別，所有事務都可以看到其他未提交事務的執(zhí)行結果。本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。

Read Committed（讀取提交內(nèi)容）

這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經(jīng)提交事務所做的改變。這種隔離級別 也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實例在該實例處理其間可能會有新的commit，所以同一select可能返回不同結果。

Repeatable Read（可重讀）

這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。不過理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務又在該范圍內(nèi)插入了新行，當用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。

Serializable（可串行化）

這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數(shù)據(jù)行上加上共享鎖。在這個級別，可能導致大量的超時現(xiàn)象和鎖競爭。

這四種隔離級別采取不同的鎖類型來實現(xiàn)，若讀取的是同一個數(shù)據(jù)的話，就容易發(fā)生問題。例如：

i. 臟讀（Drity Read）：某個事務已更新一份數(shù)據(jù)，另一個事務在此時讀取了同一份數(shù)據(jù)，由于某些原因，前一個RollBack了操作，則后一個事務所讀取的數(shù)據(jù)就會是不正確的。

ii. 不可重復讀（Non-repeatable read）：在一個事務的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個事務更新的原有的數(shù)據(jù)。

iii. 幻讀（Phantom Read）：在一個事務的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個事務查詢了幾列（Row）數(shù)據(jù)，而另一個事務卻在此時插入了新的幾列數(shù)據(jù)，先前的事務在接下來的查詢中，就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

（3）一致性處理：

A、開啟事務。B、申請寫權限，也就是給對象（表或記錄）加鎖。C、假如失敗，則結束事務，過一會重試。D、假如成功，也就是給對象加鎖成功，防止其他用戶再用同樣的方式打開。E、進行編輯操作。F、寫入所進行的編輯結果。G、假如寫入成功，則提交事務，完成操作。 H、假如寫入失敗，則回滾事務，取消提交。I、（G、H）兩步操作已釋放了鎖定的對象，恢復到操作前的狀態(tài)。

（4）基于事務的數(shù)據(jù)庫引擎的選型：如果考慮到事務，推薦選用MySQL INNODB引擎；如果考慮速度，建議考慮MySQL MyISAM引擎，并且需要在代碼層面做比較復雜的處理，如通過多線程、異步、非阻塞等方式對數(shù)據(jù)庫進行清理，同時需要信號量、欄柵、數(shù)據(jù)庫標志位等工具保證數(shù)據(jù)一致性。

4、海量數(shù)據(jù)處理

（1）數(shù)據(jù)庫擴展：

①縱向擴展：基于業(yè)務的高度隔離性和數(shù)據(jù)的安全性，對業(yè)務和數(shù)據(jù)進行合理的切分，進行主-備機分離，主-主同步，主-從同步（對于MySQL數(shù)據(jù)庫是單向異步同步機制），主-從熱備等操作。

②橫向擴展：對數(shù)據(jù)表進行橫向切分，按一定的規(guī)則（hash取模分、user_id尾數(shù)、自定義算法等）對數(shù)據(jù)表進行橫向切分。

關于數(shù)據(jù)庫架構和擴展方面的文章請見：Mysql在大型網(wǎng)站的應用架構演變。

（2）分布式數(shù)據(jù)方案：

①提供分庫規(guī)則和路由規(guī)則（RouteRule簡稱RR），將上面的說明中提到的三中切分規(guī)則直接內(nèi)嵌入本系統(tǒng)，具體的嵌入方式在接下來的內(nèi)容中進行詳細的說明和論述；

②引入集群（Group）的概念，保證數(shù)據(jù)的高可用性；

③引入負載均衡策略（LoadBalancePolicy簡稱LB）；

④引入集群節(jié)點可用性探測機制，對單點機器的可用性進行定時的偵測，以保證LB策略的正確實施，以確保系統(tǒng)的高度穩(wěn)定性；

⑤引入讀/寫分離，提高數(shù)據(jù)的查詢速度。

具體描述請參見博文：MySQL 海量數(shù)據(jù)的存儲和訪問解決方案。

（3）數(shù)據(jù)庫切分策略介紹，請見博文：數(shù)據(jù)庫Sharding的基本思想和切分策略。

（4）隨著數(shù)據(jù)量隨著業(yè)務的發(fā)展不斷增大，傳統(tǒng)的關系型數(shù)據(jù)庫RDB已經(jīng)無法滿足需要，這時需要引入新的海量數(shù)據(jù)處理解決方案：Apache HBase。

框架方面：

Spring原理（建議讀一下框架核心源碼）

①IoC（Inversion of control）： 控制反轉，依賴注入

1）IoC：

概念：控制權由對象本身轉向容器；由容器根據(jù)配置文件去創(chuàng)建實例并創(chuàng)建各個實例之間的依賴關系

2）依賴IoC容器負責管理bean，有兩種，一種是BeanFactory，另一種是ApplicationContext，但是ApplicationContext繼承與BeanFactory。

核心：bean工廠；在Spring中，bean工廠創(chuàng)建的各個實例稱作bean

②AOP（Aspect-Oriented Programming）： 面向方面編程

1）代理的兩種方式：

靜態(tài)代理：

? 針對每個具體類分別編寫代理類；

? 針對一個接口編寫一個代理類；

動態(tài)代理：

針對一個方面編寫一個InvocationHandler，然后借用JDK反射包中的Proxy類為各種接口動態(tài)生成相應的代理類

2） AOP的主要原理：動態(tài)代理

實現(xiàn)：有兩種：JDK Proxy和Cglib，Spring規(guī)定對于有接口的類用JDK Proxy，對于無接口和抽象類用Cglib，雖然Cglib均可以代理，但是Cglib復雜，效率低。但是Cglib有例外，就是代理的類中不能是final修飾的類或者類中有final方法。

3、Spring、Struts2、Servlet對比

①Servlet原理：Tomcat 的容器等級中，Context 容器是直接管理 Servlet 在容器中的包裝類 Wrapper，所以 Context 容器如何運行將直接影響 Servlet 的工作方式。

A、Servlet生命周期詳解

Servlet的生命周期可以分為四個階段，即裝載類及創(chuàng)建實例階段、初始化階段、服務階段和實例銷毀階段。下面針對每個階段的編程任務及注意事項進行詳細的說明。

B、Servlet創(chuàng)建過程

在默認情況下Servlet實例是在第一個請求到來的時候創(chuàng)建，以后復用。一旦Servlet實例被創(chuàng)建，Web服務器會自動調用init（ServletConfig config）方法來初始化該Servlet。其中方法參數(shù)config中包含了Servlet的配置信息，比如初始化參數(shù)，該對象由服務器創(chuàng)建。init方法在Servlet生命周期中只執(zhí)行一次，而且該方法執(zhí)行在單線程的環(huán)境下，因此開發(fā)者不用考慮線程安全的問題。

C、服務

一旦Servlet實例成功創(chuàng)建及初始化，該Servlet實例就可以被服務器用來服務于客戶端的請求并生成響應。在服務階段Web服務器會調用該實例的service（ServletRequest request，ServletResponse response）方法，request對象和response對象有服務器創(chuàng)建并傳給Servlet實例。request對象封裝了客戶端發(fā)往服務器端的信息，response對象封裝了服務器發(fā)往客戶端的信息。

為了提高效率，Servlet規(guī)范要求一個Servlet實例必須能夠同時服務于多個客戶端請求，即service（）方法運行在多線程的環(huán)境下，Servlet開發(fā)者必須保證該方法的線程安全性。

Serlvet接口只定義了一個服務方法就是service，而HttpServlet類實現(xiàn)了該方法并且要求調用下列的方法之一：

doGet：處理GET請求

doPost：處理POST請求

當發(fā)出客戶端請求的時候，調用service 方法并傳遞一個請求和響應對象。Servlet首先判斷該請求是GET 操作還是POST 操作。然后它調用下面的一個方法：doGet 或 doPost。如果請求是GET就調用doGet方法，如果請求是POST就調用doPost方法。

②對比：Spring主要有IoC和AOP，Spring中IoC管理的bean為單例模式的，可以配置成原型模式。如果用Spring管理struts2的bean，必須要設置成原型模式，因為struts2封裝來了servlet，隔離了servlet的特性，Action不同于Spring，已經(jīng)是原型模式了。