本文是我從業(yè)多年開發(fā)生涯中針對線上業(yè)務(wù)的處理經(jīng)驗總結(jié)而來，這些業(yè)務(wù)或多或少相信大家都遇到過，因此在這里分享給大家，大家也可以看看是不是遇到過類似場景。本文大綱如下，

項目大綱

后臺上傳文件

線上后臺項目有一個消息推送的功能，運營新建一條通知消息時，需要一起上傳一列包含用戶 id 的文件，來給文件中包含的指定用戶推送系統(tǒng)消息。

如上功能描述看著很簡單，但是實際上處理上傳文件這一步是由講究的，假如說后臺上傳文件太大，導(dǎo)致內(nèi)存溢出，又或者讀取文件太慢等其實都是一些隱性的問題。

對于技術(shù)側(cè)想要做好這個功能，保證大用戶量（比如達到百萬級別）下，上傳文件、發(fā)送消息功能都正常，其實是需要仔細(xì)思考的，我這里給出我的優(yōu)化思路，

上傳文件類型選擇

通常情況下大部分用戶都會使用 Excel 文件作為后臺上傳文件類型，但是相比 Excel 文件，還有一種更加推薦的文件格式，那就是 CSV 文件。

CSV 是一種純文本格式，數(shù)據(jù)以文本形式存儲，每行數(shù)據(jù)以逗號分隔，沒有任何格式化。

因此 CSV 適用于簡單、易讀、導(dǎo)入和導(dǎo)出的場景，而且由于 CSV 文件只包含純文本，因此文件大小通常比 Excel 文件小得多。

但是 CSV 文件針對復(fù)雜電子表格操作的支持就沒 Excel 功能那么強大了，不過在這個只有一列的文件上傳業(yè)務(wù)里夠用了。

假如說上傳文件中包含 100 萬用戶 id，那么這里使用 CSV 文件上傳就有明顯優(yōu)勢，占用內(nèi)存更少，處理上傳文件也更快。

消息推送狀態(tài)保存

由于大批量數(shù)據(jù)插入是一個耗時操作（可能幾秒也可能幾分鐘），所以需要保存批量插入是否成功的狀態(tài)，在后臺中還需要顯現(xiàn)出這條消息推送狀態(tài)是成功還是失敗，方便運營人員回溯消息推送狀態(tài)。

批量寫入

針對這里上傳大文件時的批量寫入場景，這里提幾個點大家注意一下就行，

rewriteBatchedStatements=true

MySQL 的 JDBC 連接的 url 中要加 rewriteBatchedStatements 參數(shù)，并保證 5.1.13 以上版本的驅(qū)動，才能實現(xiàn)高性能的批量插入。

MySQL JDBC 驅(qū)動在默認(rèn)情況下會無視 executeBatch()語句，把我們期望批量執(zhí)行的一組 sql 語句拆散，一條一條地發(fā)給 MySQL 數(shù)據(jù)庫，批量插入實際上是單條插入，直接造成較低的性能。只有把 rewriteBatchedStatements 參數(shù)置為 true， 驅(qū)動才會幫你批量執(zhí)行 SQL。另外這個選項對 INSERT/UPDATE/DELETE 都有效。

是否啟用事物功能

批量寫入場景里要不要啟用事物，其實很多人都有自己的看法，這里我給出啟用于不啟用的利弊，

• 啟用事務(wù)：好處在于如批量插入過程中，異常情況可以保證原子性，但是性能比不開事務(wù)低，在特大數(shù)據(jù)量下會明顯低一個檔次
• 不啟用事務(wù)：好處就是寫入性能高，特大數(shù)據(jù)量寫入性能提升明顯，但是無法保證原子性

在本文提到的大文件上傳批量寫入的場景下，要是追求極致性能我推薦是不啟用事務(wù)的。

假如在批量寫入過程中發(fā)生網(wǎng)絡(luò)波動或者數(shù)據(jù)庫宕機，我們其實只需要重新新建一條通知消息，然后重新上傳包含用戶 id 的文件即可。

因為上一條通知消息因為批量插入步驟沒有全部完成，所以推送狀態(tài)是失敗。后續(xù)等開發(fā)人員處理一下臟數(shù)據(jù)即可。

大事務(wù)

@Transactional 是 Spring 框架提供得事務(wù)注解，相信這是許多人都知道的，但是在一些高性能場景下，是不建議使用的，推薦通過編程式事務(wù)來手動控制事務(wù)提交或者回滾，減少事務(wù)影響范圍，因而提升性能。

使用事務(wù)注解

如下是一段訂單超時未支付回滾業(yè)務(wù)數(shù)據(jù)得代碼，采用 @Transactional 事務(wù)注解

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

    // 2. 更新訂單為已取消狀態(tài)
    order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());
    orderService.updateById(order);
    ...
    // 3. 訂單商品數(shù)量增加
    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. 返還用戶優(yōu)惠券
    couponService.releaseCoupon(orderId);
    log.info("---------------訂單orderId:{}，未支付超時取消成功"， orderId);
}

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

1. 查詢訂單是否存在
2. 更新訂單為已取消狀態(tài)
3. 訂單商品數(shù)量增加
4. 返還用戶優(yōu)惠券

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

使用編程式事務(wù)

使用編程式事務(wù)對其優(yōu)化后，代碼如下，

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

public void doUnPaidTask(Long orderId) {
    // 啟用編程式事務(wù)
    // 1. 在開啟事務(wù)錢查詢訂單是否存在
    Order order = orderService.getById(orderId);
    ...
    // 2. 開啟事務(wù)
    TransactionStatus transaction = platformTransactionManager.getTransaction(transactionDefinition);
    try {
        // 3. 設(shè)置訂單為已取消狀態(tài)
        order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());
        orderService.updateById(order);
        ...
        // 4. 商品貨品數(shù)量增加
        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. 返還優(yōu)惠券
        couponService.releaseCoupon(orderId);
        // 6. 所有更新操作完成后，提交事務(wù)
        platformTransactionManager.commit(transaction);
        log.info("---------------訂單orderId:{}，未支付超時取消成功"， orderId);
    } catch (Exception e) {
        log.info("---------------訂單orderId:{}，未支付超時取消失敗"， orderId， e);
        // 7. 發(fā)生異常，回滾事務(wù)
        platformTransactionManager.rollback(transaction);
    }
}

可以看到采用編程式事務(wù)后，我們將查詢邏輯排除在事務(wù)之外，這樣也就減小了事物影響范圍。

在極高性能優(yōu)先的場景下，我們甚至可以考慮不使用事務(wù)，使用本地消息表 + 消息隊列來實現(xiàn)最終一致性就行 。

海量日志采集

公司線上有一個項目的客戶端，采用 tcp 協(xié)議與后端的一個日志采集服務(wù)建立連接，用來上報客戶端日志數(shù)據(jù)。

在業(yè)務(wù)高峰期下，會有同時成千上萬個客戶端建立連接，實時上報日志數(shù)據(jù)。

在上面的高峰期場景下，日志采集服務(wù)會有不小的壓力，如果程序代碼邏輯處理稍有不當(dāng)，就會造成服務(wù)卡頓、CPU 占用過高、內(nèi)存溢出等問題。

為了解決上面的大量連接實施上報數(shù)據(jù)的場景，日志采集服務(wù)決定使用 Netty 框架進行開發(fā)。

這里直接給出日志采集程序使用 Netty 后的一些優(yōu)化點，

采集日志異步化

針對客戶端連接上報日志的采集流程異步化處理有三個方案，給大家介紹一下，

• 普通版：采用阻塞隊列 ArrayBlockingQueue 得生產(chǎn)者消費者模式，對上報的日志數(shù)據(jù)進行異步批量處理，在此場景下，通過生產(chǎn)者將數(shù)據(jù)緩存到內(nèi)存隊列中，然后再消費者中批量獲取內(nèi)存隊列的日志數(shù)據(jù)保存入庫，好處是簡單易用，壞處是有內(nèi)存溢出風(fēng)險。
• 進階版：采用 Disruptor 隊列，也是一個基于內(nèi)存的高性能生產(chǎn)者消費者隊列，消費速度對比 ArrayBlockingQueue 有一個數(shù)量級以上得性能提升，附簡介說明：https://www.jianshu.com/p/bad7b4b44e48。
• 終極版：也是公司日志采集程序最后采用的方案。采用 kfaka 消息隊列中間件，先持久日志上報數(shù)據(jù)，然后慢慢消費。雖然引入第三方依賴會增加系統(tǒng)復(fù)雜度，但是 kfaka 在大數(shù)據(jù)場景表現(xiàn)實在是太優(yōu)秀了，這一點也是值得。

采集日志壓縮

對上報后的日志如果要再發(fā)送給其他服務(wù)，是需要進行壓縮后再處理，這一步是為了避免消耗過多網(wǎng)絡(luò)帶寬。

在 Java 里通常是指序列化方式，Jdk 自帶得序列化方式對比 Protobuf、fst、Hession 等在序列化速度和大小的表現(xiàn)上都沒有優(yōu)勢，甚至可以用垃圾形容。

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

• JDK 自帶的序列化：性能較差，占用空間大，無法跨語言，好處是簡單易用，通用性強。
• JSON：常用的 JSON 庫有 Jackson、Gson、Fastjson 等。性能較好，占用空間少，跨語言支持廣泛，但是無法序列化復(fù)雜對象。
• Protocol Buffers：由 Google 開源，基于 IDL 語言定義格式，編譯器生成對象訪問代碼。性能高效占用空間小，但是需要提前定義 Schema。
• Thrift：Facebook 開源，與 Protocol Buffers 類似。定制生態(tài)不如 PB 完善，但是支持多語言交互。
• Avro：Hadoop 生態(tài)圈序列化框架，支持?jǐn)?shù)據(jù)隔離與進化，動態(tài)讀寫，性能可靠性好，占用空間較小。但是使用復(fù)雜，通用性較差。
• Hessian：一款開源的二進制遠(yuǎn)程通訊協(xié)議，使用簡單方法提供了RMI功能，主要用于面向?qū)ο蟮南⑼ㄐ?。支持跨平臺、多語言支持、使用簡單，缺點是傳遞復(fù)雜對象性能會下降，不適合安全性高的應(yīng)用。

如果兼容性要求不高可以選擇 JSON，如果要求效率以及傳輸數(shù)據(jù)量越小越好則 PB/Thrift/Avro/Hessian 更合適。

數(shù)據(jù)落庫選型

像日志這種大數(shù)據(jù)量落庫，都是新增且無修改得場景建議使用 Clickhouse 進行存儲，好處是相同數(shù)據(jù)量下對比 MySQL 占用存儲更少，查詢速度更快，壞處就是并發(fā)查詢性能比較低，相比 MySQL 使用不算那么成熟。