在spring boot中配置多數據源和分庫分表，核心是通過定義多個datasource bean實現多數據源連接與動態切換，并根據分片鍵將數據分散到不同數據庫或表中以提升系統擴展性。1. 多數據源配置需在application.yml中定義多個數據源信息，并通過@bean創建多個datasource實例；2. 使用abstractroutingdatasource實現動態數據源切換，結合threadlocal和aop實現運行時上下文識別；3. 分庫分表策略包括范圍分片、哈希分片、時間分片和業務分片，選擇合適的分片鍵至關重要；4. 可借助shardingsphere等中間件簡化實現，也可自定義規則在dao層或aop中處理路由；5. 事務管理復雜，優先避免跨庫操作，必要時采用分布式事務方案如tcc或saga；6. 需綜合考慮數據分布均勻性、擴容遷移可行性及查詢復雜度，提前規劃并逐步迭代以平衡擴展性與維護成本。
在spring boot應用里搞多數據源和分庫分表，說白了，就是為了解決數據庫單點瓶頸和數據量爆炸的問題。我們不再把所有雞蛋放一個籃子里，而是把數據分散到多個數據庫甚至多臺服務器上，讓系統能扛住更大的并發和數據增長。這玩意兒，搞好了能讓你的應用像打了雞血一樣跑得飛快，但搞不好，那真是給自己挖坑。
搞定多數據源和分庫分表，核心思路就是兩步：第一，讓你的Spring Boot應用能同時連接和管理多個數據庫連接；第二，當有數據操作請求過來時，能根據一定的規則（比如用戶ID）判斷這個數據應該去哪個數據庫、哪個表。
具體到Spring Boot，多數據源的配置相對直接，就是定義多個DataSource bean，然后通過一個動態數據源切換機制（比如繼承AbstractRoutingDataSource）來根據上下文選擇使用哪個數據源。分庫分表這塊就更復雜了，你需要一套規則來決定數據走向，這套規則可以是自己寫代碼實現，也可以借助像ShardingSphere這樣的中間件。自己寫代碼，通常是在DAO層或Service層前面加一層攔截，或者干脆用AOP，根據業務ID來計算出目標庫和表名，然后動態修改sql或者切換數據源。這個過程中，事務管理是個大挑戰，跨庫事務通常很麻煩，能避免就避免，實在不行，就得考慮分布式事務方案了，比如XA，但那玩意兒性能損耗大，或者TCC、SAGA這種柔性事務。說實話，我個人傾向于盡量在業務層面規避分布式事務，或者通過最終一致性來解決。
為什么我們需要在Spring Boot中考慮多數據源和分庫分表？
其實，這事兒挺無奈的，但又不得不做。當你的用戶量和數據量達到一定規模，單臺數據庫服務器，即便你硬件堆到極致，也總會有扛不住的一天。讀寫瓶頸、存儲容量限制，這些都是明擺著的問題。Spring Boot本身雖然簡化了應用開發，但它不負責幫你擴展數據庫。所以，一旦你的業務開始高速增長，數據庫的橫向擴展就成了繞不過去的坎。
考慮多數據源和分庫分表，本質上就是為了實現數據庫的水平擴展。把一個巨大的數據庫拆分成多個小的、易于管理的數據庫實例，每個實例只承載一部分數據或請求。這樣一來，讀寫壓力分散了，存儲空間也擴展了。這就像把一個大水池的水，分流到好幾個小水池里，每個小水池的壓力都小了，而且可以根據需要增加更多的小水池。當然，這也會帶來額外的復雜性，比如數據查詢可能需要跨多個庫表，數據一致性問題，還有運維的挑戰，但這些都是為了高可用和高性能必須付出的代價。我見過太多項目，早期跑得歡，后期因為沒提前規劃好數據庫擴展，導致整個系統性能直線下降，甚至重構。
如何在Spring Boot項目中配置和管理多數據源？
在Spring Boot里配置多個數據源，這算是分庫分表的第一步，也是相對直接的一步。你需要在application.yml或application.properties里定義好多個數據源的連接信息，比如datasource.db1.url、datasource.db2.url等等。
然后，在你的配置類里，為每個數據源定義一個@Bean。通常會用@ConfigurationProperties來綁定配置信息，這樣能讓代碼更清晰。例如：
@Configuration public class DataSourceConfig { @Bean(name = "db1DataSource") @ConfigurationProperties(prefix = "spring.datasource.db1") public DataSource db1DataSource() { return DataSourceBuilder.create().build(); } @Bean(name = "db2DataSource") @ConfigurationProperties(prefix = "spring.datasource.db2") public DataSource db2DataSource() { return DataSourceBuilder.create().build(); } // 關鍵：動態數據源 @Bean(name = "dynamicDataSource") @Primary // 標記為主數據源，Spring會默認注入它 public DataSource dynamicDataSource(@Qualifier("db1DataSource") DataSource db1, @Qualifier("db2DataSource") DataSource db2) { DynamicDataSource dynamicDataSource = new DynamicDataSource(); Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put("db1", db1); targetDataSources.put("db2", db2); dynamicDataSource.setTargetDataSources(targetDataSources); dynamicDataSource.setDefaultTargetDataSource(db1); // 默認使用db1 return dynamicDataSource; } // 事務管理器也需要指向動態數據源 @Bean public PlatformTransactionManager transactionManager(@Qualifier("dynamicDataSource") DataSource dynamicDataSource) { return new DataSourceTransactionManager(dynamicDataSource); } }
這里的DynamicDataSource就是我們自定義的，它繼承自AbstractRoutingDataSource。你需要重寫determineCurrentLookupKey()方法，這個方法會返回當前請求應該使用哪個數據源的鍵（比如”db1″或”db2″）。這個鍵通常通過ThreadLocal來傳遞，比如你在某個Service方法執行前設置好，執行完再清除。
public class DynamicDataSource extends AbstractRoutingDataSource { @Override protected Object determineCurrentLookupKey() { // 從ThreadLocal獲取當前數據源的key return DynamicDataSourceContextHolder.getDataSourceKey(); } } public class DynamicDataSourceContextHolder { private static final ThreadLocal<String> CONTEXT_HOLDER = new ThreadLocal<>(); public static void setDataSourceKey(String key) { CONTEXT_HOLDER.set(key); } public static String getDataSourceKey() { return CONTEXT_HOLDER.get(); } public static void clearDataSourceKey() { CONTEXT_HOLDER.remove(); } }
然后，你可以通過AOP或者自定義注解來在方法執行前后切換數據源。比如定義一個@TargetDataSource注解，然后用AOP攔截這個注解，在方法執行前設置數據源，方法執行后清除。這樣，你的業務代碼就不用關心數據源切換的細節了。
分庫分表的策略選擇與實現考量
分庫分表的策略選擇，這才是真正的難點和藝術。沒有銀彈，只有最適合你業務的方案。核心是選擇一個合適的“分片鍵”（Sharding Key），這個鍵決定了數據最終會落在哪個庫、哪個表。
常見的策略有：
- 范圍分片（Range Sharding）：比如用戶ID 1-100000放一個庫，100001-200000放另一個庫。優點是簡單直觀，擴容方便。缺點是數據分布可能不均勻，某些范圍的數據量大，導致熱點問題。
- 哈希分片（Hash Sharding）/取模分片（Modulus Sharding）：比如根據用戶ID對N取模，結果為0的放庫0，為1的放庫1。優點是數據分布相對均勻。缺點是擴容時麻煩，可能需要大量數據遷移。
- 時間分片（Time Sharding）：按時間維度分表，比如每月一張表。適用于日志、訂單等時效性強的數據。優點是查詢特定時間范圍的數據很快。缺點是跨時間范圍查詢復雜，歷史數據歸檔麻煩。
- 業務分片（Business Sharding）：根據業務屬性直接劃分，比如電商系統把商品數據放一個庫，用戶數據放一個庫。這種其實更像是垂直拆分，而不是嚴格意義上的分庫分表。
在實現上，我個人傾向于先評估是否真的需要自己手寫分片邏輯。如果業務復雜，或者未來擴展性要求高，直接上像ShardingSphere這樣的分布式數據庫中間件會省心很多。它能幫你處理數據路由、讀寫分離、分布式事務等一系列問題，你只需要配置好規則，sql語句基本不用改。當然，引入中間件也會增加系統的復雜度，多了一層維護成本。
如果業務相對簡單，數據量沒那么恐怖，或者你對性能有極致要求，可以考慮自己實現。這通常意味著你需要一個解析SQL的層，或者在ORM框架（比如mybatis）的攔截器里做手腳，根據分片鍵動態生成表名和路由到對應的數據源。
無論哪種方式，都要考慮以下幾點：
- 分片鍵的選擇：這是重中之重。理想的分片鍵應該能均勻分布數據，并且大部分查詢都能通過分片鍵來路由，避免全表掃描或跨庫查詢。比如用戶ID通常是個好選擇。
- 數據遷移和擴容：當數據量繼續增長，或者某個分片變成熱點時，如何平滑地進行數據遷移和擴容，是個大挑戰。
- 分布式事務：前面提過，盡量避免。如果實在避免不了，需要深入研究XA、TCC或SAGA這些方案，并評估其對性能的影響。
- 查詢復雜性：分庫分表后，原本簡單的JOIN查詢可能變得非常復雜，甚至無法實現。聚合查詢也可能需要在應用層進行二次聚合。這會倒逼你重新思考數據模型和業務查詢模式。
總之，分庫分表是個系統性工程，需要從業務、技術、運維多個角度去權衡。提前規劃，小步快跑，逐步迭代，比一開始就追求完美要靠譜得多。
