轉(zhuǎn)載自?http://www.cnblogs.com/thingk/p/6813045.html

以下摘自http://www.tvtv223.com/so/8/default/8.html#36-數(shù)據(jù)庫(kù)的分庫(kù)分表mycat

java技術(shù)棧

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

1 java基礎(chǔ)：

1.1 算法

• 1.1 排序算法：直接插入排序、希爾排序、冒泡排序、快速排序、直接選擇排序、堆排序、歸并排序、基數(shù)排序
• 1.2 二叉查找樹、紅黑樹、B樹、B+樹、LSM樹（分別有對(duì)應(yīng)的應(yīng)用，數(shù)據(jù)庫(kù)、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)鍵字的底層實(shí)現(xiàn)原理
• 2.10 Collections.sort方法使用的是哪種排序方法
• 2.11 Future接口，常見的線程池中的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ū)）、年老代、永久代以及他們的分配過程

• 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)存只能使用一半，針對(duì)大部分對(duì)象存活時(shí)間短的場(chǎng)景，引出了一個(gè)默認(rèn)的8:1:1的改進(jìn)，缺點(diǎn)是仍然需要借助外界來(lái)解決可能承載不下的問題）

  標(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問題的解決，如加入修改次數(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ā)問題
• 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開發(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對(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（概念，沒有定義對(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（過濾類）、MethodMatcher（過濾方法）

  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ù)存在的問題
• 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)死鎖：

  start transaction; DELETE FROM t WHERE id =6; INSERT INTO t VALUES(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)邏輯。還存在什么問題？怎么解決？Double Write
  • 6 undo log為什么不采用物理日志而采用邏輯日志？
  • 7 為什么要引入Checkpoint？
  • 8 引入Checkpoint后為了保證一致性需要阻塞用戶操作一段時(shí)間，怎么解決這個(gè)問題？（這個(gè)問題還是很有普遍性的，redis、ZooKeeper都有類似的情況以及不同的應(yīng)對(duì)策略）又有了同步Checkpoint和異步Checkpoint
  • 9 開啟binlog的情況下，事務(wù)內(nèi)部2PC的一般過程（含有2次持久化，redo log和binlog的持久化）
  • 10 解釋上述過程，為什么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的過程，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)證過程以及與Session的關(guān)系
• 7.3 CAS實(shí)現(xiàn)SSO（詳見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ǔ)句的過程中對(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的建立和激活過程
• 1.4 Leader選舉過程
• 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ā)布過程
• 3.3 服務(wù)的訂閱過程
• 3.4 RPC通信的設(shè)計(jì)

3.4 NIO模塊以及對(duì)應(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的對(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ù)制過程
• 5.3 kafka副本的leader選舉過程
• 5.4 kafka的消息丟失問題
• 5.5 kafka的消息順序性問題
• 5.6 kafka的isr設(shè)計(jì)和過半對(duì)比
• 5.7 kafka本身做的很輕量級(jí)來(lái)保持高效，很多高級(jí)特性沒有：事務(wù)、優(yōu)先級(jí)的消息、消息的過濾，更重要的是服務(wù)治理不健全，一旦出問題，不能直觀反應(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)快速切換和回滾

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

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

具體見?張開濤大神的架構(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ù)開始提交或者回滾，執(zhí)行所有參與者的提交或回滾
• 13.3.5 所有參與者的提交或者回滾，還是通過遠(yuǎn)程RPC調(diào)用，provider端開始執(zhí)行對(duì)應(yīng)分支事務(wù)的confirm或者cancel方法
• 13.3.6 事務(wù)的存儲(chǔ)，集群共享問題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ù)，集群是否共享問題調(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)用過程傳遞TransactionContext參與方創(chuàng)建分支的CompensableTransaction事務(wù)，并加入資源，然后提交jta事務(wù)
• 13.4.7 RPC遠(yuǎn)程調(diào)用來(lái)到provider端，CompensableDubboServiceFilter根據(jù)傳遞過來(lái)的TransactionContext創(chuàng)建出對(duì)應(yīng)的CompensableTransaction類型事務(wù)
• 13.4.8 provider端，執(zhí)行時(shí)遇見@Transactional和@Compensable，作為一個(gè)參與者開啟try階段的事務(wù)，即創(chuàng)建了一個(gè)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ù)的提交或者回滾，如果是提交則先對(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)備開啟一個(gè)新的事務(wù)，當(dāng)前線程的CompensableTransaction類型事務(wù)已存在，所以這里開啟事務(wù)僅僅是創(chuàng)建了一個(gè)新的jta事務(wù)而已
• 13.4.13 針對(duì)此，每一個(gè)CompensableInvocation資源的confirm開啟的事務(wù)，又開始重復(fù)上述過程，對(duì)于jdbc等資源都加入新創(chuàng)建的jta事務(wù)中，而RPC資源和CompensableInvocation資源仍然加入到當(dāng)前線程綁定的CompensableTransaction類型事務(wù)
• 13.4.14 當(dāng)前CompensableInvocation資源的confirm開啟的事務(wù)執(zhí)行完畢后，開始執(zhí)行commit,此時(shí)仍然是執(zhí)行jta事務(wù)的提交，提交完畢，一個(gè)CompensableInvocation資源的confirm完成，繼續(xù)執(zhí)行下一個(gè)CompensableInvocation資源的confirm，即又要重新開啟一個(gè)新的jta事務(wù)RPC資源的提交（參與方CompensableTransaction事務(wù)的提交）
• 13.4.15 當(dāng)所有CompensableInvocation資源的confirm執(zhí)行完畢，開始執(zhí)行RPC資源的commit，會(huì)進(jìn)行遠(yuǎn)程調(diào)用，執(zhí)行遠(yuǎn)程provider分支事務(wù)的提交，遠(yuǎn)程調(diào)用過程會(huì)傳遞事務(wù)id
• 13.4.16 provider端，根據(jù)傳遞過來(lái)的事務(wù)id找到對(duì)應(yīng)的CompensableTransaction事務(wù)，開始執(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（詳見Raft算法賞析）

  • 14.1.1 leader選舉過程，leader選舉約束，要包含所有commited entries，實(shí)現(xiàn)上log比過半的log都最新即可
  • 14.1.2 log復(fù)制過程，leader給所有的follower發(fā)送AppendEntries RPC請(qǐng)求，過半follower回復(fù)ok，則可提交該entry，然后向客戶端響應(yīng)OK
  • 14.1.3 在上述leader收到過半復(fù)制之后，掛了，則后續(xù)leader不能直接對(duì)這些之前term的過半entry進(jìn)行提交（這一部分有詳細(xì)的案例來(lái)證明，并能說(shuō)出根本原因），目前做法是在當(dāng)前term中創(chuàng)建空的entry，然后如果這些新創(chuàng)建的entry被大部分復(fù)制了，則此時(shí)就可以對(duì)之前term的過半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)被過半復(fù)制了），此時(shí)leader掛了，還沒來(lái)得及給client回復(fù)，也就是說(shuō)對(duì)client來(lái)說(shuō)，請(qǐng)求雖然失敗了，但是請(qǐng)求對(duì)應(yīng)的entry卻被持久化保存了，但是有的時(shí)候卻是請(qǐng)求失敗了（過半都沒復(fù)制成功）沒有持久化成功，也就是說(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é)議（詳見ZooKeeper的一致性算法賞析）

  • 14.2.1 leader選舉過程。要點(diǎn)：對(duì)于不同狀態(tài)下的server的投票的收集，投票是需要選舉出一個(gè)包含所有日志的server來(lái)作為leader
  • 14.2.2 leader和follower數(shù)據(jù)同步過程，全量同步、差異同步、日志之間的糾正和截?cái)?#xff0c;來(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)求，過半響應(yīng)即可回復(fù)客戶端。
  • 14.2.4 日志的恢復(fù)和持久化。持久化：每隔一定數(shù)量的事務(wù)日志持久化一次，leader選舉前持久化一次。恢復(fù)：簡(jiǎn)單的認(rèn)為已寫入日志的的事務(wù)請(qǐng)求都算作已提交的請(qǐng)求（不管之前是否已過半復(fù)制），全部執(zhí)行commit提交。具體的恢復(fù)是：先恢復(fù)快照日志，然后再應(yīng)用相應(yīng)的事務(wù)日志

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

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

    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收到了過半的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)的過程。

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

  • 14.3.2 paxos的證明過程：

    1 足夠多的問題

    2 acceptor的初始accept

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

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

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

    6 P2c-對(duì)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通信的實(shí)現(xiàn)
• 1.3 代理用戶的過程
• 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)化過程
• 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è)計(jì)
• 7.3 client端的異步批量flush尋找RegionServer的過程
• 7.4 Zookeeper上HBase節(jié)點(diǎn)解釋
• 7.5 Hbase中的mini、major合并
• 7.6 Region的高可用問題對(duì)比kafka分區(qū)的高可用實(shí)現(xiàn)
• 7.7 RegionServer RPC調(diào)用的隔離問題
• 7.8 數(shù)據(jù)從內(nèi)存刷寫到HDFS的粒度問題
• 7.9 rowKey的設(shè)計(jì)
• 7.10 MemStore與LSM

4.8 Spark

• 8.1 不同的部署方式
• 8.2 SparkSql的實(shí)現(xiàn)方式
• 8.3 。。。

總結(jié)

以上是生活随笔為你收集整理的java十年技术栈[总结复习用]的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。