大廠面試衝刺，Java“實戰”問題三連，你碰到了哪個？

推薦學習

全網首發！馬士兵內部共享—1658頁《Java面試突擊核心講》

狂刷《Java權威面試指南（阿里版）》，衝擊“金九銀十”有望了

Java“實戰”問題三連

Java“實戰”面試題1：如果用mybatis批次插入資料時需要返回主鍵，你是怎麼做的？

Java“實戰”面試題2：在微服務中你是如何實現不同服務間session 共享的？

Java“實戰”面試題3：你瞭解分庫分表麼？分庫分表一般出現在哪些場景下？

面試題1：如果用mybatis批次插入資料時需要返回主鍵，你是怎麼做的？

需要在Mapper。xml的中標籤中配置useGeneratedKeys和keyProperty兩個屬性，就可以在批次插入時返回主鍵。

比如有個表t_user，裡面有 user_id，user_name，sex 這三個欄位，其中user_id是自增主鍵。

下面是批次插入的Dao層介面：

List insertUsers（@Param（“list”） List users）；

xml形式：

insert into t_user （user_name，sex） values （#{c。user_name}，#{c。sex}）

註解形式：

@Insert（“”）@Options（useGeneratedKeys = true， keyProperty = “user_id”， resultType=“String”）List insertUsers（@Param（“list”） List users）；

注意：@Param裡和foreach的collection裡都需要寫成list，其實是原始碼中寫死了key為list，否則批次插入後會報錯說找不到“user_id”欄位，而無法返回主鍵。

這種方式的前提是該表主鍵

有序自增

，它的原理其實就是拿到當前表中

最大ID

，然後結合

影響行數

來返回相應資料。但這就需要固定的insert場景，如果是insert ignore這種可能和實際影響行數不同的情況，就會出現不準確的情況。

面試題2：在微服務中你是如何實現不同服務間session 共享的？

在微服務中，一個完整的專案被拆分成多個不相同的獨立的服務，各個服務獨立部署在不同的伺服器上，各自的 session 被從物理空間上隔離開了，但是經常，我們需要在不同微服務之間共享 session。

常見的方案就是 Spring Session + Redis 來實現 session 共享。將所有微服務的 session 統一儲存在 Redis 上，當各個微服務對 session 有相關的讀寫操作時，都去操作 Redis 上的 session 。這樣就實現了session 共享，Spring Session 基於 Spring 中的代理過濾器實現，使得 session 的同步操作對開發人員而言是透明的，非常簡便。

同時，Spring Session已經集成了redis，可以很方便的將session存到redis中從而實現單點登陸/登出的效果，但是從微服務的角度來說，為了降低系統間的耦合度，一般會單獨建一個Redis服務來搞session共享。

1、pom 檔案中引入以下包

<！——spring boot 與redis應用基本環境配置 ——> org。springframework。boot spring-boot-starter-data-redis<！——spring session 與redis應用基本環境配置 ——> org。springframework。session spring-session-data-redis

2、application。properties配置好 redis

spring。redis。database = 0spring。redis。host = 192。168。xx。xxspring。redis。port = 6379spring。redis。password = testspring。redis。pool。max-active = 200spring。redis。pool。max-wait = -1spring。redis。pool。max-idle = 10spring。redis。pool。min-idle = 0spring。redis。pool。timeout = 1000

在需要共享 session 的服務的啟動類上，加上註解即可

@EnableRedisHttpSession@SpringBootApplication（exclude= {DataSourceAutoConfiguration。class}）public class PhoneApplication { public static void main（String［］ args） { SpringApplication。run（PhoneApplication。class， args）； }}

面試題3：你瞭解分庫分表麼？分庫分表一般出現在哪些場景下？

分庫：由單個數據庫例項拆分成多個數據庫例項，將資料分佈到多個數據庫例項中。

分表：由單張表拆分成多張表，將資料劃分到多張表內。

隨著業務資料量和網站QPS日益增高，對資料庫壓力也越來越大，單機版資料庫很快會到達儲存和併發瓶頸，就需要做資料庫效能方面的最佳化，分庫分表採取的是分而治之的策略，分庫目的是減輕單臺MySQL例項儲存壓力及可擴充套件性，而分表是解決單張表資料過大以後查詢的瓶頸問題，坦白說，這些問題也是所有關係型資料庫的“硬傷”。

常用策略包括：垂直分表、水平分表、垂直分庫、水平分庫。

一、樸實無華的 - 分表

1、垂直分表

垂直分表，或者叫豎著切表，是不是感受到該策略是以欄位為依據的！主要按照欄位的活躍性、欄位長度，將表中欄位拆分到不同的表（主表和擴充套件表）中。

特點：

每個表的結構都不一樣；

每個表的資料也不一樣；

有一個關聯欄位，一般是主鍵或外來鍵，用於關聯兄弟表資料；

所有兄弟表的並集是該表的全量資料；

場景：

有幾個欄位屬於熱點欄位，更新頻率很高，要把這些欄位單獨切到一張表裡，不然innodb行鎖很噁心的，鎖死你呀~~如使用者表裡的餘額欄位？不，我的餘額就很穩定，一直是0。。

有大欄位，如text，儲存壓力很大，畢竟innodb資料和索引是同一個檔案；同時，我又喜歡用SELECT *，你懂得，這磁碟IO消耗的，跟玩兒似的，誰都扛不住的。

有明顯的業務區分，或表結構設計時欄位冗餘；有些小夥伴看到第一點時，就發現陳哈哈是個菜雞，使用者表怎麼會有餘額欄位？明顯有問題啊！趕緊先到評論區噴陳哈哈一波~~然後笑嘻嘻地發現原來是個小尾巴，真不要臉是吧。。是的，因此不同業務我們要把具體欄位拆開，這樣才有利於業務後續擴充套件哦。

2、水平分表

水平分表，也叫“橫著切”。。以行資料為依據進行切分，一般按照某列的內容進行切分。

如手機號表，我們可以透過前兩位或前三位進行切分，如131、132、133 → phone_131、phone_132、phone_133，手機號有11位（100億），量大是很正常的事兒，這年頭誰家老頭老太太每個手機呢是吧。這樣切就把一張大表切成了好幾十張小表，資料量不就下來了。有同學就問了那我怎麼知道我這手機號查哪個表呢？一看你就沒認真看前兩行標紅的點，為啥標紅嘞？比如我查13100001111，那我擷取前三位，動態拼接到查詢的表名上，就行了。

特點：

每個表的結構都一樣；

每個表的資料都不一樣，沒有交集；

所有表的並集是該表的全量資料；

場景

：單表的資料量過大或增長速度很快，已經影響或即將會影響SQL查詢效率，加重了CPU負擔，提前到達瓶頸。記得水平分表越早越好，別問我為什麼。。

二、花裡胡哨的 - 分庫

需要你注意的是，傳統的分庫和我們熟悉的叢集、主從複製可不是一個事兒；多節點叢集是將一個庫複製成N個庫，從而透過讀寫分離實現多個MySQL服務的負載均衡，實際是圍繞一個庫來搞的，這個庫稱為Master主庫。而分庫就不同了，分庫是將這個主庫一分為N，比如一分為二，然後針對這兩個主庫，再配置2N個從庫節點。

3、垂直分庫

縱向切庫，太經典的切分方式，基於表進行切分，通常是把新的業務模組或整合公共模組拆分出去，比如我們最熟悉的單點登入、鑑權模組。熟悉的味道，記得有一次我把一些沒用的表切到一個性能很好的伺服器中，這伺服器我專門用來學習，後來也不知被哪個狗腿子告密了~ 我**你個**，有種站出來，你個**東西。