java技術(shù)棧

java技術(shù)棧

參考了眾多資料驱闷，這里就不再詳細(xì)列舉了，可以自行去搜索

1 java基礎(chǔ)：

1.1 算法

1.1 排序算法：直接插入排序扼菠、希爾排序、冒泡排序析恢、快速排序映挂、直接選擇排序、堆排序鞍时、歸并排序逆巍、基數(shù)排序

1.2 二叉查找樹蒸苇、紅黑樹溪烤、B樹、B+樹鸳兽、LSM樹（分別有對應(yīng)的應(yīng)用揍异，數(shù)據(jù)庫衷掷、HBase）

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

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)鍵字的底層實現(xiàn)原理

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

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

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

1.3 設(shè)計模式

單例模式

工廠模式

裝飾者模式

觀察者設(shè)計模式

ThreadLocal設(shè)計模式

。

1.4 正則表達(dá)式

4.1 捕獲組和非捕獲組

4.2 貪婪登夫，勉強(qiáng)恼策，獨占模式

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

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

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

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

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

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ù)制算法（解決了上述問題，但是內(nèi)存只能使用一半猎荠，針對大部分對象存活時間短的場景坚弱，引出了一個默認(rèn)的8:1:1的改進(jì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類的原理穴店，使用它來實現(xiàn)CAS球凰。因此誕生了AtomicInteger系列等

6.3 CAS可能產(chǎn)生的ABA問題的解決规肴，如加入修改次數(shù)删壮、版本號

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

6.5 獨占鎖粘秆、共享鎖；可重入的獨占鎖ReentrantLock、共享鎖 實現(xiàn)原理

6.6 公平鎖和非公平鎖

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

6.8 LockSupport工具

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

6.10 HashMap坤溃、HashSet、ArrayList军拟、LinkedList姜盈、HashTable告喊、ConcurrentHashMap、TreeMap的實現(xiàn)原理

6.11 HashMap的并發(fā)問題

6.12 ConcurrentLinkedQueue的實現(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è)計

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

1.2 SpringMVC為解決上述問題開發(fā)的幾大組件及接口：HandlerMapping漫拭、HandlerAdapter汰翠、HandlerMethodArgumentResolver攒盈、HttpMessageConverter谆吴、Converter、GenericConverter凰兑、HandlerMethodReturnValueHandler捶枢、ViewResolver、MultipartResolver

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

1.4 敘述SpringMVC對請求的整體處理流程

1.5 SpringBoot

2.2 SpringAOP源碼

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

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

2.3 接口設(shè)計：

AOP聯(lián)盟定義的概念或接口：Pointcut（概念句旱，沒有定義對應(yīng)的接口）光稼、Joinpoint或南、Advice、MethodInterceptor艾君、MethodInvocation

SpringAOP針對上述Advice接口定義的接口及其實現(xiàn)類：BeforeAdvice采够、AfterAdvice、MethodBeforeAdvice腻贰、AfterReturningAdvice吁恍；針對aspectj對上述接口的實現(xiàn)AspectJMethodBeforeAdvice扒秸、AspectJAfterReturningAdvice播演、AspectJAfterThrowingAdvice、AspectJAfterAdvice伴奥。

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

SpringAOP定義的Pointcut接口：含有兩個屬性ClassFilter（過濾類）写烤、MethodMatcher（過濾方法）

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

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

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

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

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

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

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

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

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

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

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

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

3.8 Jotm尼啡、Atomikos的實現(xiàn)原理

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

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

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

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

4.1 Read uncommitted：讀未提交

4.2 Read committed ： 讀已提交

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

4.4 Serializable ：串行化

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

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

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

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

start transaction; DELETE FROM t WHERE id =6; INSERT INTO t VALUES(6); commit;

5.3 insert into select語句的加鎖情況

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

5.5 innodb的MVCC理解

5.6 undo redo binlog

1 undo redo 都可以實現(xiàn)持久化狂巢，他們的流程是什么？為什么選用redo來做持久化书聚？

2 undo唧领、redo結(jié)合起來實現(xiàn)原子性和持久化，為什么undo log要先于redo log持久化雌续？

3 undo為什么要依賴redo斩个？

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

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

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

7 為什么要引入Checkpoint？

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

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

10 解釋上述過程，為什么binlog的持久化要在redo log之后温学，在存儲引擎commit之前略贮？

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

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

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

2.6 ORM框架: mybatis拄丰、Hibernate

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

2.7 SpringSecurity、shiro俐末、SSO（單點登錄）

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

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

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

2.8 日志

8.1 jdk自帶的logging料按、log4j、log4j2卓箫、logback

8.2 門面commons-logging载矿、slf4j

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

2.9 datasource

9.1 c3p0

9.2 druid

9.3 JdbcTemplate執(zhí)行sql語句的過程中對Connection的使用和管理

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

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

3.1 ZooKeeper源碼

1.1 客戶端架構(gòu)

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

1.3 集群版session的建立和激活過程

1.4 Leader選舉過程

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

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

1.7 實現(xiàn)Leader選舉

1.8 ZAB協(xié)議實現(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ī)制的實現(xiàn)甫题，對比SPI機(jī)制

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

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

3.4 RPC通信的設(shè)計

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

4.1 TCP握手和斷開及有限狀態(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的對接實現(xiàn)

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

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

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

4.11 Netty的EventLoopGroup設(shè)計

4.12 Netty的ByteBuf設(shè)計

4.13 Netty的ChannelHandler

4.13 Netty的零拷貝

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

3.5 消息隊列kafka攒菠、RocketMQ、Notify歉闰、Hermes

5.1 kafka的文件存儲設(shè)計

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

5.3 kafka副本的leader選舉過程

5.4 kafka的消息丟失問題

5.5 kafka的消息順序性問題

5.6 kafka的isr設(shè)計和過半對比

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

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

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

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

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

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

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

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

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

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

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

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

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

8.6 redis的RDB持久化铝耻，save和bgsave

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

8.8 redis AOF重寫瓢捉，為了減少阻塞時間采取的措施

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è)計原理

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

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

9.3 http請求到達(dá)tomcat的整個處理流程

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

10.1 Elasticsearch、Logstash泡态、Kibana

3.11 服務(wù)方面

11.1 SOA與微服務(wù)

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

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

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

具體見張開濤大神的架構(gòu)系列

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

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

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

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

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

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

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

11.5 服務(wù)鏈路監(jiān)控和報警：CAT腾降、Dapper拣度、Pinpoint

3.12 Spring Cloud

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

12.2 Spring Cloud Config:分布式配置

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

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

12.4 Spring Cloud Netflix Zuul:動態(tài)路由螃壤，API Gateway

3.13 分布式事務(wù)

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

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

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

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

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

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

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

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

13.3.6 事務(wù)的存儲逮光，集群共享問題13.3.7 事務(wù)的恢復(fù)赘淮，避免集群重復(fù)恢復(fù)

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

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

13.4.2 事務(wù)的存儲和恢復(fù)梢卸，集群是否共享問題調(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)行綁定蛤高，同時創(chuàng)建一個jta事務(wù)

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

13.4.6 dubbo RPC遠(yuǎn)程調(diào)用前碑幅，CompensableDubboServiceFilter創(chuàng)建出一個代理XAResource戴陡，加入上述 CompensableTransaction類型事務(wù)，并在RPC調(diào)用過程傳遞TransactionContext參與方創(chuàng)建分支的CompensableTransaction事務(wù)沟涨，并加入資源恤批，然后提交jta事務(wù)

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

13.4.8 provider端裹赴，執(zhí)行時遇見@Transactional和@Compensable喜庞，作為一個參與者開啟try階段的事務(wù)，即創(chuàng)建了一個jta事務(wù)

13.4.9 provider端try執(zhí)行完畢開始準(zhǔn)備try的提交棋返，僅僅是提交上述jta事務(wù)延都，返回結(jié)果到RPC調(diào)用端調(diào)用方?jīng)Q定回滾還是提交

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

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

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

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

13.4.14 當(dāng)前CompensableInvocation資源的confirm開啟的事務(wù)執(zhí)行完畢后扁位，開始執(zhí)行commit,此時仍然是執(zhí)行jta事務(wù)的提交准潭，提交完畢，一個CompensableInvocation資源的confirm完成域仇，繼續(xù)執(zhí)行下一個CompensableInvocation資源的confirm刑然，即又要重新開啟一個新的jta事務(wù)RPC資源的提交（參與方CompensableTransaction事務(wù)的提交）

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

13.4.16 provider端第美，根據(jù)傳遞過來的事務(wù)id找到對應(yīng)的CompensableTransaction事務(wù)崩掘，開始執(zhí)行提交操作臀晃，提交操作完成后返回響應(yīng)結(jié)束

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

3.14 一致性算法

14.1 raft（詳見Raft算法賞析）

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

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

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

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

14.1.5 從上述流程可以看到，作為client來說爱榔，可能會出現(xiàn)這樣的情況：leader認(rèn)為某次client的請求可以提交了（對應(yīng)的entry已經(jīng)被過半復(fù)制了）被环，此時leader掛了，還沒來得及給client回復(fù)详幽，也就是說對client來說筛欢，請求雖然失敗了，但是請求對應(yīng)的entry卻被持久化保存了唇聘，但是有的時候卻是請求失敗了（過半都沒復(fù)制成功）沒有持久化成功版姑，也就是說請求失敗了，服務(wù)器端可能成功了也可能失敗了迟郎。所以這時候需要在client端下功夫剥险，即cleint端重試的時候仍然使用之前的請求數(shù)據(jù)進(jìn)行重試，而不是采用新的數(shù)據(jù)進(jìn)行重試宪肖，服務(wù)器端也必須要實現(xiàn)冪等表制。

14.1.6 Cluster membership changes

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

14.2.1 leader選舉過程健爬。要點：對于不同狀態(tài)下的server的投票的收集，投票是需要選舉出一個包含所有日志的server來作為leader

14.2.2 leader和follower數(shù)據(jù)同步過程么介，全量同步娜遵、差異同步、日志之間的糾正和截斷壤短，來保證和leader之間的一致性魔熏。以及follower加入已經(jīng)完成選舉的系統(tǒng)，此時的同步的要點：阻塞leader處理寫請求鸽扁，完成日志之間的差異同步蒜绽，還要處理現(xiàn)有進(jìn)行中的請求的同步，完成同步后桶现，解除阻塞躲雅。

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

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

14.3 paxos（詳見paxos算法證明過程）

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

Phase 1: (a) 一個proposer選擇一個編號為n的議案休里，向所有的acceptor發(fā)送prepare請求

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

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

Phase 2：(b) acceptor接收到編號為n的議案，如果acceptor還沒有對大于n的議案的prepare請求響應(yīng)過，則acceptor就accept該議案修己，否則拒絕

14.3.2 paxos的證明過程：

1 足夠多的問題

2 acceptor的初始accept

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

4 P2a-對acceptor的accept要求

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

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

7 引出prepare過程和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通信的實現(xiàn)

1.3 代理用戶的過程

1.4 kerberos認(rèn)證

4.2 MapReduce

2.1 MapReduce理論及其對應(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è)計

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

4.6 Hive

6.1 HiveServer2片仿、metatore的thrift RPC通信設(shè)計

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

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

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

6.5 HiveServer2向metatore的用戶傳遞過程

4.7 Hbase

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

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

7.3 client端的異步批量flush尋找RegionServer的過程

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

7.5 Hbase中的mini、major合并

7.6 Region的高可用問題對比kafka分區(qū)的高可用實現(xiàn)

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

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

7.9 rowKey的設(shè)計

7.10 MemStore與LSM