一、業務背景

目前生產庫數據庫服務器數據存儲達到了13T，其中license_spart表數據量達到了200億，占用7.5T，空間占用率達到54%。而且這張表每年數據增長量達到30億。其中有效VALID數據占20億，無效數據INVALID占180億。由于業務上有些場景，需要查詢無效數據，所以不能直接刪除。隨著license_spart表規模持續擴大，會帶來嚴重的性能問題、存儲成本增加、備份與恢復困難、數據一致性問題（生產4臺服務器）等等。

二、整體目標

將license_spart數據整體遷移到歸檔庫，主庫license_spart只保留最新的3個月的有效VALID數據，歸檔庫按照年份保存有效和無效數據，實現主庫license_spart存儲大幅縮減。

二、治理策略

1、歸檔庫按照年份創建數據表

整體采用分庫分表方案，申請歸檔庫數據庫服務器資源，然后創建license_spart_2018到license_spart_2035這18張表。歸檔庫表字段跟主庫license_spart表字段高度保持一致。

2、分析數據量及規模，指定定時同步策略

分析主庫license_spart表的日增長量達1000w（其中有效數據達20w），所以針對2025年以前的數據，采用【全量】+【實時】同步方式；針對2025年之后的數據，采用【實時】方式。

同步方式	定時任務名	源表	目標表	查詢條件
全量+實時	license_spart_2018	license_spart	license_spart_2008	lsn < ‘LIC2019’
全量+實時	license_spart_2019	license_spart	license_spart_2019	lsn like ‘LIC2019%’
…	…	…	…	…
實時	license_spart_2026	license_spart	license_spart_2026	lsn like ‘LIC2026%’

由于數據量比較大，可以在業務不繁忙時間（比如凌晨0點~5點），分100批次同步數據，每次同步5w數據，根據實際情況可以動態調整參數大小。

主庫數據同步完成后，建議保留3~4個月時間（2個迭代版本），無問題，再清空生產主庫無效數據。

3、編寫讀取歸檔庫工具類

Spring框架中，Spring-JDBC模塊提供了AbstractRoutingDataSource，其內部可以包含了多個DataSource，通過繼承該類并覆蓋determineCurrentLookupKey方法，可以根據業務需求動態選擇數據源。利用AOP注解實現動態切換數據源，參考利用AOP實現數據庫讀寫分離。

編寫一個公共查詢歸檔庫Service方法，由于歸檔庫跟主庫物理分離，所以采用無事務方式，否則會不生效。lsn組成分為LIC+年份+XXXX+標識等構成，通過對lsn的前7位進行切分，能夠找對對應的歸檔庫。

@DataSource("archiving")
public List<String> getArchivingLsnList(List<String> lsnList){// 根據入參lsn進行切分...
}

這樣在業務代碼查詢license_spart時候，如果返回lsnList結果為空，再利用getArchivingLsnList查詢歸檔庫數據，進行補充。

4、生產驗證及回滾

生產上線后，驗證同步的數據是否準確，業務邏輯查詢和修改是否無誤等。如果有問題，及時回滾。

5、定時任務刪除生產庫數據

編寫定時任務定期清理2個月前的數據，利用相關同步工具每天進行物理刪除2個月前的主庫數據。

針對主庫舊表數據清理，采用表重命名方式，進行替換，最后刪除舊表。