JAVA高級要求

項目情況

• 1.主要的職責(zé)
• 2.主要的貢獻(xiàn)
• 3.解決的難點(diǎn)
• 4.心得

基礎(chǔ)

數(shù)據(jù)結(jié)構(gòu)算法

線性結(jié)構(gòu)包括：數(shù)組，鏈表，隊列，棧；

非線性結(jié)構(gòu)包括：樹，圖，表；

多線程模型

Future模型、Fork&Join 模型、Actor消息模型、生產(chǎn)者消費(fèi)者模型、Master-Worker模型。

Servlet原理

Servlet 容器作為一個獨(dú)立發(fā)展的標(biāo)準(zhǔn)化產(chǎn)品，目前它的種類很多，如jetty、tomcat。

Tomcat 的容器分為四個等級，真正管理 Servlet 的容器是 Context 容器，一個 Context 對應(yīng)一個 Web 工程。

1、Web Client 向Servlet容器（Tomcat）發(fā)出Http請求

2、Servlet容器接收Web Client的請求

3、Servlet容器創(chuàng)建一個HttpRequest對象，將Web Client請求的信息封裝到這個對象中

4、Servlet容器創(chuàng)建一個HttpResponse對象

5、Servlet容器調(diào)用HttpServlet對象的service方法，把HttpRequest對象與HttpResponse對象作為參數(shù)傳給 HttpServlet對象

6、HttpServlet調(diào)用HttpRequest對象的有關(guān)方法，獲取Http請求信息

7、HttpServlet調(diào)用HttpResponse對象的有關(guān)方法，生成響應(yīng)數(shù)據(jù)

8、Servlet容器把HttpServlet的響應(yīng)結(jié)果傳給Web Client

JDBC原理

JDBC是接口，而JDBC驅(qū)動才是接口的實(shí)現(xiàn)，沒有驅(qū)動無法完成數(shù)據(jù)庫連接！每個數(shù)據(jù)庫廠商都有自己的驅(qū)動，用來連接自己公司的數(shù)據(jù)庫。

JDBC中的核心類有：DriverManager、Connection、Statement，和ResultSet！

DriverManger（驅(qū)動管理器）的作用有兩個：

l 注冊驅(qū)動：這可以讓JDBC知道要使用的是哪個驅(qū)動；

l 獲取Connection：如果可以獲取到Connection，那么說明已經(jīng)與數(shù)據(jù)庫連接上了。

Connection對象表示連接，與數(shù)據(jù)庫的通訊都是通過這個對象展開的：

l Connection最為重要的一個方法就是用來獲取Statement對象；

l Statement是用來向數(shù)據(jù)庫發(fā)送SQL語句的，這樣數(shù)據(jù)庫就會執(zhí)行發(fā)送過來的SQL語句

l void executeUpdate(String sql)：執(zhí)行更新操作（insert、update、delete等）；

l ResultSet executeQuery(String sql)：執(zhí)行查詢操作，數(shù)據(jù)庫在執(zhí)行查詢后會把查詢結(jié)果，查詢結(jié)果就是ResultSet；

ResultSet對象表示查詢結(jié)果集，只有在執(zhí)行查詢操作后才會有結(jié)果集的產(chǎn)生。結(jié)果集是一個二維的表格，有行有列。操作結(jié)果集要學(xué)習(xí)移動ResultSet內(nèi)部的“行光標(biāo)”，以及獲取當(dāng)前行上的每一列上的數(shù)據(jù)。

Spring特點(diǎn)

• 一、非侵入式編程

  Spring框架的API不會再業(yè)務(wù)邏輯上出現(xiàn)，即業(yè)務(wù)邏輯是POJO（Plain Ordinary Java Object）。由于業(yè)務(wù)邏輯中沒有Spring的API，所以業(yè)務(wù)邏輯可以從Spring框架快速的移植到其他框架。

• 二、容器

  Spring作為一個容器，可以管理對象的生命周期、對象與對象之間的依賴關(guān)系?？梢酝ㄟ^配置文件來定義對象，以及設(shè)置其他對象的依賴關(guān)系。

• 三、IoC

  控制反轉(zhuǎn)（Inversion of Control），即創(chuàng)建被調(diào)用的實(shí)例不是由調(diào)用者完成，而是由Spring容器完成，并注入調(diào)用者。

  當(dāng)應(yīng)用IoC，一個對象依賴的其他對象會通過被動的方式傳遞進(jìn)來，而不是這個對象自己創(chuàng)建或查找依賴對象，即，不是對象從容器中查找依賴，而是容器在對象初始化時不等對象請求就主動將依賴傳遞給它。

• 四、AOP

  面向切面編程，是一種編程思想，是面向?qū)ο缶幊蘋OP的補(bǔ)充。Spring提供面向?qū)ο缶幊痰闹С?，允許通過分離應(yīng)用的業(yè)務(wù)邏輯與系統(tǒng)級服務(wù)（日志和事務(wù)管理）進(jìn)行開發(fā)。應(yīng)用對象只實(shí)現(xiàn)他們應(yīng)該做的（完成業(yè)務(wù)邏輯），并不負(fù)責(zé)其它的系統(tǒng)級關(guān)注點(diǎn)（日志或者事務(wù)的支持）。

  可以把日志、安全、事務(wù)管理等服務(wù)理解成一個“切面”，把很多被業(yè)務(wù)邏輯反復(fù)使用的服務(wù)完全剝離出來，以達(dá)到復(fù)用。然后將“切面”動態(tài)的“織入”到業(yè)務(wù)邏輯中，讓其享受此“切面”的服務(wù)。

中高級特性

并發(fā)包

集合包最常用的有Collection和Map兩個接口的實(shí)現(xiàn)類，Colleciton用于存放多個單對象，Map用于存放Key-Value形式的鍵值對。

Collection中最常用的又分為兩種類型的接口：List和Set，兩者最明顯的差別為List支持放入重復(fù)的元素，而Set不支持。

詳細(xì)了解

類加載機(jī)制

• 1. 不可以自己寫個String類，因?yàn)?根據(jù)類加載的雙親委派機(jī)制，會去加載父類，父類發(fā)現(xiàn)沖突了String就不再加載了;
• 2. 加載類的時候，可以使用Java探針技術(shù)（JAVA agent）對類的字節(jié)碼進(jìn)行修改；
• 3. 類加載器

啟動類加載器，Bootstrap ClassLoader，加載JACA_HOME\lib，或者被-Xbootclasspath參數(shù)限定的類

擴(kuò)展類加載器，Extension ClassLoader，加載\lib\ext，或者被java.ext.dirs系統(tǒng)變量指定的類

應(yīng)用程序類加載器，Application ClassLoader，加載ClassPath中的類庫

自定義類加載器，通過繼承ClassLoader實(shí)現(xiàn)，一般是加載我們的自定義類

• 4. 要創(chuàng)建用戶自己的類加載器，只需要繼承java.lang.ClassLoader類，然后覆蓋它的findClass(String name)方法即可，即指明如何獲取類的字節(jié)碼流;
     如果要符合雙親委派規(guī)范，則重寫findClass方法（用戶自定義類加載邏輯）；要破壞的話，重寫loadClass方法(雙親委派的具體邏輯實(shí)現(xiàn))。

詳細(xì)了解

GC原理與調(diào)優(yōu)

• 1. Java 的內(nèi)存管理實(shí)際上就是對象的管理，其中包括對象的分配和釋放，對于程序員來說，分配對象使用new關(guān)鍵字；釋放對象時，只要將對象所有引用賦值為null，讓程序不能夠再訪問到這個對象，我們稱該對象為"不可達(dá)的".GC將負(fù)責(zé)回收所有"不可達(dá)"對象的內(nèi)存空間。

設(shè)計模式與框架源碼

1. 創(chuàng)建型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。
2. 結(jié)構(gòu)型模式（7種）：適配器模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。
3. 行為型模式（11種）：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式。

設(shè)計模式遵循的原則有6個：

1. 開閉原則（Open Close Principle）

對擴(kuò)展開放，對修改關(guān)閉。

2. 里氏代換原則（Liskov Substitution Principle）

只有當(dāng)衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復(fù)用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。

3. 依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）

這個是開閉原則的基礎(chǔ)，對接口編程，依賴于抽象而不依賴于具體。

4. 接口隔離原則（Interface Segregation Principle）

使用多個隔離的借口來降低耦合度。

5. 迪米特法則（最少知道原則）（Demeter Principle）

一個實(shí)體應(yīng)當(dāng)盡量少的與其他實(shí)體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對獨(dú)立。

6. 合成復(fù)用原則（Composite Reuse Principle）

原則是盡量使用合成/聚合的方式，而不是使用繼承。繼承實(shí)際上破壞了類的封裝性，超類的方法可能會被子類修改。

spring IOC AOP原理與優(yōu)點(diǎn)

IOC

(1). IoC（Inversion of Control）是指容器控制程序?qū)ο笾g的關(guān)系，而不是傳統(tǒng)實(shí)現(xiàn)中，由程序代碼直接操控?？刂茩?quán)由應(yīng)用代碼中轉(zhuǎn)到了外部容器，控制權(quán)的轉(zhuǎn)移是所謂反轉(zhuǎn)。 對于Spring而言，就是由Spring來控制對象的生命周期和對象之間的關(guān)系；IoC還有另外一個名字——“依賴注入（Dependency Injection）”。從名字上理解，所謂依賴注入，即組件之間的依賴關(guān)系由容器在運(yùn)行期決定，即由容器動態(tài)地將某種依賴關(guān)系注入到組件之中。

(2). 在Spring的工作方式中，所有的類都會在spring容器中登記，告訴spring這是個什么東西，你需要什么東西，然后spring會在系統(tǒng)運(yùn)行到適當(dāng)?shù)臅r候，把你要的東西主動給你，同時也把你交給其他需要你的東西。所有的類的創(chuàng)建、銷毀都由 spring來控制，也就是說控制對象生存周期的不再是引用它的對象，而是spring。對于某個具體的對象而言，以前是它控制其他對象，現(xiàn)在是所有對象都被spring控制，所以這叫控制反轉(zhuǎn)。

(3). 在系統(tǒng)運(yùn)行中，動態(tài)的向某個對象提供它所需要的其他對象。

(4). 依賴注入的思想是通過反射機(jī)制實(shí)現(xiàn)的，在實(shí)例化一個類時，它通過反射調(diào)用類中set方法將事先保存在HashMap中的類屬性注入到類中。 總而言之，在傳統(tǒng)的對象創(chuàng)建方式中，通常由調(diào)用者來創(chuàng)建被調(diào)用者的實(shí)例，而在Spring中創(chuàng)建被調(diào)用者的工作由Spring來完成，然后注入調(diào)用者，即所謂的依賴注入or控制反轉(zhuǎn)。 注入方式有兩種：依賴注入和設(shè)置注入； IoC的優(yōu)點(diǎn)：降低了組件之間的耦合，降低了業(yè)務(wù)對象之間替換的復(fù)雜性，使之能夠靈活的管理對象。

AOP

(1). AOP面向方面編程基于IoC，是對OOP的有益補(bǔ)充；

(2). AOP利用一種稱為“橫切”的技術(shù)，剖解開封裝的對象內(nèi)部，并將那些影響了 多個類的公共行為封裝到一個可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡單地說，就是將那些與業(yè)務(wù)無關(guān)，卻為業(yè)務(wù)模塊所共同調(diào)用的 邏輯或責(zé)任封裝起來，比如日志記錄，便于減少系統(tǒng)的重復(fù)代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護(hù)性。

(3). AOP代表的是一個橫向的關(guān) 系，將“對象”比作一個空心的圓柱體，其中封裝的是對象的屬性和行為；則面向方面編程的方法，就是將這個圓柱體以切面形式剖開，選擇性的提供業(yè)務(wù)邏輯。而 剖開的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開的切面復(fù)原，不留痕跡，但完成了效果。

(4). 實(shí)現(xiàn)AOP的技術(shù)，主要分為兩大類：一是采用動態(tài)代理技術(shù)，利用截取消息的方式，對該消息進(jìn)行裝飾，以取代原有對象行為的執(zhí)行；二是采用靜態(tài)織入的方式，引入特定的語法創(chuàng)建“方面”，從而使得編譯器可以在編譯期間織入有關(guān)“方面”的代碼。

(5). Spring實(shí)現(xiàn)AOP：JDK動態(tài)代理和CGLIB代理 JDK動態(tài)代理：其代理對象必須是某個接口的實(shí)現(xiàn)，它是通過在運(yùn)行期間創(chuàng)建一個接口的實(shí)現(xiàn)類來完成對目標(biāo)對象的代理；其核心的兩個類是InvocationHandler和Proxy。 CGLIB代理：實(shí)現(xiàn)原理類似于JDK動態(tài)代理，只是它在運(yùn)行期間生成的代理對象是針對目標(biāo)類擴(kuò)展的子類。CGLIB是高效的代碼生成包，底層是依靠ASM（開源的java字節(jié)碼編輯類庫）操作字節(jié)碼實(shí)現(xiàn)的，性能比JDK強(qiáng)；需要引入包asm.jar和cglib.jar。 使用AspectJ注入式切面和@AspectJ注解驅(qū)動的切面實(shí)際上底層也是通過動態(tài)代理實(shí)現(xiàn)的。

(6). AOP使用場景：

Authentication 權(quán)限檢查

Caching 緩存

Context passing 內(nèi)容傳遞

Error handling 錯誤處理

Lazy loading　延遲加載

Debugging　　調(diào)試

logging, tracing, profiling and monitoring　日志記錄，跟蹤，優(yōu)化，校準(zhǔn)

Performance optimization　性能優(yōu)化，效率檢查

Persistence　　持久化

Resource pooling　資源池

Synchronization　同步

Transactions 事務(wù)管理

另外Filter的實(shí)現(xiàn)和struts2的攔截器的實(shí)現(xiàn)都是AOP思想的體現(xiàn)。

數(shù)據(jù)庫

復(fù)雜SQL與優(yōu)化

• 1)優(yōu)化sql和索引優(yōu)化

Mysql全文檢索

• 2)利用redis加緩存

sql優(yōu)化解決不了，那么我們可以用redis加緩存，在系統(tǒng)啟動的時候就做一個數(shù)據(jù)的熱處理提前加入到緩存中，以至于每次查詢命中緩存。

• 3)讀寫分離，主從復(fù)制或者主主復(fù)制

緩存解決不了，我們可以做讀寫分離

• 4 )利用分區(qū)表

分區(qū)的表的原理就是把一張大表進(jìn)行分區(qū)后，他還是一張表，不會變成二張表，但是他存放數(shù)據(jù)的區(qū)塊變多了。 mysql的分表是真正的分表，一張表分成很多表后，每一個小表都是完正的一張表，比如user表按userid分表后就是user_01和user_02。分區(qū)表mysql有專門的語句做分區(qū)存儲。

• 5)最后是分庫分表

首先說一下oracle的分區(qū)表和表分區(qū)是不同的概念，其實(shí)就是oracle的分區(qū)表說的就是mysql的分區(qū)表，但是表分區(qū)說的就是mysql的分表操作，也就是我們所說的水平拆分。f分庫分表也是我們所說的分庫就是垂直拆分，分表就是水平拆分。

垂直拆分：把表按模塊劃分到不同數(shù)據(jù)庫表中。

水平拆分：把一個大表的壓力按照相同的表結(jié)構(gòu)分到不同的數(shù)據(jù)庫上或者同一個數(shù)據(jù)庫中的拆分成多個表，每次存儲根據(jù)分區(qū)建做hash取模運(yùn)算判斷出存在哪個字表上面。

事務(wù)機(jī)制

數(shù)據(jù)庫事務(wù)（Database Transaction）,是指作為單個邏輯工作單元執(zhí)行的一系列操作，要么完全執(zhí)行，要么完全地不執(zhí)行。

• 1. 事務(wù)必須具備ACID四個特性

原子性（Atomicity）
原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾。

一致性（Consistency）
一致性是指事務(wù)必須使數(shù)據(jù)庫從一個一致的狀態(tài)變到另外一個一致的狀態(tài)，也就是執(zhí)行事務(wù)之前和之后的狀態(tài)都必須處于一致的狀態(tài)。

隔離性(Isolation)

隔離性是指當(dāng)多個用戶并發(fā)訪問數(shù)據(jù)庫時，比如操作同一張表時，數(shù)據(jù)庫為每一個用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個并發(fā)事務(wù)之間要相互隔離.

持久性(Durability)

持久性是指一個事務(wù)一旦被提交了，那么對于數(shù)據(jù)庫中的數(shù)據(jù)改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遭遇到故障的情況下也不會丟失提交事務(wù)的操作。

• 2. 并發(fā)訪問數(shù)據(jù)會出現(xiàn)三種情況：臟讀、不可重復(fù)讀、幻讀。

臟讀（Dirty Read）

當(dāng)事務(wù)A在修改(insert、delete、update)記錄但還未提交時，另一個事務(wù)B讀取了該記錄，此時事務(wù)B讀到的數(shù)據(jù)就是臟數(shù)據(jù)，如果此時事務(wù)A回滾了事務(wù)，則事務(wù)B讀到的數(shù)據(jù)無效。

不可重復(fù)讀（Non-repeatable Read）

當(dāng)事務(wù)A在讀取記錄時，另一個事務(wù)B修改(delete、update)了該記錄并提交，此時事務(wù)A再一次讀取該記錄會讀取到被事務(wù)B修改后的數(shù)據(jù)。在一個事務(wù)中前后兩次讀取的數(shù)據(jù)不一樣，因此被稱作不可重復(fù)讀。

幻讀（Phantom Read）

當(dāng)事務(wù)A在讀取記錄時，另一個事務(wù)B插入(insert)了新記錄并提交，導(dǎo)致事務(wù)A再次查詢記錄時多出了原本不存在的記錄，就像看到了幻覺一樣，所以被稱作幻讀。

• 3. 事務(wù)的隔離級別

事務(wù)的隔離級別描述了事務(wù)被隔離的程度，其隔離級別有4個，由低到高依次為Read Uncommitted 、Read Committed 、Repeatable Read 、Serializable。通過設(shè)置不同的事務(wù)隔離級別可以解決臟讀、不可重復(fù)讀和幻讀。

讀未提交（Read Uncommitted）

在該隔離級別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。在實(shí)際中很少使用這種隔離級別，其性能并沒有比其他隔離級別好多少，且會發(fā)生臟讀、不可重復(fù)讀和幻讀。

讀提交（Read Committed）

在該隔離級別，所有事務(wù)都只能看到其他已經(jīng)提交的事務(wù)的執(zhí)行結(jié)果。這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級別（MySQL默認(rèn)的是可重復(fù)讀），在該隔離級別會發(fā)生不可重復(fù)讀和幻讀。

可重復(fù)讀（Repeatable Read）

這是MySQL默認(rèn)的事務(wù)隔離級別，該隔離級別雖然解決了臟讀和不可重復(fù)讀，但還是無法避免幻讀。

可串行化（Serializable）

最高級別的事務(wù)隔離級別，通過強(qiáng)制事務(wù)排序，使之不可能相互沖突，從而解決幻讀問題。但是系統(tǒng)開銷花費(fèi)最高，性能很低，一般很少使用。

• 4. MYSQL 事務(wù)處理主要有兩種方法：

MySQL數(shù)據(jù)庫默認(rèn)的存儲引擎類型是MyISAM，這種存儲引擎類型不支持事務(wù)處理。

在MySQL中，只有InnoDB存儲引擎類型的數(shù)據(jù)表才能支持事務(wù)處理。

1）用 BEGIN, ROLLBACK, COMMIT來實(shí)現(xiàn)

BEGIN 開始一個事務(wù)

ROLLBACK 事務(wù)回滾

COMMIT 事務(wù)確認(rèn)

2）直接用 SET 來改變 MySQL 的自動提交模式:

SET AUTOCOMMIT=0 禁止自動提交

SET AUTOCOMMIT=1 開啟自動提交

spring事務(wù)應(yīng)用

• 1. 編程式事務(wù)處理：所謂編程式事務(wù)指的是通過編碼方式實(shí)現(xiàn)事務(wù)，允許用戶在代碼中精確定義事務(wù)的邊界。即類似于JDBC編程實(shí)現(xiàn)事務(wù)管理。管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。對于編程式事務(wù)管理，spring推薦使用TransactionTemplate。
• 2. 聲明式事務(wù)處理：管理建立在AOP之上的。其本質(zhì)是對方法前后進(jìn)行攔截，然后在目標(biāo)方法開始之前創(chuàng)建或者加入一個事務(wù)，在執(zhí)行完目標(biāo)方法之后根據(jù)執(zhí)行情況提交或者回滾事務(wù)。聲明式事務(wù)最大的優(yōu)點(diǎn)就是不需要通過編程的方式管理事務(wù)，這樣就不需要在業(yè)務(wù)邏輯代碼中摻雜事務(wù)管理的代碼，只需在配置文件中做相關(guān)的事務(wù)規(guī)則聲明(或通過基于@Transactional注解的方式)，便可以將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中。

簡單地說，編程式事務(wù)侵入到了業(yè)務(wù)代碼里面，但是提供了更加詳細(xì)的事務(wù)管理；而聲明式事務(wù)由于基于AOP，所以既能起到事務(wù)管理的作用，又可以不影響業(yè)務(wù)代碼的具體實(shí)現(xiàn)。

Spring并不直接管理事務(wù)，而是提供了多種事務(wù)管理器，他們將事務(wù)管理的職責(zé)委托給hibernate或者JTA等持久化機(jī)制所提供的相關(guān)平臺框架的事務(wù)來實(shí)現(xiàn)。
Spring事務(wù)管理器的接口是org.springframework.transaction.PlatformTransactionManager，通過這個接口，Spring為各個平臺如JDBC、Hibernate等都提供了對應(yīng)的事務(wù)管理器，但是具體的實(shí)現(xiàn)就是各個平臺自己的事情了。

延申閱讀

索引原理

MySQL官方對索引的定義為：索引（Index）是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。提取句子主干，就可以得到索引的本質(zhì)：索引是數(shù)據(jù)結(jié)構(gòu)。

主流的RDBMS都是把平衡樹當(dāng)做數(shù)據(jù)表默認(rèn)的索引數(shù)據(jù)結(jié)構(gòu)的。

延申閱讀

延申閱讀

延申閱讀

架構(gòu)能力

用過哪些中間件

tomcat等服務(wù)器中間件

redis等緩存中間件

mybatis等數(shù)據(jù)庫中間件

activemq等消息中間件

zookeeper作用

ZooKeeper 是一個開源的分布式協(xié)調(diào)服務(wù)，由雅虎創(chuàng)建，是 Google Chubby 的開源實(shí)現(xiàn)。
分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)
調(diào)/通知、集群管理、Master 選舉、配置維護(hù)，名字服務(wù)、分布式同步、分布式鎖和分布式隊列
等功能。

可以用來做注冊中心和配置中心。

分布式鎖

• 1. 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖

基于數(shù)據(jù)庫表：通過表的增刪改查實(shí)現(xiàn)加解鎖

基于數(shù)據(jù)庫排他鎖：通過for update來實(shí)現(xiàn)加解鎖

• 2. 基于緩存實(shí)現(xiàn)分布式鎖

相比較于基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖的方案來說，基于緩存來實(shí)現(xiàn)在性能方面會表現(xiàn)的更好一點(diǎn)。而且很多緩存是可以集群部署的，可以解決單點(diǎn)問題。

目前有很多成熟的緩存產(chǎn)品，包括Redis，memcached.

基于Redis實(shí)現(xiàn)分布式鎖在網(wǎng)上有很多相關(guān)文章，其中主要的實(shí)現(xiàn)方式是使用Jedis.setNX方法來實(shí)現(xiàn)。

redis的作者Salvatore Sanfilippo，提出了Redlock算法，該算法實(shí)現(xiàn)了比單一節(jié)點(diǎn)更安全、可靠的分布式鎖管理（DLM）。

• 3. 基于Zookeeper實(shí)現(xiàn)分布式鎖

基于zookeeper臨時有序節(jié)點(diǎn)可以實(shí)現(xiàn)的分布式鎖。

大致思想即為：每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應(yīng)的指定節(jié)點(diǎn)的目錄下，生成一個唯一的瞬時有序節(jié)點(diǎn)。 判斷是否獲取鎖的方式很簡單，只需要判斷有序節(jié)點(diǎn)中序號最小的一個。 當(dāng)釋放鎖的時候，只需將這個瞬時節(jié)點(diǎn)刪除即可。同時，其可以避免服務(wù)宕機(jī)導(dǎo)致的鎖無法釋放，而產(chǎn)生的死鎖問題。

• 4. 三種方案的比較

從理解的難易程度角度（從低到高）
數(shù)據(jù)庫 > 緩存 > Zookeeper

從實(shí)現(xiàn)的復(fù)雜性角度（從低到高）
Zookeeper > 緩存 > 數(shù)據(jù)庫

從性能角度（從高到低）
緩存 > Zookeeper >= 數(shù)據(jù)庫

從可靠性角度（從高到低）
Zookeeper > 緩存 > 數(shù)據(jù)庫

分布式事務(wù)

什么是分布式事務(wù)？簡單的說，就是一次大操作由不同小操作組成，這些小操作分布在不同服務(wù)器上，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗。

基于XA協(xié)議的兩階段提交:MySQL 5.0或者更新版本開始支持XA事務(wù)，只有InnoDB引擎支持XA協(xié)議。詳細(xì)閱讀

TCC編程模式: LCN

消息最終一致性:RocketMQ

延申閱讀

緩存

本地緩存：ehcache等

緩存中間件：redis，memcached

CAP和BASE和ACID的理解

• 1. ACID模型

ACID是傳統(tǒng)數(shù)據(jù)庫常用的設(shè)計理念，追求強(qiáng)一致性模型。
關(guān)系數(shù)據(jù)庫的ACID模型擁有 高一致性 + 可用性 很難進(jìn)行分區(qū)：

Atomicity原子性：一個事務(wù)中所有操作都必須全部完成，要么全部不完成。

Consistency一致性. 在事務(wù)開始或結(jié)束時，數(shù)據(jù)庫應(yīng)該在一致狀態(tài)。

Isolation隔離層. 事務(wù)將假定只有它自己在操作數(shù)據(jù)庫，彼此不知曉。

Durability. 一旦事務(wù)完成，就不能返回。

ACID模型要求一個事物必須滿足上面的四點(diǎn)，這是對關(guān)系型傳統(tǒng)數(shù)據(jù)庫的指導(dǎo)性依據(jù)。而非關(guān)系型數(shù)據(jù)庫NoSql則不再依賴這一模型。

• 2. CAP理論

CAP理論正式成為分布式計算領(lǐng)域的公認(rèn)定理。

CAP理論為：
一個分布式系統(tǒng)最多只能同時滿足：

Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的

Availability(可用性), 好的響應(yīng)性能

Partition tolerance(分區(qū)容錯性) 可靠性

這三項中的兩項。

• 3. BASE理論

BASE:Basically,Available,Soft state,Eventually consistent四個詞組的首字母,它的意思是：基本可用+軟狀態(tài)+最終一致性
eBay的架構(gòu)師Dan Pritchett源于對大規(guī)模分布式系統(tǒng)的實(shí)踐總結(jié)，在ACM上發(fā)表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強(qiáng)一致性（Strong Consistency，CAP的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（Eventual Consitency）。

BASE是指基本可用（Basically Available）、軟狀態(tài)（ Soft State）、最終一致性（ Eventual Consistency）。

基本可用（Basically Available）

基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，即保證核心可用。
電商大促時，為了應(yīng)對訪問量激增，部分用戶可能會被引導(dǎo)到降級頁面，服務(wù)層也可能只提供降級服務(wù)。這就是損失部分可用性的體現(xiàn)。

軟狀態(tài)（ Soft State）

軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本，允許不同節(jié)點(diǎn)間副本同步的延時就是軟狀態(tài)的體現(xiàn)。mysql replication的異步復(fù)制也是一種體現(xiàn)。

最終一致性（ Eventual Consistency）

最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況。

BASE模型是傳統(tǒng)ACID模型的反面，不同與ACID，BASE強(qiáng)調(diào)犧牲高一致性，從而獲得可用性，數(shù)據(jù)允許在一段時間內(nèi)的不一致，只要保證最終一致就可以了。

BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性： Basically Available基本可用。支持分區(qū)失敗(e.g. sharding碎片劃分?jǐn)?shù)據(jù)庫) Soft state軟狀態(tài) 狀態(tài)可以有一段時間不同步，異步。 Eventually consistent最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時時一致。

BASE思想的主要實(shí)現(xiàn)有

1.按功能劃分?jǐn)?shù)據(jù)庫

2.sharding碎片

溝通和學(xué)習(xí)能力職業(yè)規(guī)劃

• 1.平時怎么學(xué)習(xí)
• 2.喜歡逛什么社區(qū)
• 3.未來打算如何

技術(shù)要求

• 1.多線程模型 - > 各種狀態(tài)之間轉(zhuǎn)換 -> jdk常見的并發(fā)類 -> 如何保證線程安全 -> volatile實(shí)現(xiàn)原理 -> 線程池與隊列 -> 調(diào)優(yōu)

volatile實(shí)現(xiàn)原理：

• 2.spring 特點(diǎn) -> AOP原理 -> 代理種類 -> 實(shí)現(xiàn)細(xì)節(jié) -> CGLib局限 -> 性能如何
• 3.JVM組成 -> 內(nèi)存模型 -> 垃圾收集算法 -> 類加載 -> 收集器類型 -> 如何調(diào)優(yōu)
• 4.spring MVC 組成 - > 怎么映射控制器 -> 控制器單例否 -> 攔截器應(yīng)用
• 5.使用過MySQL -> 數(shù)據(jù)庫引擎區(qū)別 -> 事務(wù)控制 - > 隔離級別 -> 加鎖種類區(qū)別 -> spring事務(wù)傳播 -> 區(qū)別
• 6.分布式和集群區(qū)別 -> 服務(wù)發(fā)現(xiàn)和負(fù)載均衡 -> 中間件 -> 分布式事務(wù)處理 -> 緩存設(shè)計