服務器方面：

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

①nginx相對于apache的優點：

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

apache相對于nginx 的優點：A.rewrite ，比nginx 的rewrite 強大；B.動態頁面，模塊超多，基本想到的都可以找到；C.少bug ，nginx 的bug 相對較多；D.超穩定。

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

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

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

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

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

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

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

數據庫方面：

1、數據庫優化：

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

②導致索引失效的情況：

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

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

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

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

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

2、MySQL引擎的種類和區別

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

②區別：

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

1 靜態表

2 動態表

3 壓縮表

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

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

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

3、數據庫事務

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

（2）四個隔離級別：

Read Uncommitted（讀取未提交內容）

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

Read Committed（讀取提交內容）

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

Repeatable Read（可重讀）

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

Serializable（可串行化）

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

這四種隔離級別采取不同的鎖類型來實現，若讀取的是同一個數據的話，就容易發生問題。例如：

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

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

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

（3）一致性處理：

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

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

4、海量數據處理

（1）數據庫擴展：

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

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

關于數據庫架構和擴展方面的文章請見：Mysql在大型網站的應用架構演變。

（2）分布式數據方案：

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

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

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

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

⑤引入讀/寫分離，提高數據的查詢速度。

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

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

（4）隨著數據量隨著業務的發展不斷增大，傳統的關系型數據庫RDB已經無法滿足需要，這時需要引入新的海量數據處理解決方案：Apache HBase。

框架方面：

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

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

1）IoC：

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

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

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

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

1）代理的兩種方式：

靜態代理：

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

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

動態代理：

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

2） AOP的主要原理：動態代理

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

3、Spring、Struts2、Servlet對比

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

A、Servlet生命周期詳解

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

B、Servlet創建過程

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

C、服務

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

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

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

doGet：處理GET請求

doPost：處理POST請求

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

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