NO IMAGE

java技術棧

參考了眾多資料,這裡就不再詳細列舉了,可以自行去搜尋

1 java基礎:

1.1 演算法

  • 1.1 排序演算法:直接插入排序、希爾排序、氣泡排序、快速排序、直接選擇排序、堆排序、歸併排序、基數排序
  • 1.2 二叉查詢樹、紅黑樹、B樹、B 樹、LSM樹(分別有對應的應用,資料庫、HBase)
  • 1.3 BitSet解決資料重複和是否存在等問題

1.2 基本

  • 2.1 字串常量池的遷移
  • 2.2 字串KMP演算法
  • 2.3 equals和hashcode
  • 2.4 泛型、異常、反射
  • 2.5 string的hash演算法
  • 2.6 hash衝突的解決辦法:拉鍊法
  • 2.7 foreach迴圈的原理
  • 2.8 static、final、transient等關鍵字的作用
  • 2.9 volatile關鍵字的底層實現原理
  • 2.10 Collections.sort方法使用的是哪種排序方法
  • 2.11 Future介面,常見的執行緒池中的FutureTask實現等
  • 2.12 string的intern方法的內部細節,jdk1.6和jdk1.7的變化以及內部cpp程式碼StringTable的實現

1.3 設計模式

  • 單例模式
  • 工廠模式
  • 裝飾者模式
  • 觀察者設計模式
  • ThreadLocal設計模式
  • 。。。

1.4 正規表示式

  • 4.1 捕獲組和非捕獲組
  • 4.2 貪婪,勉強,獨佔模式

1.5
java記憶體模型以及垃圾回收演算法

  • 5.1 類載入機制,也就是雙親委派模型

  • 5.2 java記憶體分配模型(預設HotSpot)

    執行緒共享的:堆區、永久區 執行緒獨享的:虛擬機器棧、本地方法棧、程式計數器

  • 5.3 記憶體分配機制:年輕代(Eden區、兩個Survivor區)、年老代、永久代以及他們的分配過程

  • 5.4 強引用、軟引用、弱引用、虛引用與GC

  • 5.5 happens-before規則

  • 5.6 指令重排序、記憶體柵欄

  • 5.7 Java 8的記憶體分代改進

  • 5.8 垃圾回收演算法:

    標記-清除(不足之處:效率不高、記憶體碎片)

    複製演算法(解決了上述問題,但是記憶體只能使用一半,針對大部分物件存活時間短的場景,引出了一個預設的8:1:1的改進,缺點是仍然需要藉助外界來解決可能承載不下的問題)

    標記整理

  • 5.8 常用垃圾收集器:

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

    老年代:Serial Old收集器、Parallel Old收集器、CMS(Concurrent Mark Sweep)收集器、 G1 收集器(跨新生代和老年代)

  • 5.9 常用gc的引數:-Xmn、-Xms、-Xmx、-XX:MaxPermSize、-XX:SurvivorRatio、-XX:-PrintGCDetails

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

1.6
鎖以及併發容器的原始碼

  • 6.1 synchronized和volatile理解
  • 6.2 Unsafe類的原理,使用它來實現CAS。因此誕生了AtomicInteger系列等
  • 6.3 CAS可能產生的ABA問題的解決,如加入修改次數、版本號
  • 6.4 同步器AQS的實現原理
  • 6.5 獨佔鎖、共享鎖;可重入的獨佔鎖ReentrantLock、共享鎖 實現原理
  • 6.6 公平鎖和非公平鎖
  • 6.7 讀寫鎖 ReentrantReadWriteLock的實現原理
  • 6.8 LockSupport工具
  • 6.9 Condition介面及其實現原理
  • 6.10 HashMap、HashSet、ArrayList、LinkedList、HashTable、ConcurrentHashMap、TreeMap的實現原理
  • 6.11 HashMap的併發問題
  • 6.12 ConcurrentLinkedQueue的實現原理
  • 6.13 Fork/Join框架
  • 6.14 CountDownLatch和CyclicBarrier

1.7 執行緒池原始碼

  • 7.1 內部執行原理
  • 7.2 各種執行緒池的區別

2 web方面:

2.1
SpringMVC的架構設計

  • 1.1 servlet開發存在的問題:對映問題、引數獲取問題、格式化轉換問題、返回值處理問題、檢視渲染問題
  • 1.2 SpringMVC為解決上述問題開發的幾大元件及介面:HandlerMapping、HandlerAdapter、HandlerMethodArgumentResolver、HttpMessageConverter、Converter、GenericConverter、HandlerMethodReturnValueHandler、ViewResolver、MultipartResolver
  • 1.3 DispatcherServlet、容器、元件三者之間的關係
  • 1.4 敘述SpringMVC對請求的整體處理流程
  • 1.5 SpringBoot

2.2
SpringAOP原始碼

  • 2.1 AOP的實現分類:編譯期、位元組碼載入前、位元組碼載入後三種時機來實現AOP

  • 2.2 深刻理解其中的角色:AOP聯盟、aspectj、jboss AOP、Spring自身實現的AOP、Spring嵌入aspectj。特別是能用程式碼區分後兩者

  • 2.3 介面設計:

    AOP聯盟定義的概念或介面:Pointcut(概念,沒有定義對應的介面)、Joinpoint、Advice、MethodInterceptor、MethodInvocation

    SpringAOP針對上述Advice介面定義的介面及其實現類:BeforeAdvice、AfterAdvice、MethodBeforeAdvice、AfterReturningAdvice;針對aspectj對上述介面的實現AspectJMethodBeforeAdvice、AspectJAfterReturningAdvice、AspectJAfterThrowingAdvice、AspectJAfterAdvice。

    SpringAOP定義的定義的AdvisorAdapter介面:將上述Advise轉化為MethodInterceptor

    SpringAOP定義的Pointcut介面:含有兩個屬性ClassFilter(過濾類)、MethodMatcher(過濾方法)

    SpringAOP定義的ExpressionPointcut介面:實現中會引入aspectj的pointcut表示式

    SpringAOP定義的PointcutAdvisor介面(將上述Advice介面和Pointcut介面結合起來)

  • 2.4 SpringAOP的呼叫流程

  • 2.5 SpringAOP自己的實現方式(代表人物ProxyFactoryBean)和藉助aspectj實現方式區分

2.3
Spring事務體系原始碼以及分散式事務Jotm Atomikos原始碼實現

  • 3.1 jdbc事務存在的問題
  • 3.2 Hibernate對事務的改進
  • 3.3 針對各種各樣的事務,Spring如何定義事務體系的介面,以及如何融合jdbc事務和Hibernate事務的
  • 3.4 三種事務模型包含的角色以及各自的職責
  • 3.5 事務程式碼也業務程式碼分離的實現(AOP ThreadLocal來實現)
  • 3.6 Spring事務攔截器TransactionInterceptor全景
  • 3.7 X/Open DTP模型,兩階段提交,JTA介面定義
  • 3.8 Jotm、Atomikos的實現原理
  • 3.9 事務的傳播屬性
  • 3.10 PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED的實現原理以及區別
  • 3.11 事物的掛起和恢復的原理

2.4
資料庫隔離級別

  • 4.1 Read uncommitted:讀未提交
  • 4.2 Read committed : 讀已提交
  • 4.3 Repeatable read:可重複讀
  • 4.4 Serializable :序列化

2.5 資料庫

  • 5.1 資料庫效能的優化

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

    例如下面的在什麼情況下會出現死鎖:

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

  • 5.3 insert into select語句的加鎖情況

  • 5.4 事務的ACID特性概念

  • 5.5 innodb的MVCC理解

  • 5.6 undo redo binlog

    • 1 undo redo 都可以實現持久化,他們的流程是什麼?為什麼選用redo來做持久化?
    • 2 undo、redo結合起來實現原子性和持久化,為什麼undo log要先於redo log持久化?
    • 3 undo為什麼要依賴redo?
    • 4 日誌內容可以是物理日誌,也可以是邏輯日誌?他們各自的優點和缺點是?
    • 5 redo log最終採用的是物理日誌加邏輯日誌,物理到page,page內邏輯。還存在什麼問題?怎麼解決?Double Write
    • 6 undo log為什麼不採用物理日誌而採用邏輯日誌?
    • 7 為什麼要引入Checkpoint?
    • 8 引入Checkpoint後為了保證一致性需要阻塞使用者操作一段時間,怎麼解決這個問題?(這個問題還是很有普遍性的,redis、ZooKeeper都有類似的情況以及不同的應對策略)又有了同步Checkpoint和非同步Checkpoint
    • 9 開啟binlog的情況下,事務內部2PC的一般過程(含有2次持久化,redo log和binlog的持久化)
    • 10 解釋上述過程,為什麼binlog的持久化要在redo log之後,在儲存引擎commit之前?
    • 11 為什麼要保持事務之間寫入binlog和執行儲存引擎commit操作的順序性?(即先寫入binlog日誌的事務一定先commit)
    • 12 為了保證上述順序性,之前的辦法是加鎖prepare_commit_mutex,但是這極大的降低了事務的效率,怎麼來實現binlog的group commit?
    • 13 怎麼將redo log的持久化也實現group commit?至此事務內部2PC的過程,2次持久化的操作都可以group commit了,極大提高了效率

2.6
ORM框架: mybatis、Hibernate

  • 6.1 最原始的jdbc->Spring的JdbcTemplate->hibernate->JPA->SpringDataJPA的演進之路

2.7
SpringSecurity、shiro、SSO(單點登入)

  • 7.1 Session和Cookie的區別和聯絡以及Session的實現原理
  • 7.2 SpringSecurity的認證過程以及與Session的關係
  • 7.3 CAS實現SSO(詳見Cas(01)——簡介

輸入圖片說明

2.8 日誌

  • 8.1 jdk自帶的logging、log4j、log4j2、logback
  • 8.2 門面commons-logging、slf4j
  • 8.3 上述6種混戰時的日誌轉換

2.9
datasource

  • 9.1 c3p0
  • 9.2 druid
  • 9.3 JdbcTemplate執行sql語句的過程中對Connection的使用和管理

2.10
HTTPS的實現原理

3
分散式、java中介軟體、web伺服器等方面:

3.1
ZooKeeper原始碼

  • 1.1 客戶端架構
  • 1.2 伺服器端單機版和叢集版,對應的請求處理器
  • 1.3 叢集版session的建立和啟用過程
  • 1.4 Leader選舉過程
  • 1.5 事務日誌和快照檔案的詳細解析
  • 1.6 實現分散式鎖、分散式ID分發器
  • 1.7 實現Leader選舉
  • 1.8 ZAB協議實現一致性原理

3.2
序列化和反序列化框架

  • 2.1 Avro研究
  • 2.2 Thrift研究
  • 2.3 Protobuf研究
  • 2.4 Protostuff研究
  • 2.5 Hessian

3.3
RPC框架dubbo原始碼

  • 3.1 dubbo擴充套件機制的實現,對比SPI機制
  • 3.2 服務的釋出過程
  • 3.3 服務的訂閱過程
  • 3.4 RPC通訊的設計

3.4
NIO模組以及對應的Netty和Mina、thrift原始碼

  • 4.1 TCP握手和斷開及有限狀態機
  • 4.2 backlog
  • 4.3 BIO NIO
  • 4.4 阻塞/非阻塞的區別、同步/非同步的區別
  • 4.5 阻塞IO、非阻塞IO、多路複用IO、非同步IO
  • 4.6 Reactor執行緒模型
  • 4.7 jdk的poll、epoll與底層poll、epoll的對接實現
  • 4.8 Netty自己的epoll實現
  • 4.9 核心層poll、epoll的大致實現
  • 4.10 epoll的邊緣觸發和水平觸發
  • 4.11 Netty的EventLoopGroup設計
  • 4.12 Netty的ByteBuf設計
  • 4.13 Netty的ChannelHandler
  • 4.13 Netty的零拷貝
  • 4.14 Netty的執行緒模型,特別是與業務執行緒以及資源釋放方面的理解

3.5
訊息佇列kafka、RocketMQ、Notify、Hermes

  • 5.1 kafka的檔案儲存設計
  • 5.2 kafka的副本複製過程
  • 5.3 kafka副本的leader選舉過程
  • 5.4 kafka的訊息丟失問題
  • 5.5 kafka的訊息順序性問題
  • 5.6 kafka的isr設計和過半對比
  • 5.7 kafka本身做的很輕量級來保持高效,很多高階特性沒有:事務、優先順序的訊息、訊息的過濾,更重要的是服務治理不健全,一旦出問題,不能直觀反應出來,不太適合對資料要求十分嚴苛的企業級系統,而適合日誌之類併發量大但是允許少量的丟失或重複等場景
  • 5.8 Notify、RocketMQ的事務設計
  • 5.9 基於檔案的kafka、RocketMQ和基於資料庫的Notify和Hermes
  • 5.10 設計一個訊息系統要考慮哪些方面
  • 5.11 丟失訊息、訊息重複、高可用等話題

3.6
資料庫的分庫分表mycat

3.7
NoSql資料庫mongodb

3.8
KV鍵值系統memcached redis

  • 8.1 redis對客戶端的維護和管理,讀寫緩衝區
  • 8.2 redis事務的實現
  • 8.3 Jedis客戶端的實現
  • 8.4 JedisPool以及ShardedJedisPool的實現
  • 8.5 redis epoll實現,迴圈中的檔案事件和時間事件
  • 8.6 redis的RDB持久化,save和bgsave
  • 8.7 redis AOF命令追加、檔案寫入、檔案同步到磁碟
  • 8.8 redis AOF重寫,為了減少阻塞時間採取的措施
  • 8.9 redis的LRU記憶體回收演算法
  • 8.10 redis的master slave複製
  • 8.11 redis的sentinel高可用方案
  • 8.12 redis的cluster分片方案

3.9
web伺服器tomcat、ngnix的設計原理

  • 9.1 tomcat的整體架構設計
  • 9.2 tomcat對通訊的併發控制
  • 9.3 http請求到達tomcat的整個處理流程

3.10
ELK日誌實時處理查詢系統

  • 10.1 Elasticsearch、Logstash、Kibana

3.11
服務方面

  • 11.1 SOA與微服務
  • 11.2 服務的合併部署、多版本自動快速切換和回滾

詳見基於Java容器的多應用部署技術實踐

  • 11.3 服務的治理:限流、降級

具體見 張開濤大神的架構系列

服務限流:令牌桶、漏桶

服務降級、服務的熔斷、服務的隔離:netflix的hystrix元件

  • 11.4 服務的線性擴充套件

    無狀態的服務如何做線性擴充套件:

    如一般的web應用,直接使用硬體或者軟體做負載均衡,簡單的輪訓機制

    有狀態服務如何做線性擴充套件:

    如Redis的擴充套件:一致性hash,遷移工具

  • 11.5 服務鏈路監控和報警:CAT、Dapper、Pinpoint

3.12
Spring Cloud

  • 12.1 Spring Cloud Zookeeper:用於服務註冊和發現
  • 12.2 Spring Cloud Config:分散式配置
  • 12.2 Spring Cloud Netflix Eureka:用於rest服務的註冊和發現
  • 12.3 Spring Cloud Netflix Hystrix:服務的隔離、熔斷和降級
  • 12.4 Spring Cloud Netflix Zuul:動態路由,API Gateway

3.13
分散式事務

  • 13.1 JTA分散式事務介面定義,對此與Spring事務體系的整合
  • 13.2 TCC分散式事務概念
  • 13.3 TCC分散式事務實現框架案例1:tcc-transaction
  • 13.3.1 TccCompensableAspect切面攔截建立ROOT事務
  • 13.3.2 TccTransactionContextAspect切面使遠端RPC呼叫資源加入到上述事務中,作為一個參與者
  • 13.3.3 TccCompensableAspect切面根據遠端RPC傳遞的TransactionContext的標記建立出分支事務
  • 13.3.4 全部RPC呼叫完畢,ROOT事務開始提交或者回滾,執行所有參與者的提交或回滾
  • 13.3.5 所有參與者的提交或者回滾,還是通過遠端RPC呼叫,provider端開始執行對應分支事務的confirm或者cancel方法
  • 13.3.6 事務的儲存,叢集共享問題13.3.7 事務的恢復,避免叢集重複恢復
  • 13.4 TCC分散式事務實現框架案例2:ByteTCC
  • 13.4.1 JTA事務管理實現,類比Jotm、Atomikos等JTA實現
  • 13.4.2 事務的儲存和恢復,叢集是否共享問題呼叫方建立CompensableTransaction事務,並加入資源
  • 13.4.3 CompensableMethodInterceptor攔截器向spring事務注入CompensableInvocation資源
  • 13.4.4 Spring的分散式事務管理器建立作為協調者CompensableTransaction型別事務,和當前執行緒進行繫結,同時建立一個jta事務
  • 13.4.5 在執行sql等操作的時候,所使用的jdbc等XAResource資源加入上述jta事務
  • 13.4.6 dubbo RPC遠端呼叫前,CompensableDubboServiceFilter建立出一個代理XAResource,加入上述 CompensableTransaction型別事務,並在RPC呼叫過程傳遞TransactionContext參與方建立分支的CompensableTransaction事務,並加入資源,然後提交jta事務
  • 13.4.7 RPC遠端呼叫來到provider端,CompensableDubboServiceFilter根據傳遞過來的TransactionContext建立出對應的CompensableTransaction型別事務
  • 13.4.8 provider端,執行時遇見@Transactional和@Compensable,作為一個參與者開啟try階段的事務,即建立了一個jta事務
  • 13.4.9 provider端try執行完畢開始準備try的提交,僅僅是提交上述jta事務,返回結果到RPC呼叫端呼叫方決定回滾還是提交
  • 13.4.10 全部執行完畢後開始事務的提交或者回滾,如果是提交則先對jta事務進行提交(包含jdbc等XAResource資源的提交),提交成功後再對CompensableTransaction型別事務進行提交,如果jta事務提交失敗,則需要回滾CompensableTransaction型別事務。
  • 13.4.11 CompensableTransaction型別事務的提交就是對CompensableInvocation資源和RPC資源的提交,分別呼叫每一個CompensableInvocation資源的confirm,以及每一個RPC資源的提交CompensableInvocation資源的提交
  • 13.4.12 此時每一個CompensableInvocation資源的confirm又會準備開啟一個新的事務,當前執行緒的CompensableTransaction型別事務已存在,所以這裡開啟事務僅僅是建立了一個新的jta事務而已
  • 13.4.13 針對此,每一個CompensableInvocation資源的confirm開啟的事務,又開始重複上述過程,對於jdbc等資源都加入新建立的jta事務中,而RPC資源和CompensableInvocation資源仍然加入到當前執行緒繫結的CompensableTransaction型別事務
  • 13.4.14 當前CompensableInvocation資源的confirm開啟的事務執行完畢後,開始執行commit,此時仍然是執行jta事務的提交,提交完畢,一個CompensableInvocation資源的confirm完成,繼續執行下一個CompensableInvocation資源的confirm,即又要重新開啟一個新的jta事務RPC資源的提交(參與方CompensableTransaction事務的提交)
  • 13.4.15 當所有CompensableInvocation資源的confirm執行完畢,開始執行RPC資源的commit,會進行遠端呼叫,執行遠端provider分支事務的提交,遠端呼叫過程會傳遞事務id
  • 13.4.16 provider端,根據傳遞過來的事務id找到對應的CompensableTransaction事務,開始執行提交操作,提交操作完成後返回響應結束
  • 13.4.17 協調者收到響應後繼續執行下一個RPC資源的提交,當所有RPC資源也完成相應的提交,則協調者算是徹底完成該事務

3.14
一致性演算法

  • 14.1 raft(詳見Raft演算法賞析

    • 14.1.1 leader選舉過程,leader選舉約束,要包含所有commited entries,實現上log比過半的log都最新即可
    • 14.1.2 log複製過程,leader給所有的follower傳送AppendEntries RPC請求,過半follower回覆ok,則可提交該entry,然後向客戶端響應OK
    • 14.1.3 在上述leader收到過半複製之後,掛了,則後續leader不能直接對這些之前term的過半entry進行提交(這一部分有詳細的案例來證明,並能說出根本原因),目前做法是在當前term中建立空的entry,然後如果這些新建立的entry被大部分複製了,則此時就可以對之前term的過半entry進行提交了
    • 14.1.4 leader一旦認為某個term可以提交了,則更新自己的commitIndex,同時應用entry到狀態機中,然後在下一次與follower的heartbeat通訊中,將leader的commitIndex帶給follower,讓他們進行更新,同時應用entry到他們的狀態機中
    • 14.1.5 從上述流程可以看到,作為client來說,可能會出現這樣的情況:leader認為某次client的請求可以提交了(對應的entry已經被過半複製了),此時leader掛了,還沒來得及給client回覆,也就是說對client來說,請求雖然失敗了,但是請求對應的entry卻被持久化儲存了,但是有的時候卻是請求失敗了(過半都沒複製成功)沒有持久化成功,也就是說請求失敗了,伺服器端可能成功了也可能失敗了。所以這時候需要在client端下功夫,即cleint端重試的時候仍然使用之前的請求資料進行重試,而不是採用新的資料進行重試,伺服器端也必須要實現冪等。
    • 14.1.6 Cluster membership changes
  • 14.2 ZooKeeper使用的ZAB協議(詳見ZooKeeper的一致性演算法賞析

    • 14.2.1 leader選舉過程。要點:對於不同狀態下的server的投票的收集,投票是需要選舉出一個包含所有日誌的server來作為leader
    • 14.2.2 leader和follower資料同步過程,全量同步、差異同步、日誌之間的糾正和截斷,來保證和leader之間的一致性。以及follower加入已經完成選舉的系統,此時的同步的要點:阻塞leader處理寫請求,完成日誌之間的差異同步,還要處理現有進行中的請求的同步,完成同步後,解除阻塞。
    • 14.2.3 廣播階段,即正常處理客戶端的請求,過半響應即可回覆客戶端。
    • 14.2.4 日誌的恢復和持久化。持久化:每隔一定數量的事務日誌持久化一次,leader選舉前持久化一次。恢復:簡單的認為已寫入日誌的的事務請求都算作已提交的請求(不管之前是否已過半複製),全部執行commit提交。具體的恢復是:先恢復快照日誌,然後再應用相應的事務日誌
  • 14.3 paxos(詳見paxos演算法證明過程

    • 14.3.1 paxos的運作過程:

      Phase 1: (a) 一個proposer選擇一個編號為n的議案,向所有的acceptor傳送prepare請求

      Phase 1: (b) 如果acceptor已經響應的prepare請求中議案編號都比n小,則它承諾不再響應prepare請求或者accept請求中議案編號小於n的, 並且找出已經accept的最大議案的value返回給該proposer。如果已響應的編號比n大,則直接忽略該prepare請求。

      Phase 2:(a) 如果proposer收到了過半的acceptors響應,那麼將提出一個議案(n,v),v就是上述所有acceptor響應中最大accept議案的value,或者是proposer自己的value。然後將該議案傳送給所有的acceptor。這個請求叫做accept請求,這一步才是所謂傳送議案請求,而前面的prepare請求更多的是一個構建出最終議案(n,v)的過程。

      Phase 2:(b) acceptor接收到編號為n的議案,如果acceptor還沒有對大於n的議案的prepare請求響應過,則acceptor就accept該議案,否則拒絕

    • 14.3.2 paxos的證明過程:

      1 足夠多的問題

      2 acceptor的初始accept

      3 P2-對結果要求

      4 P2a-對acceptor的accept要求

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

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

      7 引出prepare過程和P1a

      8 8 優化prepare

    • 14.3.3 base paxos和multi-paxos

4 大資料方向

4.1
Hadoop

  • 1.1 UserGroupInformation原始碼解讀:JAAS認證、user和group關係的維護
  • 1.2 RPC通訊的實現
  • 1.3 代理使用者的過程
  • 1.4 kerberos認證

4.2
MapReduce

  • 2.1 MapReduce理論及其對應的介面定義

4.3 HDFS

  • 3.1 MapFile、SequenceFile
  • 3.2 ACL

4.4
YARN、Mesos 資源排程

4.5 oozie

  • 5.1 oozie XCommand設計
  • 5.2 DagEngine的實現原理

4.6 Hive

  • 6.1 HiveServer2、metatore的thrift RPC通訊設計
  • 6.2 Hive的優化過程
  • 6.3 HiveServer2的認證和授權
  • 6.4 metastore的認證和授權
  • 6.5 HiveServer2向metatore的使用者傳遞過程

4.7 Hbase

  • 7.1 Hbase的整體架構圖
  • 7.2 Hbase的WAL和MVCC設計
  • 7.3 client端的非同步批量flush尋找RegionServer的過程
  • 7.4 Zookeeper上HBase節點解釋
  • 7.5 Hbase中的mini、major合併
  • 7.6 Region的高可用問題對比kafka分割槽的高可用實現
  • 7.7 RegionServer RPC呼叫的隔離問題
  • 7.8 資料從記憶體刷寫到HDFS的粒度問題
  • 7.9 rowKey的設計
  • 7.10 MemStore與LSM