技術文章 » 【解決方案】MySQL5.7 百萬資料遷移到 ElasticSearch7.x 的思考

【解決方案】MySQL5.7 百萬資料遷移到 ElasticSearch7.x 的思考

2023-12-06 18:01:05

目錄

前言

在日常專案開發中，可能會遇到使用 ES 做關鍵詞搜尋的場景，但是一般來說業務資料是不會直接通過 CRUD 寫進 ES 的。

因為這可能違背了 ES 是用來查詢的初衷，資料持久化的事情可以交給資料庫來做。那麼，這裡就有一個顯而易見的問題：ES 裡的資料從哪裡來？

本文介紹的就是如何將 MySQL 的表資料遷移到 ES 的全過程。

一、一次性全量

該方案的思路很簡單直接：將資料庫中的表資料一次性查出，放入記憶體，在轉換 DB 與 ES 的實體結構，遍歷迴圈將 DB 的資料 放入 ES 中。

但是對機器的效能考驗非常大：本地 MySQL 10w 條資料，電腦記憶體16GB，僅30秒鐘記憶體佔用90%，CPU佔用100%。太過於粗暴了，不推薦使用。

@Component05
@Slf4j
public class FullSyncArticleToES implements CommandLineRunner {

    @Resource
    private ArticleMapper articleMapper;

    @Resource
    private ArticleRepository articleRepository;

    /**
     * 執行一次即可全量遷移
     */
    //todo: 弊端太明顯了，資料量一大的話，對記憶體和 cpu 都是考驗，不推薦這麼簡單粗暴的方式
    public void fullSyncArticleToES() {
        LambdaQueryWrapper<Article> wrapper = new LambdaQueryWrapper<>();
        List<Article> articleList = articleMapper.selectList(wrapper);
        if (CollectionUtils.isNotEmpty(articleList)) {
            List<ESArticle> esArticleList = articleList.stream().map(ESArticle::dbToEs).collect(Collectors.toList());
            final int pageSize = 500;
            final int total = esArticleList.size();
            log.info("------------FullSyncArticleToES start!-----------, total {}", total);
            for (int i = 0; i < total; i += pageSize) {
                int end = Math.min(i + pageSize, total);
                log.info("------sync from {} to {}------", i, end);
                articleRepository.saveAll(esArticleList.subList(i, end));
            }
            log.info("------------FullSyncPostToEs end!------------, total {}", total);
        }
        else {
            log.info("------------DB no Data！------------");
        }
    }
    @Override
    public void run(String... args) {}
}

二、定時任務增量

這種方案的思想是按時間範圍以增量的方式讀取，比全量的一次性資料量要小很多。

也存在弊端：頻繁的資料庫連線 + 讀寫，對伺服器資源消耗較大。且在極端短時間內大量資料寫入的場景，可能會導致效能、資料不一致的問題（即來不及把所有資料都查到，同時還要寫到 ES）。

但還是有一定的可操作性，畢竟可能沒有那麼極端的情況，高並行寫入的場景不會時刻都有。

@Component
@Slf4j
public class IncSyncArticleToES {
    @Resource
    private ArticleMapper articleMapper;

    @Resource
    private ArticleRepository articleRepository;

    /**
     * 每分鐘執行一次
     */
    @Scheduled(fixedRate = 60 * 1000)
    public void run() {
        // 查詢近 5 分鐘內的資料，有 id 重複的資料 ES 會自動覆蓋
        Date fiveMinutesAgoDate = new Date(new Date().getTime() - 5 * 60 * 1000L);
        List<Article> articleList = articleMapper.listArticleWithData(fiveMinutesAgoDate);
        if (CollectionUtils.isNotEmpty(articleList)) {
            List<ESArticle> esArticleList = articleList.stream().map(ESArticle::dbToEs).collect(Collectors.toList());
            final int pageSize = 500;
            int total = esArticleList.size();
            log.info("------------IncSyncArticleToES start!-----------, total {}", total);
            for (int i = 0; i < total; i += pageSize) {
                int end = Math.min(i + pageSize, total);
                log.info("sync from {} to {}", i, end);
                articleRepository.saveAll(esArticleList.subList(i, end));
            }
            log.info("------------IncSyncArticleToES end!------------, total {}", total);
        }
        else {
            log.info("------------DB no Data！------------");
        }
    }
}

三、強一致性問題

如果大家看完以上兩個方案，可能會有一個問題：

無論是增量還是全量， MySQL 和 ES 進行連線/讀寫是需要耗費時間的，如果這個過程中如果有大量的資料插到 MySQL 裡，那麼有沒有可能寫入 ES 裡的資料並不能和 MySQL 裡的完全一致？

答案是：在資料量大和高並行的場景下，是很有可能會發生這種情況的。

如果需要我們自己寫程式碼來保證一致性，可以怎麼做才能較好地解決呢？

思路：由於 ES 查詢做了分頁，每次查只有10 條，那麼每次呼叫查詢的時候，就拿這10條資料的唯一標識 id 再去 MySQL 中查一下，MySQL 裡有的就會被查出來，那麼返回這些結果就好，就不直接返回 ES 的查詢結果了；同時刪除掉 ES 裡那些在資料庫中被刪除的資料，做個」反向同步「。這個思路有幾個明顯的優點：

1、單次資料量很小，在記憶體中操作幾乎就是毫秒級的；

2、返回的是 MySQL 的源資料，不再 」信任「 ES 了，保證強一致性；

3、反向刪除 ES 中的那些已經被 MySQL 刪除了的資料。

以下是程式碼，註釋很詳細，應該很好理解：

@Override
public PageInfo<Article> testSearchFromES(ArticleSearchDTO articleSearchDTO){
    // 獲取查詢物件的結果, searchQuery 這裡忽略，就當查詢條件已經寫好了，可以查到資料
    SearchHits<ESArticle> searchHits = elasticTemplate.search(searchQuery, ESArticle.class);
    //todo: 以下考慮使用 MySQL 的源資料，不再以 ES 的資料為準
    List<Article> resultList = new ArrayList<>();
    // 從 ES 查出結果後，再與 db 獲的資料進行對比，確認後再組裝返回
    if (searchHits.hasSearchHits()) {
        // 收集 ES 裡業務物件的 Id 成 List
        List<String> articleIdList = searchHits.getSearchHits().stream()
            .map(val -> val.getContent().getId())
            .collect(Collectors.toList());
        // 獲取資料庫的符合體條件的資料，由於是分頁的，一次性的資料量小（10條而已），剩下的都是記憶體操作，效能可以保證
        List<Article> articleList = baseMapper.selectBatchIds(articleIdList);
        if (CollectionUtils.isNotEmpty(articleList)) {
            //根據 db 裡業務物件的 Id 進行分組
            Map<String , List<Article>> idArticleMap = articleList.stream().collect(Collectors.groupingBy(Article::getId));
            //對 ES 中的 Id 的集合進行 for 迴圈，經過對比後新增資料
            articleIdList.forEach(articleId -> {
                // 如果 ES 裡的 Id 在資料庫裡有，說明資料已經同步到 ES 了，兩邊的資料是一致的
                if (idArticleMap.containsKey(articleId)) {
                    // 則把符合的資料放入 page 物件中
                    resultList.add(idArticleMap.get(articleId).get(NumberUtils.INTEGER_ZERO));
                } else {
                    // 刪除 ES 中那些在資料庫中被刪除的資料；因為資料庫都沒有這條資料庫了，那麼 ES 裡也不能有，算是一種反向同步吧
                    String delete = elasticTemplate.delete(String.valueOf(articleId), PostEsDTO.class);
                    log.info("delete post {}", delete);
                }
            });
        }
    }
    // 初始化 page 物件
    PageInfo<Article> pageInfo = new PageInfo<>();
    pageInfo.setList(resultList);
    pageInfo.setTotal(searchHits.getTotalHits());
    System.out.println(pageInfo);
    return pageInfo;
}

然而，以上的所有內容並不是今天文章的重點。只是為引入 canal 做的鋪墊，引入、安裝、設定好 canal 後可以解決以上的全部問題。對，就是全部。

四、canal 框架

4.1基本原理

canal 是 Alibaba 開源的一個用於 MySQL 資料庫增量資料同步工具。它通過解析 MySQL 的 binlog 來獲取增量資料，並將資料傳送到指定位置。

canal 會模擬 MySQL slave 的互動協定，偽裝自己為 MySQL 的 slave ，向 MySQL master 傳送 dump 協定。MySQL master 收到 dump 請求，開始推播 bin-log 給 slave (即 canal )。

canal 簡單原理

canal 的高可用分為兩部分：canal server 和 canal client。

canal server 為了減少對 MySQL dump 的請求，不同 server 上的範例要求同一時間只能有一個處於 running 狀態；

canal client 為了保證有序性，一份範例同一時間只能由一個 canal client 進行 get/ack/rollback 操作來保證順序。

canal 高可用

4.2安裝使用（重點）

  • 版本說明
    • Centos 7（這個關係不大）
    • JDK 11（這個很關鍵）
    • MySQL 5.7.36（只要5.7.x都可）
    • Elasticsearch 7.16.x（不要太高，比較關鍵）
    • cannal.server: 1.1.5（有官方映象，放心拉取）
    • canal.adapter: 1.1.5（無官方映象，但問題不大）

注：我這裡由於自己的個人伺服器的一些中介軟體版本問題，始終無法成功安裝上 canal-adapter，所以沒有最終將資料遷移到 ES 裡去。

主要原因在於兩點：

  1. JDK 版本需要 JDK11及以上，我自己個人伺服器現用的是 JDK 8，但 canal 並不相容 JDK 8；
  2. 我的 ES 的版本太高用的是7.6.1，這可能導致 canal 版本與它不相容，可能實際需要降低到7.16.x 左右。

但是本人在工作中是有過專案實踐的，推薦使用 docker 安裝 canal，步驟參考：https://zhuanlan.zhihu.com/p/465614745

4.3引入依賴（測試）

<!-- https://mvnrepository.com/artifact/com.alibaba.otter/canal.client -->
<dependency>
    <groupId>com.alibaba.otter</groupId>
    <artifactId>canal.client</artifactId>
    <version>1.1.4</version>
</dependency>

4.4程式碼範例（測試）

以下程式碼 demo 來自官網，僅用於測試。

首先需要連線上4.2小節中的 canal-server 設定，然後啟動該類中的 main 方法後會不斷去監聽對應的 MySQL 庫-表資料是否有變化，有的話就列印出來。

public class CanalClientUtils {
    public static void main(String[] args) {
        // 建立連線
        CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress
                ("你的公網ip地址", 11111), "example", "", "");
        int batchSize = 1000;
        int emptyCount = 0;
        try {
            connector.connect();
            connector.subscribe(".*\\..*");
            connector.rollback();
            int totalEmptyCount = 1000;
            while (emptyCount < totalEmptyCount) {
                // 獲取指定數量的資料
                Message message = connector.getWithoutAck(batchSize);
                long batchId = message.getId();
                int size = message.getEntries().size();
                if (batchId == -1 || size == 0) {
                    emptyCount++;
                    System.out.println("empty count : " + emptyCount);
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                    }
                } else {
                    emptyCount = 0;
                    System.out.printf("message[batchId=%s,size=%s] \n", batchId, size);
                    printEntry(message.getEntries());
                }
                // 提交確認
                connector.ack(batchId);
                // 處理失敗, 回滾資料
                //connector.rollback(batchId);
            }
            System.out.println("empty too many times, exit");
        } finally {
            // 關閉連線
            connector.disconnect();
        }
    }
    private static void printEntry(List<CanalEntry.Entry> entries) {
        for (CanalEntry.Entry entry : entries) {
            if (entry.getEntryType() == CanalEntry.EntryType.TRANSACTIONBEGIN || entry.getEntryType() == CanalEntry.EntryType.TRANSACTIONEND) {
                continue;
            }
            CanalEntry.RowChange rowChage;
            try {
                rowChage = CanalEntry.RowChange.parseFrom(entry.getStoreValue());
            } catch (Exception e) {
                throw new RuntimeException("ERROR ## parser of error-event has an error , data:" + entry, e);
            }
            CanalEntry.EventType eventType = rowChage.getEventType();
            System.out.printf(
                    "-----------binlog[%s:%s] , name[%s,%s] , eventType：%s%n ------------",
                    entry.getHeader().getLogfileName(), entry.getHeader().getLogfileOffset(),
                    entry.getHeader().getSchemaName(), entry.getHeader().getTableName(),
                    eventType);
            for (CanalEntry.RowData rowData : rowChage.getRowDatasList()) {
                if (eventType == CanalEntry.EventType.DELETE) {
                    printColumn(rowData.getBeforeColumnsList());
                } else if (eventType == CanalEntry.EventType.INSERT) {
                    printColumn(rowData.getAfterColumnsList());
                } else {
                    System.out.println("---------before data----------");
                    printColumn(rowData.getBeforeColumnsList());
                    System.out.println("---------after data-----------");
                    printColumn(rowData.getAfterColumnsList());
                }
            }
        }
    }
    private static void printColumn(List<CanalEntry.Column> columns) {
        for (CanalEntry.Column column : columns) {
            System.out.println(column.getName() + " : " + column.getValue() + "，update status：" + column.getUpdated());
        }
    }
}

預期的結果會表明涉及的庫、表名稱，以及操作的型別，同時還可以知道欄位的狀態：true 為有變化，false 為無變化。如下圖所示：

canal 監聽範例

以上的4.3和4.4小節都是用來測試效果的，在伺服器上安裝設定好 canal 以後，實際無需在專案中寫關於 canal 的操作程式碼。

每一步的 MySQL 操作 binlog 都會被 canal 獲取到，然後將資料同步到 ES 中，這些操作都是在伺服器上進行的，基本上對於開發人員來說是無感的。

阿里雲上有專門的產品來支援資料從 MySQL 遷移到 ES 的場景，真正的商業專案開發，還是可以選擇雲廠商現有的方案（我不是打廣告）：

https://help.aliyun.com/zh/dts/user-guide/migrate-data-from-an-apsaradb-rds-for-mysql-instance-to-an-elasticsearch-cluster?spm=a2c4g.11186623.0.0.33626255Aql88M

五、文章小結

到這裡我就和大家分享完了關於資料從 MySQL 遷移到 ES 全過程的思考，如有錯誤和不足，期待大家的指正和交流。

參考檔案：

  1. 阿里巴巴 canal 的 GitHub 開源專案地址：https://github.com/alibaba/canal
  2. 安裝以及設定步驟：https://zhuanlan.zhihu.com/p/465614745