【轉】Java技術棧

標籤：min   解決辦法   整理   adc   模式   expr   註冊   sort   架構   

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 Regex

• 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 資料庫的分庫分表mycat3.7 NoSql資料庫mongodb3.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

4.8 Spark

• 8.1 不同的部署方式
• 8.2 SparkSql的實現方式
• 8.3 。。。

【轉】Java技術棧