原

?乒乓狂魔

?發(fā)布于 2016/07/29 12:47

#1 java基礎(chǔ)：

1.1 算法

1.1 排序算法：直接插入排序、希爾排序、冒泡排序、快速排序、直接選擇排序、堆排序、歸并排序、基數(shù)排序

1.2 二叉查找樹(shù)、紅黑樹(shù)、B樹(shù)、B+樹(shù)、LSM樹(shù)（分別有對(duì)應(yīng)的應(yīng)用，數(shù)據(jù)庫(kù)、HBase）

1.3 BitSet解決數(shù)據(jù)重復(fù)和是否存在等問(wèn)題

1.2 基本

2.1 字符串常量池的遷移

2.2 字符串KMP算法

2.3 equals和hashcode

2.4 泛型、異常、反射

2.5 string的hash算法

2.6 hash沖突的解決辦法：拉鏈法

2.7 foreach循環(huán)的原理

2.8 static、final、transient等關(guān)鍵字的作用

2.9 volatile關(guān)鍵字的底層實(shí)現(xiàn)原理

2.10 Collections.sort方法使用的是哪種排序方法

2.11 Future接口，常見(jiàn)的線程池中的FutureTask實(shí)現(xiàn)等

2.12 string的intern方法的內(nèi)部細(xì)節(jié)，jdk1.6和jdk1.7的變化以及內(nèi)部cpp代碼StringTable的實(shí)現(xiàn)

1.3 設(shè)計(jì)模式

單例模式

工廠模式

裝飾者模式

觀察者設(shè)計(jì)模式

ThreadLocal設(shè)計(jì)模式

。。。

1.4 正則表達(dá)式

4.1 捕獲組和非捕獲組

4.2 貪婪，勉強(qiáng)，獨(dú)占模式

1.5 java內(nèi)存模型以及垃圾回收算法

5.1 類加載機(jī)制，也就是雙親委派模型

5.2 java內(nèi)存分配模型（默認(rèn)HotSpot）

線程共享的：堆區(qū)、永久區(qū) 線程獨(dú)享的：虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器

5.3 內(nèi)存分配機(jī)制：年輕代（Eden區(qū)、兩個(gè)Survivor區(qū)）、年老代、永久代以及他們的分配過(guò)程

5.4 強(qiáng)引用、軟引用、弱引用、虛引用與GC

5.5 happens-before規(guī)則

5.6 指令重排序、內(nèi)存柵欄

5.7 Java 8的內(nèi)存分代改進(jìn)

5.8 垃圾回收算法：

標(biāo)記-清除（不足之處：效率不高、內(nèi)存碎片）

復(fù)制算法（解決了上述問(wèn)題，但是內(nèi)存只能使用一半，針對(duì)大部分對(duì)象存活時(shí)間短的場(chǎng)景，引出了一個(gè)默認(rèn)的8:1:1的改進(jìn)，缺點(diǎn)是仍然需要借助外界來(lái)解決可能承載不下的問(wèn)題）

標(biāo)記整理

5.8 常用垃圾收集器：

新生代：Serial收集器、ParNew收集器、Parallel Scavenge 收集器

老年代：Serial Old收集器、Parallel Old收集器、CMS（Concurrent Mark Sweep）收集器、 G1 收集器（跨新生代和老年代）

5.9 常用gc的參數(shù)：-Xmn、-Xms、-Xmx、-XX:MaxPermSize、-XX:SurvivorRatio、-XX:-PrintGCDetails

5.10 常用工具： jps、jstat、jmap、jstack、圖形工具jConsole、Visual VM、MAT

1.6 鎖以及并發(fā)容器的源碼

6.1 synchronized和volatile理解

6.2 Unsafe類的原理，使用它來(lái)實(shí)現(xiàn)CAS。因此誕生了AtomicInteger系列等

6.3 CAS可能產(chǎn)生的ABA問(wèn)題的解決，如加入修改次數(shù)、版本號(hào)

6.4 同步器AQS的實(shí)現(xiàn)原理

6.5 獨(dú)占鎖、共享鎖；可重入的獨(dú)占鎖ReentrantLock、共享鎖 實(shí)現(xiàn)原理

6.6 公平鎖和非公平鎖

6.7 讀寫鎖 ReentrantReadWriteLock的實(shí)現(xiàn)原理

6.8 LockSupport工具

6.9 Condition接口及其實(shí)現(xiàn)原理

6.10 HashMap、HashSet、ArrayList、LinkedList、HashTable、ConcurrentHashMap、TreeMap的實(shí)現(xiàn)原理

6.11 HashMap的并發(fā)問(wèn)題

6.12 ConcurrentLinkedQueue的實(shí)現(xiàn)原理

6.13 Fork/Join框架

6.14 CountDownLatch和CyclicBarrier

1.7 線程池源碼

7.1 內(nèi)部執(zhí)行原理

7.2 各種線程池的區(qū)別

2 web方面：

2.1 SpringMVC的架構(gòu)設(shè)計(jì)

1.1 servlet開(kāi)發(fā)存在的問(wèn)題：映射問(wèn)題、參數(shù)獲取問(wèn)題、格式化轉(zhuǎn)換問(wèn)題、返回值處理問(wèn)題、視圖渲染問(wèn)題

1.2 SpringMVC為解決上述問(wèn)題開(kāi)發(fā)的幾大組件及接口：HandlerMapping、HandlerAdapter、HandlerMethodArgumentResolver、HttpMessageConverter、Converter、GenericConverter、HandlerMethodReturnValueHandler、ViewResolver、MultipartResolver

1.3 DispatcherServlet、容器、組件三者之間的關(guān)系

1.4 敘述SpringMVC對(duì)請(qǐng)求的整體處理流程

1.5 SpringBoot

2.2 SpringAOP源碼

2.1 AOP的實(shí)現(xiàn)分類：編譯期、字節(jié)碼加載前、字節(jié)碼加載后三種時(shí)機(jī)來(lái)實(shí)現(xiàn)AOP

2.2 深刻理解其中的角色：AOP聯(lián)盟、aspectj、jboss AOP、Spring自身實(shí)現(xiàn)的AOP、Spring嵌入aspectj。特別是能用代碼區(qū)分后兩者

2.3 接口設(shè)計(jì)：

AOP聯(lián)盟定義的概念或接口：Pointcut（概念，沒(méi)有定義對(duì)應(yīng)的接口）、Joinpoint、Advice、MethodInterceptor、MethodInvocation

SpringAOP針對(duì)上述Advice接口定義的接口及其實(shí)現(xiàn)類：BeforeAdvice、AfterAdvice、MethodBeforeAdvice、AfterReturningAdvice；針對(duì)aspectj對(duì)上述接口的實(shí)現(xiàn)AspectJMethodBeforeAdvice、AspectJAfterReturningAdvice、AspectJAfterThrowingAdvice、AspectJAfterAdvice。

SpringAOP定義的定義的AdvisorAdapter接口：將上述Advise轉(zhuǎn)化為MethodInterceptor

SpringAOP定義的Pointcut接口：含有兩個(gè)屬性ClassFilter（過(guò)濾類）、MethodMatcher（過(guò)濾方法）

SpringAOP定義的ExpressionPointcut接口：實(shí)現(xiàn)中會(huì)引入aspectj的pointcut表達(dá)式

SpringAOP定義的PointcutAdvisor接口（將上述Advice接口和Pointcut接口結(jié)合起來(lái)）

2.4 SpringAOP的調(diào)用流程

2.5 SpringAOP自己的實(shí)現(xiàn)方式（代表人物ProxyFactoryBean）和借助aspectj實(shí)現(xiàn)方式區(qū)分

2.3 Spring事務(wù)體系源碼以及分布式事務(wù)Jotm Atomikos源碼實(shí)現(xiàn)

3.1 jdbc事務(wù)存在的問(wèn)題

3.2 Hibernate對(duì)事務(wù)的改進(jìn)

3.3 針對(duì)各種各樣的事務(wù)，Spring如何定義事務(wù)體系的接口，以及如何融合jdbc事務(wù)和Hibernate事務(wù)的

3.4 三種事務(wù)模型包含的角色以及各自的職責(zé)

3.5 事務(wù)代碼也業(yè)務(wù)代碼分離的實(shí)現(xiàn)（AOP+ThreadLocal來(lái)實(shí)現(xiàn)）

3.6 Spring事務(wù)攔截器TransactionInterceptor全景

3.7 X/Open DTP模型，兩階段提交，JTA接口定義

3.8 Jotm、Atomikos的實(shí)現(xiàn)原理

3.9 事務(wù)的傳播屬性

3.10 PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED的實(shí)現(xiàn)原理以及區(qū)別

3.11 事物的掛起和恢復(fù)的原理

2.4 數(shù)據(jù)庫(kù)隔離級(jí)別

4.1 Read uncommitted：讀未提交

4.2 Read committed ： 讀已提交

4.3 Repeatable read：可重復(fù)讀

4.4 Serializable ：串行化

2.5 數(shù)據(jù)庫(kù)

5.1 數(shù)據(jù)庫(kù)性能的優(yōu)化

5.2 深入理解mysql的Record Locks、Gap Locks、Next-Key Locks

例如下面的在什么情況下會(huì)出現(xiàn)死鎖：

starttransaction;DELETEFROMtWHEREid=6;INSERTINTOtVALUES(6);commit;

5.3 insert into select語(yǔ)句的加鎖情況

5.4 事務(wù)的ACID特性概念

5.5 innodb的MVCC理解

5.6 undo redo binlog

1 undo redo 都可以實(shí)現(xiàn)持久化，他們的流程是什么？為什么選用redo來(lái)做持久化？

2 undo、redo結(jié)合起來(lái)實(shí)現(xiàn)原子性和持久化，為什么undo log要先于redo log持久化？

3 undo為什么要依賴redo？

4 日志內(nèi)容可以是物理日志，也可以是邏輯日志？他們各自的優(yōu)點(diǎn)和缺點(diǎn)是？

5 redo log最終采用的是物理日志加邏輯日志，物理到page，page內(nèi)邏輯。還存在什么問(wèn)題？怎么解決？Double Write

6 undo log為什么不采用物理日志而采用邏輯日志？

7 為什么要引入Checkpoint？

8 引入Checkpoint后為了保證一致性需要阻塞用戶操作一段時(shí)間，怎么解決這個(gè)問(wèn)題？（這個(gè)問(wèn)題還是很有普遍性的，redis、ZooKeeper都有類似的情況以及不同的應(yīng)對(duì)策略）又有了同步Checkpoint和異步Checkpoint

9 開(kāi)啟binlog的情況下，事務(wù)內(nèi)部2PC的一般過(guò)程（含有2次持久化，redo log和binlog的持久化）

10 解釋上述過(guò)程，為什么binlog的持久化要在redo log之后，在存儲(chǔ)引擎commit之前？

11 為什么要保持事務(wù)之間寫入binlog和執(zhí)行存儲(chǔ)引擎commit操作的順序性？（即先寫入binlog日志的事務(wù)一定先commit）

12 為了保證上述順序性，之前的辦法是加鎖prepare_commit_mutex，但是這極大的降低了事務(wù)的效率，怎么來(lái)實(shí)現(xiàn)binlog的group commit？

13 怎么將redo log的持久化也實(shí)現(xiàn)group commit？至此事務(wù)內(nèi)部2PC的過(guò)程，2次持久化的操作都可以group commit了，極大提高了效率

2.6 ORM框架: mybatis、Hibernate

6.1 最原始的jdbc->Spring的JdbcTemplate->hibernate->JPA->SpringDataJPA的演進(jìn)之路

2.7 SpringSecurity、shiro、SSO（單點(diǎn)登錄）

7.1 Session和Cookie的區(qū)別和聯(lián)系以及Session的實(shí)現(xiàn)原理

7.2 SpringSecurity的認(rèn)證過(guò)程以及與Session的關(guān)系

7.3 CAS實(shí)現(xiàn)SSO（詳見(jiàn)Cas（01）——簡(jiǎn)介）

2.8 日志

8.1 jdk自帶的logging、log4j、log4j2、logback

8.2 門面commons-logging、slf4j

8.3 上述6種混戰(zhàn)時(shí)的日志轉(zhuǎn)換

2.9 datasource

9.1 c3p0

9.2 druid

9.3 JdbcTemplate執(zhí)行sql語(yǔ)句的過(guò)程中對(duì)Connection的使用和管理

2.10 HTTPS的實(shí)現(xiàn)原理

3 分布式、java中間件、web服務(wù)器等方面：

3.1 ZooKeeper源碼

1.1 客戶端架構(gòu)

1.2 服務(wù)器端單機(jī)版和集群版，對(duì)應(yīng)的請(qǐng)求處理器

1.3 集群版session的建立和激活過(guò)程

1.4 Leader選舉過(guò)程

1.5 事務(wù)日志和快照文件的詳細(xì)解析

1.6 實(shí)現(xiàn)分布式鎖、分布式ID分發(fā)器

1.7 實(shí)現(xiàn)Leader選舉

1.8 ZAB協(xié)議實(shí)現(xiàn)一致性原理

3.2 序列化和反序列化框架

2.1 Avro研究

2.2 Thrift研究

2.3 Protobuf研究

2.4 Protostuff研究

2.5 Hessian

3.3 RPC框架dubbo源碼

3.1 dubbo擴(kuò)展機(jī)制的實(shí)現(xiàn)，對(duì)比SPI機(jī)制

3.2 服務(wù)的發(fā)布過(guò)程

3.3 服務(wù)的訂閱過(guò)程

3.4 RPC通信的設(shè)計(jì)

3.4 NIO模塊以及對(duì)應(yīng)的Netty和Mina、thrift源碼

4.1 TCP握手和斷開(kāi)及有限狀態(tài)機(jī)

4.2 backlog

4.3 BIO NIO

4.4 阻塞/非阻塞的區(qū)別、同步/異步的區(qū)別

4.5 阻塞IO、非阻塞IO、多路復(fù)用IO、異步IO

4.6 Reactor線程模型

4.7 jdk的poll、epoll與底層poll、epoll的對(duì)接實(shí)現(xiàn)

4.8 Netty自己的epoll實(shí)現(xiàn)

4.9 內(nèi)核層poll、epoll的大致實(shí)現(xiàn)

4.10 epoll的邊緣觸發(fā)和水平觸發(fā)

4.11 Netty的EventLoopGroup設(shè)計(jì)

4.12 Netty的ByteBuf設(shè)計(jì)

4.13 Netty的ChannelHandler

4.13 Netty的零拷貝

4.14 Netty的線程模型，特別是與業(yè)務(wù)線程以及資源釋放方面的理解

3.5 消息隊(duì)列kafka、RocketMQ、Notify、Hermes

5.1 kafka的文件存儲(chǔ)設(shè)計(jì)

5.2 kafka的副本復(fù)制過(guò)程

5.3 kafka副本的leader選舉過(guò)程

5.4 kafka的消息丟失問(wèn)題

5.5 kafka的消息順序性問(wèn)題

5.6 kafka的isr設(shè)計(jì)和過(guò)半對(duì)比

5.7 kafka本身做的很輕量級(jí)來(lái)保持高效，很多高級(jí)特性沒(méi)有：事務(wù)、優(yōu)先級(jí)的消息、消息的過(guò)濾，更重要的是服務(wù)治理不健全，一旦出問(wèn)題，不能直觀反應(yīng)出來(lái)，不太適合對(duì)數(shù)據(jù)要求十分嚴(yán)苛的企業(yè)級(jí)系統(tǒng)，而適合日志之類并發(fā)量大但是允許少量的丟失或重復(fù)等場(chǎng)景

5.8 Notify、RocketMQ的事務(wù)設(shè)計(jì)

5.9 基于文件的kafka、RocketMQ和基于數(shù)據(jù)庫(kù)的Notify和Hermes

5.10 設(shè)計(jì)一個(gè)消息系統(tǒng)要考慮哪些方面

5.11 丟失消息、消息重復(fù)、高可用等話題

3.6 數(shù)據(jù)庫(kù)的分庫(kù)分表mycat

3.7 NoSql數(shù)據(jù)庫(kù)mongodb

3.8 KV鍵值系統(tǒng)memcached redis

8.1 redis對(duì)客戶端的維護(hù)和管理，讀寫緩沖區(qū)

8.2 redis事務(wù)的實(shí)現(xiàn)

8.3 Jedis客戶端的實(shí)現(xiàn)

8.4 JedisPool以及ShardedJedisPool的實(shí)現(xiàn)

8.5 redis epoll實(shí)現(xiàn)，循環(huán)中的文件事件和時(shí)間事件

8.6 redis的RDB持久化，save和bgsave

8.7 redis AOF命令追加、文件寫入、文件同步到磁盤

8.8 redis AOF重寫，為了減少阻塞時(shí)間采取的措施

8.9 redis的LRU內(nèi)存回收算法

8.10 redis的master slave復(fù)制

8.11 redis的sentinel高可用方案

8.12 redis的cluster分片方案

3.9 web服務(wù)器tomcat、ngnix的設(shè)計(jì)原理

9.1 tomcat的整體架構(gòu)設(shè)計(jì)

9.2 tomcat對(duì)通信的并發(fā)控制

9.3 http請(qǐng)求到達(dá)tomcat的整個(gè)處理流程

3.10 ELK日志實(shí)時(shí)處理查詢系統(tǒng)

10.1 Elasticsearch、Logstash、Kibana

3.11 服務(wù)方面

11.1 SOA與微服務(wù)

11.2 服務(wù)的合并部署、多版本自動(dòng)快速切換和回滾

詳見(jiàn)基于Java容器的多應(yīng)用部署技術(shù)實(shí)踐

11.3 服務(wù)的治理：限流、降級(jí)

具體見(jiàn)?張開(kāi)濤大神的架構(gòu)系列

服務(wù)限流：令牌桶、漏桶

服務(wù)降級(jí)、服務(wù)的熔斷、服務(wù)的隔離：netflix的hystrix組件

11.4 服務(wù)的線性擴(kuò)展

無(wú)狀態(tài)的服務(wù)如何做線性擴(kuò)展：

如一般的web應(yīng)用，直接使用硬件或者軟件做負(fù)載均衡，簡(jiǎn)單的輪訓(xùn)機(jī)制

有狀態(tài)服務(wù)如何做線性擴(kuò)展：

如Redis的擴(kuò)展：一致性hash，遷移工具

11.5 服務(wù)鏈路監(jiān)控和報(bào)警：CAT、Dapper、Pinpoint

3.12 Spring Cloud

12.1 Spring Cloud Zookeeper:用于服務(wù)注冊(cè)和發(fā)現(xiàn)

12.2 Spring Cloud Config:分布式配置

12.2 Spring Cloud Netflix Eureka：用于rest服務(wù)的注冊(cè)和發(fā)現(xiàn)

12.3 Spring Cloud Netflix Hystrix：服務(wù)的隔離、熔斷和降級(jí)

12.4 Spring Cloud Netflix Zuul:動(dòng)態(tài)路由，API Gateway

3.13 分布式事務(wù)

13.1 JTA分布式事務(wù)接口定義，對(duì)此與Spring事務(wù)體系的整合

13.2 TCC分布式事務(wù)概念

13.3 TCC分布式事務(wù)實(shí)現(xiàn)框架案例1：tcc-transaction

13.3.1 TccCompensableAspect切面攔截創(chuàng)建ROOT事務(wù)

13.3.2 TccTransactionContextAspect切面使遠(yuǎn)程RPC調(diào)用資源加入到上述事務(wù)中，作為一個(gè)參與者

13.3.3 TccCompensableAspect切面根據(jù)遠(yuǎn)程RPC傳遞的TransactionContext的標(biāo)記創(chuàng)建出分支事務(wù)

13.3.4 全部RPC調(diào)用完畢，ROOT事務(wù)開(kāi)始提交或者回滾，執(zhí)行所有參與者的提交或回滾

13.3.5 所有參與者的提交或者回滾，還是通過(guò)遠(yuǎn)程RPC調(diào)用，provider端開(kāi)始執(zhí)行對(duì)應(yīng)分支事務(wù)的confirm或者cancel方法

13.3.6 事務(wù)的存儲(chǔ)，集群共享問(wèn)題

13.3.7 事務(wù)的恢復(fù)，避免集群重復(fù)恢復(fù)

13.4 TCC分布式事務(wù)實(shí)現(xiàn)框架案例2：ByteTCC

13.4.1 JTA事務(wù)管理實(shí)現(xiàn)，類比Jotm、Atomikos等JTA實(shí)現(xiàn)

13.4.2 事務(wù)的存儲(chǔ)和恢復(fù)，集群是否共享問(wèn)題

調(diào)用方創(chuàng)建CompensableTransaction事務(wù)，并加入資源

13.4.3 CompensableMethodInterceptor攔截器向spring事務(wù)注入CompensableInvocation資源

13.4.4 Spring的分布式事務(wù)管理器創(chuàng)建作為協(xié)調(diào)者CompensableTransaction類型事務(wù)，和當(dāng)前線程進(jìn)行綁定，同時(shí)創(chuàng)建一個(gè)jta事務(wù)

13.4.5 在執(zhí)行sql等操作的時(shí)候，所使用的jdbc等XAResource資源加入上述jta事務(wù)

13.4.6 dubbo RPC遠(yuǎn)程調(diào)用前，CompensableDubboServiceFilter創(chuàng)建出一個(gè)代理XAResource，加入上述CompensableTransaction類型事務(wù)，并在RPC調(diào)用過(guò)程傳遞TransactionContext

參與方創(chuàng)建分支的CompensableTransaction事務(wù)，并加入資源，然后提交jta事務(wù)

13.4.7 RPC遠(yuǎn)程調(diào)用來(lái)到provider端，CompensableDubboServiceFilter根據(jù)傳遞過(guò)來(lái)的TransactionContext創(chuàng)建出對(duì)應(yīng)的CompensableTransaction類型事務(wù)

13.4.8 provider端，執(zhí)行時(shí)遇見(jiàn)@Transactional和@Compensable，作為一個(gè)參與者開(kāi)啟try階段的事務(wù)，即創(chuàng)建了一個(gè)jta事務(wù)

13.4.9 provider端try執(zhí)行完畢開(kāi)始準(zhǔn)備try的提交，僅僅是提交上述jta事務(wù)，返回結(jié)果到RPC調(diào)用端

調(diào)用方?jīng)Q定回滾還是提交

13.4.10 全部執(zhí)行完畢后開(kāi)始事務(wù)的提交或者回滾，如果是提交則先對(duì)jta事務(wù)進(jìn)行提交（包含jdbc等XAResource資源的提交），提交成功后再對(duì)CompensableTransaction類型事務(wù)進(jìn)行提交，如果jta事務(wù)提交失敗，則需要回滾CompensableTransaction類型事務(wù)。

13.4.11 CompensableTransaction類型事務(wù)的提交就是對(duì)CompensableInvocation資源和RPC資源的提交，分別調(diào)用每一個(gè)CompensableInvocation資源的confirm，以及每一個(gè)RPC資源的提交

CompensableInvocation資源的提交

13.4.12 此時(shí)每一個(gè)CompensableInvocation資源的confirm又會(huì)準(zhǔn)備開(kāi)啟一個(gè)新的事務(wù)，當(dāng)前線程的CompensableTransaction類型事務(wù)已存在，所以這里開(kāi)啟事務(wù)僅僅是創(chuàng)建了一個(gè)新的jta事務(wù)而已

13.4.13 針對(duì)此，每一個(gè)CompensableInvocation資源的confirm開(kāi)啟的事務(wù)，又開(kāi)始重復(fù)上述過(guò)程，對(duì)于jdbc等資源都加入新創(chuàng)建的jta事務(wù)中，而RPC資源和CompensableInvocation資源仍然加入到當(dāng)前線程綁定的CompensableTransaction類型事務(wù)

13.4.14 當(dāng)前CompensableInvocation資源的confirm開(kāi)啟的事務(wù)執(zhí)行完畢后，開(kāi)始執(zhí)行commit,此時(shí)仍然是執(zhí)行jta事務(wù)的提交，提交完畢，一個(gè)CompensableInvocation資源的confirm完成，繼續(xù)執(zhí)行下一個(gè)CompensableInvocation資源的confirm，即又要重新開(kāi)啟一個(gè)新的jta事務(wù)

RPC資源的提交（參與方CompensableTransaction事務(wù)的提交）

13.4.15 當(dāng)所有CompensableInvocation資源的confirm執(zhí)行完畢，開(kāi)始執(zhí)行RPC資源的commit，會(huì)進(jìn)行遠(yuǎn)程調(diào)用，執(zhí)行遠(yuǎn)程provider分支事務(wù)的提交，遠(yuǎn)程調(diào)用過(guò)程會(huì)傳遞事務(wù)id

13.4.16 provider端，根據(jù)傳遞過(guò)來(lái)的事務(wù)id找到對(duì)應(yīng)的CompensableTransaction事務(wù)，開(kāi)始執(zhí)行提交操作，提交操作完成后返回響應(yīng)

結(jié)束

13.4.17 協(xié)調(diào)者收到響應(yīng)后繼續(xù)執(zhí)行下一個(gè)RPC資源的提交，當(dāng)所有RPC資源也完成相應(yīng)的提交，則協(xié)調(diào)者算是徹底完成該事務(wù)

3.14 一致性算法

14.1 raft（詳見(jiàn)Raft算法賞析）

14.1.1 leader選舉過(guò)程，leader選舉約束，要包含所有commited entries，實(shí)現(xiàn)上log比過(guò)半的log都最新即可

14.1.2 log復(fù)制過(guò)程，leader給所有的follower發(fā)送AppendEntries RPC請(qǐng)求，過(guò)半follower回復(fù)ok，則可提交該entry，然后向客戶端響應(yīng)OK

14.1.3 在上述leader收到過(guò)半復(fù)制之后，掛了，則后續(xù)leader不能直接對(duì)這些之前term的過(guò)半entry進(jìn)行提交（這一部分有詳細(xì)的案例來(lái)證明，并能說(shuō)出根本原因），目前做法是在當(dāng)前term中創(chuàng)建空的entry，然后如果這些新創(chuàng)建的entry被大部分復(fù)制了，則此時(shí)就可以對(duì)之前term的過(guò)半entry進(jìn)行提交了

14.1.4 leader一旦認(rèn)為某個(gè)term可以提交了，則更新自己的commitIndex，同時(shí)應(yīng)用entry到狀態(tài)機(jī)中，然后在下一次與follower的heartbeat通信中，將leader的commitIndex帶給follower，讓他們進(jìn)行更新，同時(shí)應(yīng)用entry到他們的狀態(tài)機(jī)中

14.1.5 從上述流程可以看到，作為client來(lái)說(shuō)，可能會(huì)出現(xiàn)這樣的情況：leader認(rèn)為某次client的請(qǐng)求可以提交了（對(duì)應(yīng)的entry已經(jīng)被過(guò)半復(fù)制了），此時(shí)leader掛了，還沒(méi)來(lái)得及給client回復(fù)，也就是說(shuō)對(duì)client來(lái)說(shuō)，請(qǐng)求雖然失敗了，但是請(qǐng)求對(duì)應(yīng)的entry卻被持久化保存了，但是有的時(shí)候卻是請(qǐng)求失敗了（過(guò)半都沒(méi)復(fù)制成功）沒(méi)有持久化成功，也就是說(shuō)請(qǐng)求失敗了，服務(wù)器端可能成功了也可能失敗了。所以這時(shí)候需要在client端下功夫，即cleint端重試的時(shí)候仍然使用之前的請(qǐng)求數(shù)據(jù)進(jìn)行重試，而不是采用新的數(shù)據(jù)進(jìn)行重試，服務(wù)器端也必須要實(shí)現(xiàn)冪等。

14.1.6 Cluster membership changes

14.2 ZooKeeper使用的ZAB協(xié)議（詳見(jiàn)ZooKeeper的一致性算法賞析）

14.2.1 leader選舉過(guò)程。要點(diǎn)：對(duì)于不同狀態(tài)下的server的投票的收集，投票是需要選舉出一個(gè)包含所有日志的server來(lái)作為leader

14.2.2 leader和follower數(shù)據(jù)同步過(guò)程，全量同步、差異同步、日志之間的糾正和截?cái)啵瑏?lái)保證和leader之間的一致性。以及follower加入已經(jīng)完成選舉的系統(tǒng)，此時(shí)的同步的要點(diǎn)：阻塞leader處理寫請(qǐng)求，完成日志之間的差異同步，還要處理現(xiàn)有進(jìn)行中的請(qǐng)求的同步，完成同步后，解除阻塞。

14.2.3 廣播階段，即正常處理客戶端的請(qǐng)求，過(guò)半響應(yīng)即可回復(fù)客戶端。

14.2.4 日志的恢復(fù)和持久化。持久化：每隔一定數(shù)量的事務(wù)日志持久化一次，leader選舉前持久化一次。恢復(fù)：簡(jiǎn)單的認(rèn)為已寫入日志的的事務(wù)請(qǐng)求都算作已提交的請(qǐng)求（不管之前是否已過(guò)半復(fù)制），全部執(zhí)行commit提交。具體的恢復(fù)是：先恢復(fù)快照日志，然后再應(yīng)用相應(yīng)的事務(wù)日志

14.3 paxos（詳見(jiàn)paxos算法證明過(guò)程）

14.3.1 paxos的運(yùn)作過(guò)程：

Phase 1: (a) 一個(gè)proposer選擇一個(gè)編號(hào)為n的議案，向所有的acceptor發(fā)送prepare請(qǐng)求

Phase 1: (b) 如果acceptor已經(jīng)響應(yīng)的prepare請(qǐng)求中議案編號(hào)都比n小，則它承諾不再響應(yīng)prepare請(qǐng)求或者accept請(qǐng)求中議案編號(hào)小于n的， 并且找出已經(jīng)accept的最大議案的value返回給該proposer。如果已響應(yīng)的編號(hào)比n大，則直接忽略該prepare請(qǐng)求。

Phase 2：(a) 如果proposer收到了過(guò)半的acceptors響應(yīng)，那么將提出一個(gè)議案（n，v）,v就是上述所有acceptor響應(yīng)中最大accept議案的value，或者是proposer自己的value。然后將該議案發(fā)送給所有的acceptor。這個(gè)請(qǐng)求叫做accept請(qǐng)求，這一步才是所謂發(fā)送議案請(qǐng)求，而前面的prepare請(qǐng)求更多的是一個(gè)構(gòu)建出最終議案(n,v)的過(guò)程。

Phase 2：(b) acceptor接收到編號(hào)為n的議案，如果acceptor還沒(méi)有對(duì)大于n的議案的prepare請(qǐng)求響應(yīng)過(guò)，則acceptor就accept該議案，否則拒絕

14.3.2 paxos的證明過(guò)程：

1 足夠多的問(wèn)題

2 acceptor的初始accept

3 P2-對(duì)結(jié)果要求

4 P2a-對(duì)acceptor的accept要求

5 P2b-對(duì)proposer提出議案的要求（結(jié)果上要求）

6 P2c-對(duì)proposer提出議案的要求（做法上要求）

7 引出prepare過(guò)程和P1a

8 8 優(yōu)化prepare

14.3.3 base paxos和multi-paxos

4 大數(shù)據(jù)方向

4.1 Hadoop

1.1 UserGroupInformation源碼解讀：JAAS認(rèn)證、user和group關(guān)系的維護(hù)

1.2 RPC通信的實(shí)現(xiàn)

1.3 代理用戶的過(guò)程

1.4 kerberos認(rèn)證

4.2 MapReduce

2.1 MapReduce理論及其對(duì)應(yīng)的接口定義

4.3 HDFS

3.1 MapFile、SequenceFile

3.2 ACL

4.4 YARN、Mesos 資源調(diào)度

4.5 oozie

5.1 oozie XCommand設(shè)計(jì)

5.2 DagEngine的實(shí)現(xiàn)原理

4.6 Hive

6.1 HiveServer2、metatore的thrift RPC通信設(shè)計(jì)

6.2 Hive的優(yōu)化過(guò)程

6.3 HiveServer2的認(rèn)證和授權(quán)

6.4 metastore的認(rèn)證和授權(quán)

6.5 HiveServer2向metatore的用戶傳遞過(guò)程

4.7 Hbase

7.1 Hbase的整體架構(gòu)圖

7.2 Hbase的WAL和MVCC設(shè)計(jì)

7.3 client端的異步批量flush尋找RegionServer的過(guò)程

7.4 Zookeeper上HBase節(jié)點(diǎn)解釋

7.5 Hbase中的mini、major合并

7.6 Region的高可用問(wèn)題對(duì)比kafka分區(qū)的高可用實(shí)現(xiàn)

7.7 RegionServer RPC調(diào)用的隔離問(wèn)題

7.8 數(shù)據(jù)從內(nèi)存刷寫到HDFS的粒度問(wèn)題

7.9 rowKey的設(shè)計(jì)

7.10 MemStore與LSM

4.8 Spark

8.1 不同的部署方式

8.2 SparkSql的實(shí)現(xiàn)方式

8.3 。。。