在這個燥熱的夏天，又突然收到告警，分庫分表的主鍵衝突了，這還能忍？不，堅決不能忍，必須解決掉！後面咱們慢慢道來是如何破局的，如何走了一條坎坷路…… ...
伴隨著業務的不斷發展，逐漸由單庫單表向分庫分表進行發展。在這個過程中不可避免的一個問題是確保主鍵要的唯一性，以便於後續的數據聚合、分析等等場景的使用。在進行分庫分表的解決方案中有多種技術選型，大概分為兩大類客戶端分庫分表、服務端分庫分表。例如 Sharding-JDBC、ShardingSphere、 MyCat、 ShardingSphere-Proxy、Jproxy(京東內部已棄用)等等。
在這個燥熱的夏天，又突然收到告警，分庫分表的主鍵衝突了，這還能忍？不，堅決不能忍，必須解決掉！後面咱們慢慢道來是如何破局的，如何走了一條坎坷路……
翻山第一步
咱們的系統使用的是ShardingSphere進行分庫分表的，大概的配置信息如下：（出於信息的安全考慮，隱藏了部分信息，只保留的部分內容，不要在意這些細節能說明問題即可）
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sharding="http://shardingsphere.apache.org/schema/shardingsphere/sharding"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd http://shardingsphere.apache.org/schema/shardingsphere/sharding http://shardingsphere.apache.org/schema/shardingsphere/sharding/sharding.xsd">
<!--數據源-->
<bean id="database1" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close">
</bean>
<bean id="database2" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close">
</bean>
<bean id="database3" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close">
</bean>
<sharding:inline-strategy id="databaseStrategy" sharding-column="cloum1" algorithm-expression="table1_$->{(Math.abs(cloum1.hashCode()) % 512).intdiv(32) }" />
<sharding:inline-strategy id="orderNoDatabaseStrategy" sharding-column="cloum2" algorithm-expression="table2_$->{(Math.abs(cloum2.hashCode()) % 512).intdiv(32) }" />
<sharding:inline-strategy id="businessNoDatabaseStrategy" sharding-column="cloum3" algorithm-expression="table3_$->{(Math.abs(cloum3.hashCode()) % 512).intdiv(32) }" />
<!-- 主鍵生成策略 -雪花演算法-->
<sharding:key-generator id="idKeyGenerator" type="SNOWFLAKE" column="id" props-ref="snowFlakeProperties"/>
<sharding:data-source id="dataSource">
<sharding:sharding-rule data-source-names="database1,database2,database3">
<sharding:table-rules>
<sharding:table-rule logic-table="table1"
actual-data-nodes="database1_$->{0..15}.table1_$->{0..31}"
database-strategy-ref="orderNoDatabaseStrategy"
table-strategy-ref="order_waybill_tableStrategy"
key-generator-ref="idKeyGenerator"/>
<sharding:table-rule logic-table="table2"
actual-data-nodes="database2_$->{0..15}.table2_$->{0..31}"
database-strategy-ref="databaseStrategy"
table-strategy-ref="waybill_contacts_tableStrategy"
key-generator-ref="idKeyGenerator"/>
<sharding:table-rule logic-table="table3"
actual-data-nodes="database3_$->{0..15}.table3->{0..31}"
database-strategy-ref="databaseStrategy"
table-strategy-ref="waybill_tableStrategy"
key-generator-ref="idKeyGenerator"/>
</sharding:table-rules>
</sharding:sharding-rule>
</sharding:data-source>
<bean id="sqlSessionFactory" class="com.baomidou.mybatisplus.extension.spring.MybatisSqlSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" value="classpath:spring/mybatis-env-setting.xml"/>
<property name="mapperLocations" value="classpath*:/mapper/*.xml"/>
</bean>
</beans>
從上面的配置可以看出配置的是"SNOWFLAKE" 主鍵使用的是雪花演算法，雪花演算法產生的ID的組成總計64位，第一位為符號位不用，後41位為時間戳用於區別不同的時間點，在後面10位為workId用於區別不同的機器，最後12位為sequence用於同一時刻同一機器的併發數量。
那接下來就看看咱們自己的系統是怎麼配置的吧,其中的屬性snowFlakeProperties配置如下,其中的max.vibration.offset配置表示sequence的範圍為1024。按照正常的理解任何單個機器的配置都很難達到這個併發量，難道是這個值沒有生效？
<sharding:key-generator id="idKeyGenerator" type="SNOWFLAKE" column="id" props-ref="snowFlakeProperties"/>
shardingsphere中實現獲取主鍵的實現源碼如下簡述，具體的實現類org.apache.shardingsphere.core.strategy.keygen.SnowflakeShardingKeyGenerator,從源碼看源碼竟然一個日誌都沒有，那讓咱們怎麼去排查呢？怎麼證明咱們的猜想是否正確的呢？囧……
真是敗也蕭何成也蕭何，shardingsphere是通過java的SPI的方式進行的主鍵生成策略的擴展。自定義實現方式如下：實現org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator介面，如果自己想要實現使用SPI方式進行載入即可，那就讓咱們自己加日誌吧，走你……
既然都自己寫實現了，那日誌就該加的都加吧，咱這絕不吝嗇這幾行日誌
修改主鍵選擇生成策略為自己實現的類 type="MYSNOWFLAKE"
<sharding:key-generator id="idKeyGenerator" type="MYSNOWFLAKE" column="id" props-ref="snowFlakeProperties"/>
啟動看日誌，屬性中有max.vibration.offset=1024這個屬性，竟然依舊拿到的還是預設的值1，驚訝中，細細一瞅，終究發現了問題，在getProperty(key)時如果返回的不是String類型那麼為null，進而取值預設值1。從咱們的系統配置中可以看到系統配置的int類型的的1024，所以取值預設值1就說通了。
INFO 2023-08-17 14:07:51.062 2174320.63604.16922524693996408 176557 com.jd.las.waybill.center.config.MySnowflakeShardingKeyGenerator.getMaxVibrationOffset(MySnowflakeShardingKeyGenerator.java:107) -- 選擇自定義的雪花演算法獲取到的properties={"max.vibration.offset":1024,"worker.id":"217","max.tolerate.time.difference.milliseconds":"3000"}
INFO 2023-08-17 14:07:51.063 2174320.63604.16922524693996408 176558 com.jd.las.waybill.center.config.MySnowflakeShardingKeyGenerator.getMaxVibrationOffset(MySnowflakeShardingKeyGenerator.java:110) -- 選擇自定義的雪花演算法獲取到的getMaxVibrationOffset=1
截止到目前主鍵重覆的問題終於可以解釋的通了，因為併發支持的是0~1總共2個併發，所以在生產系統中尤其出現生產波次的時候出現重覆值的可能性是存在的,然後把1024變成字元串修改上線，相信系統後面應該不會產生此類問題了。
越嶺第二步
如果生活總是喜歡跟你開玩笑，逗你玩，那你就配合它笑一笑吧。
當上完線後，過了一段時間發現重覆主鍵的問題竟然依舊存在只是頻率少了些,不科學呀……
重新梳理思路，進行更詳細的日誌輸出，下單進行驗證，將接單落庫這坨代碼一併都加上日誌以及觸發雪花演算法的生成的ID也加上日誌
通過日誌分析，又又又發現"靈異事件"，10條插入SQL，只有兩條觸發了shardingsphere的雪花演算法，詫異的很呀~
查看其他8張表落庫的ID數據如下圖，ID(1692562397556875266) 都為1692開頭且長度20位，而shardingsphere產生的ID（899413419526356993）都為899開頭且長度19位，很明顯這8張表的主鍵不是shardingsphere生成的，那是這20位的數據哪來的呢？？？從ID上看明顯也不是自增產生的主鍵，又不科學了……
又是一個深夜……
梳理思路重新在鋝，主鍵相關的除了數據自增長、shardingsphere配置的雪花還有唯一的一個相關的組件那就是mybatis，由於項目是很早之前的應用了，使用的是baomidou的mybaits插件，如圖是插件的入口，MybatisSqlSessionFactoryBean實現FactoryBean
baomidou涉及該塊問題的源碼如下：
如果GlobalConfig沒有配置workId和DataCenterId會使用無參構造，預設的workId
baomidou的雪花演算法和shardingphere思路一致有一點點區別在於第12位和22位有datacenter<<17|workId<<12獲取，且datacenter和workId需要在0~31之間
不同機器的Name：
所以又解釋了為什麼不同機器會出現相同的主鍵問題，但是如果有細心的同學就會問為啥10張表中有8張表走的是baomidou的雪花演算法呢，那是因為baomidou會判斷保存的入參實體bean上是否有id欄位，是否能匹配上該欄位，如果存在則在baomidou這層就給賦值了baomidou雪花演算法生產的ID，後續就不會再次觸發shardingsphere中ID生成，進而導致該問題。
截止到目前終於又解釋通了為什麼跨機器會產生相同的主鍵問題。
問題的解決方式：
baomidou配置的過程中指定workId和centerDataId，但是需要確保centerDataId<<17|workId<<12確保唯一。類比shardingphere，借用shardingphere中的12~22位唯一數，前5高位給(centerDataId<<17),後5低位給workId<<12;
夜已沉默……
生產環境已上線驗證通過
作者：京東物流 王義傑
來源：京東雲開發者社區 自猿其說Tech 轉載請註明來源
