java分布式事務框架
⑴ java程序員在面試中被問到如何配置多數據源以及如何配置多數據源下的分布式事務，該怎麼回答看清再做答
你好，我來先回答你的第一個問題：
通常多數據源，在spring中配置如下，如果你想切換環境ENV 的值，在property中
<bean id="placeholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="ignoreResourceNotFound" value="true"></property>
<property name="" value="true"></property>
<property name="nullValue" value="NULL"></property>
<property name="locations">
<list>
<value>jdbc.properties</value>
</list>
</property>
</bean>
<bean id="dataSource" class="com.spring..JDBCConfig">
<property name="driverClassName" value="${${Env}.jdbc.driverClassName}"></property>
<property name="url" value="${${Env}.jdbc.url}"></property>
<property name="username" value="${${Env}.jdbc.username1}"></property>
<property name="password" value="${${Env}.jdbc.password}"></property>
</bean>
jdbc.properties
*****************************
Env=PROD
jdbc.driverClassName=${${Env}.jdbc.driverClassName}
jdbc.url=${${Env}.jdbc.url}
jdbc.username=${${Env}.jdbc.username}
jdbc.password=${${Env}.jdbc.password}
######### JDBC Configuration for DEV Environment ###############
DEV.jdbc.driverClassName=com.mysql.jdbc.Driver
DEV.jdbc.url=jdbc:mysql://localhost:3306/devportal
DEV.jdbc.username=DEVuser
DEV.jdbc.password=DEVpwd
######### JDBC Configuration for UAT Environment ############
UAT.jdbc.driverClassName=com.mysql.jdbc.Driver
UAT.jdbc.url=jdbc:mysql://localhost:3306/UATportal
UAT.jdbc.username=UATuser
UAT.jdbc.password=UATpwd
########## JDBC Configuration for PROD Environment ############
PROD.jdbc.driverClassName=com.mysql.jdbc.Driver
PROD.jdbc.url=jdbc:mysql://localhost:3306/portal
PROD.jdbc.username=root
PROD.jdbc.password=admin，
我這里有三套環境，分別是DEV，UAT和PROD，這種方式可以靈活切換的。
我再回答你的第二個問題：
還請你去http://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/html/transaction.html這里看下，很詳細，不過是英文的哦
⑵ 目前主流的Java分布式框架有哪些，學起來難不難
Java前景是很不錯的，像Java這樣的專業還是一線城市比較好，師資力量跟得上、就業的薪資也是可觀的，學習Java可以按照路線圖的順序，
0基礎學習Java是沒有問題的，關鍵是找到靠譜的Java培訓機構，你可以深度了解機構的口碑情況，問問周圍知道這家機構的人，除了口碑再了解機構的以下幾方面：
1. 師資力量雄厚
要想有1+1>2的實際效果，很關鍵的一點是師資隊伍，你接下來無論是找個工作還是工作中出任哪些的人物角色，都越來越愛你本身的技術專業java技術性，也許的技術專業java技術性則絕大多數來自你的技術專業java教師，一個好的java培訓機構必須具備雄厚的師資力量。
2. 就業保障完善
實現1+1>2效果的關鍵在於能夠為你提供良好的發展平台，即能夠為你提供良好的就業保障，讓學員能夠學到實在實在的知識，並向java學員提供一對一的就業指導，確保學員找到自己的心理工作。
3. 學費性價比高
一個好的Java培訓機構肯定能給你帶來1+1>2的效果，如果你在一個由專業的Java教師領導並由Java培訓機構自己提供的平台上工作，你將獲得比以往更多的投資。
希望你早日學有所成。
⑶ 在java中，事務是什麼有什麼用！
一、什麼是Java事務
通常的觀念認為，事務僅與資料庫相關。
事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性（atomicity）、一致性（consistency）、隔離性
（isolation）和持久性（rability）的縮寫。事務的原子性表示事務執行過程中的任何失敗都將導致事務所做的任何修改失效。一致性表示
當事務執行失敗時，所有被該事務影響的數據都應該恢復到事務執行前的狀態。隔離性表示在事務執行過程中對數據的修改，在事務提交之前對其他事務不可見。持
久性表示已提交的數據在事務執行失敗時，數據的狀態都應該正確。
通俗的理解，事務是一組原子操作單元，從資料庫角度說，就是一組SQL指令，要麼全部執行成功，若因為某個原因其中一條指令執行有錯誤，則撤銷先前執行過的所有指令。更簡答的說就是：要麼全部執行成功，要麼撤銷不執行。
既然事務的概念從資料庫而來，那Java事務是什麼？之間有什麼聯系？
實際上，一個Java應用系統，如果要操作資料庫，則通過JDBC來實現的。增加、修改、刪除都是通過相應方法間接來實現的，事務的控制也相應轉移到Java程序代碼中。因此，資料庫操作的事務習慣上就稱為Java事務。
二、為什麼需要事務
事務是為解決數據安全操作提出的，事務控制實際上就是控制數據的安全訪問。具一個簡單例子：比如銀行轉帳業務，賬戶A要將自己賬戶上的1000元
轉到B賬戶下面，A賬戶余額首先要減去1000元，然後B賬戶要增加1000元。假如在中間網路出現了問題，A賬戶減去1000元已經結束，B因為網路中
斷而操作失敗，那麼整個業務失敗，必須做出控制，要求A賬戶轉帳業務撤銷。這才能保證業務的正確性，完成這個操走就需要事務，將A賬戶資金減少和B賬戶資
金增加方到一個事務裡面，要麼全部執行成功，要麼操作全部撤銷，這樣就保持了數據的安全性。
三、Java事務的類型
Java事務的類型有三種：JDBC事務、JTA(Java Transaction API)事務、容器事務。
1、JDBC事務
JDBC 事務是用 Connection 對象控制的。JDBC Connection 介面( java.sql.Connection )提供了兩種事務模式：自動提交和手工提交。 java.sql.Connection 提供了以下控制事務的方法：
public void setAutoCommit(boolean)
public boolean getAutoCommit()
public void commit()
public void rollback()
使用 JDBC 事務界定時，您可以將多個 SQL 語句結合到一個事務中。JDBC 事務的一個缺點是事務的范圍局限於一個資料庫連接。一個 JDBC 事務不能跨越多個資料庫。
2、JTA(Java Transaction API)事務
JTA是一種高層的，與實現無關的，與協議無關的API，應用程序和應用伺服器可以使用JTA來訪問事務。
JTA允許應用程序執行分布式事務處理–在兩個或多個網路計算機資源上訪問並且更新數據，這些數據可以分布在多個資料庫上。JDBC驅動程序的JTA支持極大地增強了數據訪問能力。
如果計劃用 JTA 界定事務，那麼就需要有一個實現 javax.sql.XADataSource 、
javax.sql.XAConnection 和 javax.sql.XAResource 介面的 JDBC
驅動程序。一個實現了這些介面的驅動程序將可以參與 JTA 事務。一個 XADataSource 對象就是一個 XAConnection
對象的工廠。 XAConnection s 是參與 JTA 事務的 JDBC 連接。
您將需要用應用伺服器的管理工具設置 XADataSource 。從應用伺服器和 JDBC 驅動程序的文檔中可以了解到相關的指導。
J2EE 應用程序用 JNDI 查詢數據源。一旦應用程序找到了數據源對象，它就調用 javax.sql.DataSource.getConnection() 以獲得到資料庫的連接。
XA 連接與非 XA 連接不同。一定要記住 XA 連接參與了 JTA 事務。這意味著 XA 連接不支持 JDBC
的自動提交功能。同時，應用程序一定不要對 XA 連接調用 java.sql.Connection.commit() 或者
java.sql.Connection.rollback() 。相反，應用程序應該使用 UserTransaction.begin()、
UserTransaction.commit() 和 serTransaction.rollback() 。
3、容器事務
容器事務主要是J2EE應用伺服器提供的，容器事務大多是基於JTA完成，這是一個基於JNDI的，相當復雜的API實現。相對編碼實現JTA事
務管理，我們可以通過EJB容器提供的容器事務管理機制（CMT）完成同一個功能，這項功能由J2EE應用伺服器提供。這使得我們可以簡單的指定將哪個方
法加入事務，一旦指定，容器將負責事務管理任務。這是我們土建的解決方式，因為通過這種方式我們可以將事務代碼排除在邏輯編碼之外，同時將所有困難交給
J2EE容器去解決。使用EJB CMT的另外一個好處就是程序員無需關心JTA API的編碼，不過，理論上我們必須使用EJB。
四、三種事務差異
1、JDBC事務控制的局限性在一個資料庫連接內，但是其使用簡單。
2、JTA事務的功能強大，事務可以跨越多個資料庫或多個DAO，使用也比較復雜。
3、容器事務，主要指的是J2EE應用伺服器提供的事務管理，局限於EJB應用使用。
五、總結
事務控制是構建J2EE應用不可缺少的一部分，合理選擇應用何種事務對整個應用系統來說至關重要。一般說來，在單個JDBC
連接連接的情況下可以選擇JDBC事務，在跨多個連接或者資料庫情況下，需要選擇使用JTA事務，如果用到了EJB，則可以考慮使用EJB容器事務。
如果滿意請及時採納，謝謝~
⑷ JAVABean是什麼
javaBean在MVC設計模型中是model，又稱模型層，在一般的程序中，我們稱它為數據層，就是用來設置數據的屬性和一些行為，然後我會提供獲取屬性和設置屬性的get/set方法
⑸ java開發需要掌握哪些技術
第一階段，Java SE基礎：
Java環境搭建、Java流程式控制制語句-for循環、switch選擇判斷、循環嵌套、數組拷貝、多維數組、final關鍵字、構造函數的調用、類的訪問許可權和路徑、面向對象高級特性、Java異常處理、Set，Map，List介面及介面實現類、Java線程、同步阻塞、Java IO流、文件的操作，復制，讀寫，刪除等。
第二階段，JavaWeb：
MySQL安裝、管理、創建資料庫、MySQL UPDATE 查詢、Mysql高級操作、JDBC、JDBC資料庫連接操作，JDBC動態Sql處理、Servlet3.0 網頁重定向、Servlet3.0 新增的註解支持、AJAX、responseText屬性詳解等。
第三階段，Java高級框架-SSH：
Struts2 異常處理、Struts2+Log4j集成、Struts2和JSON實例、Hibernate5、Hibernate集合映射、Hibernate組件映射、Spring4.0、Spring AOP + AspectJ框架、Spring 與其它Web框架集成、Spring Hibernate支持等。
第四階段，Java高級框架-SSM：
SpringMVC、Spring MVC生成JSON數據、MyBatis、MyBatis 環境配置及入門、Mybatis set標簽、Mybatis trim標簽、Shiro、Shiro快速入門教程、Shiro Web應用等。
第五階段，SpringBoot+VUE全棧框架：
SpringBoot、全局異常處理、過濾器監聽器、EHCache緩存、SpringBoot Quartz定時任務、Vue、Vue.js 安裝、模板語法、計算屬性、事件處理器、Vue.js 自定義指令、Vue.js 路由等
第六階段，特色課程：
ActiveM環境搭建、生產者和消費者、消息持久化操作、RSA數字加密演算法、Codebar條形碼生成器、zxing二維碼生成器、HighCharts統計圖、Echarts統計圖、網路播放器ckplayer、嵌入式網路播放器，可以瀏覽器和移動端隨意使用
第七階段，互聯網框架的高級應用1：
分布式服務框架的理解，Dubbo架構設計詳解及其核心要點，框架運行原理分析、SpringData數據訪問、Lucene搜索引擎、Lucene的全文搜索伺服器介紹、索引建立方式、Solr海量數據搜索引擎、Socket網路通信、實現RMI遠程對象通訊、使用JMS消息服務、Kafka分布式消息系統、Web Service與Restful WS等
第八階段，互聯網框架的高級應用2：
Spring Security安全框架、實現Web應用安全控制、緩存應用與EhCache框架、OSCache與JBossCache框架、MyBatis與Hibernate緩存機制、NoSQL應用與SQL調優、MongoDB NoSQL資料庫、Redis內存資料庫、實現Redis Session共享、SQL語句的優化、實現資料庫讀寫分離、WEB應用集群及性能優化、Maven項目管理工具、Web伺服器負載均衡、實現Nginx與Tomcat集群、使用LoadRunner測試工具、性能優化之內存調優、代碼優化與重構的方法等。
對java有興趣的小夥伴們，不妨先從java入門開始！B站上有很多的java教學視頻，從基礎到高級的都有，還挺不錯的，知識點講的很細致，還有完整版的學習路線圖。也可以自己去看看，下載學習試試。
⑹ java的框架spring如何配置分布式事務
分布式事務是指操作多個資料庫之間的事務，在tomcat下是沒有分布式事務的，可以藉助於第三方Jotm和Automikos實現，下面就寫一個使用Jotm實現分布事務的例子，如有不足，請各位大大指點：
Dao及實現，先寫出一個interface再去實現他，可能有些人覺得直接寫實現類多好，但我還是建議為了結構清晰，增強代碼的可讀性，可維護性還是先寫介面再去實現的好：
先寫一個interface，定義要實現的方法：
⑺ Java-JAVA中都有哪幾種分布式實現方式，各有什麼優缺點
常用的有EJB、rmi、Web Service，還有Hessian、NIO等，它們的優缺點比較比下：
1：EJB
優勢：可擴展性好，安全性強，支持分布式事務處理。
劣勢：不能跨語言；配置相對復雜，不同J2EE容器之間很難做無縫遷移。
2:rmi
優勢：面向對象的遠程服務模型；基於TCP協議上的服務，執行速度快。
劣勢：不能跨語言；每個遠程對象都要綁定埠，不易維護；不支持分布式事務JTA,RMI框架對於安全性、事務、可擴展性的支持非常有限。
3： Web Service
優勢：跨語言、跨平台，SOA思想的實現；安全性高；可以用來兼容legacy系統的功能
劣勢：性能相對差，不支持兩階段事務
4：Hessian
優勢：使用簡單，速度快；跨語言，跨平台；可以用來兼容legacy系統的功能。
劣勢：安全性的支持不夠強，不支持兩階段事務。
5：NIO(Mina/Netty)
優點：基於TCP通信，效率上高於HTTP的方式，非阻塞IO應對高並發綽綽有餘。根據具體的需要制定數據傳輸的格式，可擴展性強。
缺點：不能跨語言，無法穿透防火牆。
⑻ 資料庫架構選型與落地，看這篇就夠了
隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。
因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。
以下，我從資料庫架構、選型與落地來讓大家入門。
資料庫會面臨什麼樣的挑戰呢？
業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。
為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。
將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。
這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。
因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；
優點：
缺點：
在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。
優點：
缺點：
在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。
這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。
但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。
所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。
優點：
缺點：
四、分庫分表
在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。
所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。
分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。
優點：
缺點：
註：分庫還是分表核心關鍵是有沒有IO瓶頸 。
分片方式都有什麼呢？
RANGE（范圍分片）
將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。
比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。
優點：
缺點：
HASH（哈希分片）
將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。
優點：
缺點：
講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。
那麼，我們應該如何選擇資料庫架構呢？
雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。
混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。
1、對事務支持
分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。
2、多庫結果集合並 （group by，order by）
由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。
3、數據延遲
主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。
4、跨庫join
分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。
5、分片擴容
水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。
6、ID生成
分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。
一、應用層依賴類（JDBC）
這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。
此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。
中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。
優點
缺點
二、中間層代理類（Proxy）
這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。
所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。
在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。
比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。
優點
缺點
JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。
Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。
混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。
JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。
ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。
向 應用程序完全透明 ，可直接當做MySQL使用。
適用於任何兼容MySQL協議的客戶端。
Sharding-JDBC
定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。
以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。
分庫（用戶）
問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。
拆分維度：企業ID分庫
拆分策略：頭部企業單獨庫、非頭部企業一個庫
分庫分表（訂單）
問題解析：訂單數據增長速度較快，在分庫之餘需要分表。
拆分維度：企業ID分庫、用戶ID分表
拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表
單庫分表（附件）
問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。
拆分維度：用戶ID分表
拆分策略：用戶ID取模分表
問題一：分布式事務
分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。
問題二：分布式ID
問題三：跨片查詢
舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。
sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。
假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；
特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）
問題四：分片擴容
隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。
假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。
問題五：一致性哈希
首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）
其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。
然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。
所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。
好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。
老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！
本文作者：Jensen
7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。
曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。
技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。
交個朋友，一起成長！