線上業務優化之案例實戰

2023-12-10 21:03:38

本文是我從業多年開發生涯中針對線上業務的處理經驗總結而來,這些業務或多或少相信大家都遇到過,因此在這裡分享給大家,大家也可以看看是不是遇到過類似場景。本文大綱如下,

後臺上傳檔案

線上後臺專案有一個訊息推播的功能,運營新建一條通知訊息時,需要一起上傳一列包含使用者 id 的檔案,來給檔案中包含的指定使用者推播系統訊息。

如上功能描述看著很簡單,但是實際上處理上傳檔案這一步是由講究的,假如說後臺上傳檔案太大,導致記憶體溢位,又或者讀取檔案太慢等其實都是一些隱性的問題。

對於技術側想要做好這個功能,保證大使用者量(比如達到百萬級別)下,上傳檔案、傳送訊息功能都正常,其實是需要仔細思考的,我這裡給出我的優化思路,

上傳檔案型別選擇

通常情況下大部分使用者都會使用 Excel 檔案作為後臺上傳檔案型別,但是相比 Excel 檔案,還有一種更加推薦的檔案格式,那就是 CSV 檔案。

CSV 是一種純文字格式,資料以文字形式儲存,每行資料以逗號分隔,沒有任何格式化。

因此 CSV 適用於簡單、易讀、匯入和匯出的場景,而且由於 CSV 檔案只包含純文字,因此檔案大小通常比 Excel 檔案小得多。

但是 CSV 檔案針對複雜電子試算表操作的支援就沒 Excel 功能那麼強大了,不過在這個只有一列的檔案上傳業務裡夠用了。

假如說上傳檔案中包含 100 萬用戶 id,那麼這裡使用 CSV 檔案上傳就有明顯優勢,佔用記憶體更少,處理上傳檔案也更快。

訊息推播狀態儲存

由於大批次資料插入是一個耗時操作(可能幾秒也可能幾分鐘),所以需要儲存批次插入是否成功的狀態,在後臺中還需要顯現出這條訊息推播狀態是成功還是失敗,方便運營人員回溯訊息推播狀態。

批次寫入

針對這裡上傳大檔案時的批次寫入場景,這裡提幾個點大家注意一下就行,

rewriteBatchedStatements=true

MySQL 的 JDBC 連線的 url 中要加 rewriteBatchedStatements 引數,並保證 5.1.13 以上版本的驅動,才能實現高效能的批次插入。

MySQL JDBC 驅動在預設情況下會無視 executeBatch()語句,把我們期望批次執行的一組 sql 語句拆散,一條一條地發給 MySQL 資料庫,批次插入實際上是單條插入,直接造成較低的效能。只有把 rewriteBatchedStatements 引數置為 true, 驅動才會幫你批次執行 SQL。另外這個選項對 INSERT/UPDATE/DELETE 都有效。

是否啟用事物功能

批次寫入場景裡要不要啟用事物,其實很多人都有自己的看法,這裡我給出啟用於不啟用的利弊,

  • 啟用事務:好處在於如批次插入過程中,異常情況可以保證原子性,但是效能比不開事務低,在特巨量資料量下會明顯低一個檔次
  • 不啟用事務:好處就是寫入效能高,特巨量資料量寫入效能提升明顯,但是無法保證原子性

在本文提到的大檔案上傳批次寫入的場景下,要是追求極致效能我推薦是不啟用事務的。

假如在批次寫入過程中發生網路波動或者資料庫宕機,我們其實只需要重新新建一條通知訊息,然後重新上傳包含使用者 id 的檔案即可。

因為上一條通知訊息因為批次插入步驟沒有全部完成,所以推播狀態是失敗。後續等開發人員處理一下髒資料即可。

大事務

@TransactionalSpring 框架提供得事務註解,相信這是許多人都知道的,但是在一些高效能場景下,是不建議使用的,推薦通過程式設計式事務來手動控制事務提交或者回滾,減少事務影響範圍,因而提升效能。

使用事務註解

如下是一段訂單超時未支付回滾業務資料得程式碼,採用 @Transactional 事務註解

@Transactional(rollbackFor = Exception.class)
public void doUnPaidTask(Long orderId) {
    // 1. 查詢訂單是否存在
    Order order = orderService.getById(orderId);
    ,,,

    // 2. 更新訂單為已取消狀態
    order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());
    orderService.updateById(order);
    ...
    // 3. 訂單商品數量增加
    LambdaQueryWrapper<OrderItem> queryWrapper = Wrappers.lambdaQuery();
    queryWrapper.eq(OrderItem::getOrderId, orderId);
    List<OrderItem> orderItems = orderItemService.list(queryWrapper);
    for (OrderItem orderItem : orderItems) {
        Long goodsId = orderItem.getGoodsId();
        Integer goodsCount = orderItem.getGoodsCount();
        if (!goodsDao.addStock(goodsId, goodsCount)) {
            throw new BusinessException("秒殺商品貨品庫存增加失敗");
        }
    }

    // 4. 返還使用者優惠券
    couponService.releaseCoupon(orderId);
    log.info("---------------訂單orderId:{},未支付超時取消成功", orderId);
}

可以看到上面訂單回滾的程式碼邏輯有四個步驟,如下,

  1. 查詢訂單是否存在
  2. 更新訂單為已取消狀態
  3. 訂單商品數量增加
  4. 返還使用者優惠券

這裡面有個問題,訂單回滾方法裡面其實只有 2、3、4 步驟是需要在一個事物裡執行的,第 1 步其實可以放在事物外面來執行,以此縮小事物範圍。

使用程式設計式事務

使用程式設計式事務對其優化後,程式碼如下,

@Resource
private PlatformTransactionManager platformTransactionManager;
@Resource
private TransactionDefinition transactionDefinition;

public void doUnPaidTask(Long orderId) {
    // 啟用程式設計式事務
    // 1. 在開啟事務錢查詢訂單是否存在
    Order order = orderService.getById(orderId);
    ...
    // 2. 開啟事務
    TransactionStatus transaction = platformTransactionManager.getTransaction(transactionDefinition);
    try {
        // 3. 設定訂單為已取消狀態
        order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());
        orderService.updateById(order);
        ...
        // 4. 商品貨品數量增加
        LambdaQueryWrapper<OrderItem> queryWrapper = Wrappers.lambdaQuery();
        queryWrapper.eq(OrderItem::getOrderId, orderId);
        List<OrderItem> orderItems = orderItemService.list(queryWrapper);
        for (OrderItem orderItem : orderItems) {
            Long goodsId = orderItem.getGoodsId();
            Integer goodsCount = orderItem.getGoodsCount();
            if (!goodsDao.addStock(goodsId, goodsCount)) {
                throw new BusinessException("秒殺商品貨品庫存增加失敗");
            }
        }

        // 5. 返還優惠券
        couponService.releaseCoupon(orderId);
        // 6. 所有更新操作完成後,提交事務
        platformTransactionManager.commit(transaction);
        log.info("---------------訂單orderId:{},未支付超時取消成功", orderId);
    } catch (Exception e) {
        log.info("---------------訂單orderId:{},未支付超時取消失敗", orderId, e);
        // 7. 發生異常,回滾事務
        platformTransactionManager.rollback(transaction);
    }
}

可以看到採用程式設計式事務後,我們將查詢邏輯排除在事務之外,這樣也就減小了事物影響範圍。

在極高效能優先的場景下,我們甚至可以考慮不使用事務,使用本地訊息表 + 訊息佇列來實現最終一致性就行 。

海量紀錄檔採集

公司線上有一個專案的使用者端,採用 tcp 協定與後端的一個紀錄檔採集服務建立連線,用來上報使用者端紀錄檔資料。

在業務高峰期下,會有同時成千上萬個使用者端建立連線,實時上報紀錄檔資料。

在上面的高峰期場景下,紀錄檔採集服務會有不小的壓力,如果程式程式碼邏輯處理稍有不當,就會造成服務卡頓、CPU 佔用過高、記憶體溢位等問題。

為了解決上面的大量連線實施上報資料的場景,紀錄檔採集服務決定使用 Netty 框架進行開發。

這裡直接給出紀錄檔採集程式使用 Netty 後的一些優化點,

採集紀錄檔非同步化

針對使用者端連線上報紀錄檔的採集流程非同步化處理有三個方案,給大家介紹一下,

  • 普通版:採用阻塞佇列 ArrayBlockingQueue 得生產者消費者模式,對上報的紀錄檔資料進行非同步批次處理,在此場景下,通過生產者將資料快取到記憶體佇列中,然後再消費者中批次獲取記憶體佇列的紀錄檔資料儲存入庫,好處是簡單易用,壞處是有記憶體溢位風險。
  • 進階版:採用 Disruptor 佇列,也是一個基於記憶體的高效能生產者消費者佇列,消費速度對比 ArrayBlockingQueue 有一個數量級以上得效能提升,附簡介說明:https://www.jianshu.com/p/bad7b4b44e48。
  • 終極版:也是公司紀錄檔採集程式最後採用的方案。採用 kfaka 訊息佇列中介軟體,先持久紀錄檔上報資料,然後慢慢消費。雖然引入第三方依賴會增加系統複雜度,但是 kfaka 在巨量資料場景表現實在是太優秀了,這一點也是值得。

採集紀錄檔壓縮

對上報後的紀錄檔如果要再傳送給其他服務,是需要進行壓縮後再處理,這一步是為了避免消耗過多網路頻寬。

在 Java 裡通常是指序列化方式,Jdk 自帶得序列化方式對比 Protobuf、fst、Hession 等在序列化速度和大小的表現上都沒有優勢,甚至可以用垃圾形容。

Java 常用的序列化框架有下面這些,

  • JDK 自帶的序列化:效能較差,佔用空間大,無法跨語言,好處是簡單易用,通用性強。
  • JSON:常用的 JSON 庫有 Jackson、Gson、Fastjson 等。效能較好,佔用空間少,跨語言支援廣泛,但是無法序列化複雜物件。
  • Protocol Buffers:由 Google 開源,基於 IDL 語言定義格式,編譯器生成物件存取程式碼。效能高效佔用空間小,但是需要提前定義 Schema。
  • Thrift:Facebook 開源,與 Protocol Buffers 類似。客製化生態不如 PB 完善,但是支援多語言互動。
  • Avro:Hadoop 生態圈序列化框架,支援資料隔離與進化,動態讀寫,效能可靠性好,佔用空間較小。但是使用複雜,通用性較差。
  • Hessian:一款開源的二進位制遠端通訊協定,使用簡單方法提供了RMI功能,主要用於物件導向的訊息通訊。支援跨平臺、多語言支援、使用簡單,缺點是傳遞複雜物件效能會下降,不適合安全性高的應用。

如果相容性要求不高可以選擇 JSON,如果要求效率以及傳輸資料量越小越好則 PB/Thrift/Avro/Hessian 更合適。

資料落庫選型

像紀錄檔這種巨量資料量落庫,都是新增且無修改得場景建議使用 Clickhouse 進行儲存,好處是相同資料量下對比 MySQL 佔用儲存更少,查詢速度更快,壞處就是並行查詢效能比較低,相比 MySQL 使用不算那麼成熟。

最後聊兩句

到這裡本文所介紹三個線上業務優化實戰就講完了,其實這種實戰案例還有很多,但是礙於篇幅本文就沒講那麼多拉,後續有機會也會繼續更新這類文章,希望大家能夠喜歡。

關注公眾號【waynblog】,每週分享技術乾貨、開源專案、實戰經驗、高效開發工具等,您的關注將是我的更新動力