線上優(yōu)化之案例實(shí)戰(zhàn)，你學(xué)會(huì)了嗎？
本文是我從業(yè)多年開(kāi)發(fā)生涯中針對(duì)線上業(yè)務(wù)的處理經(jīng)驗(yàn)總結(jié)而來(lái)，這些業(yè)務(wù)或多或少相信大家都遇到過(guò)，因此把優(yōu)化經(jīng)驗(yàn)分享給大家，大家也可以看看是不是遇到過(guò)類(lèi)似場(chǎng)景。
本文大綱如下，
圖片
后臺(tái)上傳文件
線上后臺(tái)項(xiàng)目有一個(gè)消息推送的功能，運(yùn)營(yíng)新建一條通知消息時(shí)，需要一起上傳一列包含用戶(hù) id 的文件，來(lái)給文件中包含的指定用戶(hù)推送系統(tǒng)消息。
如上功能描述看著很簡(jiǎn)單，但是實(shí)際上處理上傳文件這一步是由講究的，假如說(shuō)后臺(tái)上傳文件太大，導(dǎo)致內(nèi)存溢出，又或者讀取文件太慢等其實(shí)都是一些隱性的問(wèn)題。
對(duì)于技術(shù)側(cè)想要做好這個(gè)功能，保證大用戶(hù)量（比如達(dá)到百萬(wàn)級(jí)別）下，上傳文件、發(fā)送消息功能都正常，其實(shí)是需要仔細(xì)思考的，我這里給出我的優(yōu)化思路。
上傳文件類(lèi)型選擇
通常情況下大部分用戶(hù)都會(huì)使用 Excel 文件作為后臺(tái)上傳文件類(lèi)型，但是相比 Excel 文件，還有一種更加推薦的文件格式，那就是 CSV 文件。
CSV 是一種純文本格式，數(shù)據(jù)以文本形式存儲(chǔ)，每行數(shù)據(jù)以逗號(hào)分隔，沒(méi)有任何格式化。
因此 CSV 適用于簡(jiǎn)單、易讀、導(dǎo)入和導(dǎo)出的場(chǎng)景，而且由于 CSV 文件只包含純文本，因此文件大小通常比 Excel 文件小得多。
但是 CSV 文件針對(duì)復(fù)雜電子表格操作的支持就沒(méi) Excel 功能那么強(qiáng)大了，不過(guò)在這個(gè)只有一列的文件上傳業(yè)務(wù)里夠用了。
假如說(shuō)上傳文件中包含 100 萬(wàn)用戶(hù) id，那么這里使用 CSV 文件上傳就有明顯優(yōu)勢(shì)，占用內(nèi)存更少，處理上傳文件也更快。
消息推送狀態(tài)保存
由于大批量數(shù)據(jù)插入是一個(gè)耗時(shí)操作（可能幾秒也可能幾分鐘），所以需要保存批量插入是否成功的狀態(tài)，在后臺(tái)中還需要顯現(xiàn)出這條消息推送狀態(tài)是成功還是失敗，方便運(yùn)營(yíng)人員回溯消息推送狀態(tài)。
批量寫(xiě)入
針對(duì)這里上傳大文件時(shí)的批量寫(xiě)入場(chǎng)景，這里提幾個(gè)點(diǎn)大家注意一下就行，
rewriteBatchedStatements=true
MySQL 的 JDBC 連接的 url 中要加 rewriteBatchedStatements 參數(shù)，并保證 5.1.13 以上版本的驅(qū)動(dòng)，才能實(shí)現(xiàn)高性能的批量插入。
MySQL JDBC 驅(qū)動(dòng)在默認(rèn)情況下會(huì)無(wú)視 executeBatch()語(yǔ)句，把我們期望批量執(zhí)行的一組 sql 語(yǔ)句拆散，一條一條地發(fā)給 MySQL 數(shù)據(jù)庫(kù)，批量插入實(shí)際上是單條插入，直接造成較低的性能。只有把 rewriteBatchedStatements 參數(shù)置為 true， 驅(qū)動(dòng)才會(huì)幫你批量執(zhí)行 SQL。另外這個(gè)選項(xiàng)對(duì) INSERT/UPDATE/DELETE 都有效。
是否啟用事物功能
批量寫(xiě)入場(chǎng)景里要不要啟用事物，其實(shí)很多人都有自己的看法，這里我給出啟用于不啟用的利弊，
- 啟用事務(wù)：好處在于如批量插入過(guò)程中，異常情況可以保證原子性，但是性能比不開(kāi)事務(wù)低，在特大數(shù)據(jù)量下會(huì)明顯低一個(gè)檔次
- 不啟用事務(wù)：好處就是寫(xiě)入性能高，特大數(shù)據(jù)量寫(xiě)入性能提升明顯，但是無(wú)法保證原子性
在本文提到的大文件上傳批量寫(xiě)入的場(chǎng)景下，要是追求極致性能我推薦是不啟用事務(wù)的。
假如在批量寫(xiě)入過(guò)程中發(fā)生網(wǎng)絡(luò)波動(dòng)或者數(shù)據(jù)庫(kù)宕機(jī)，我們其實(shí)只需要重新新建一條通知消息，然后重新上傳包含用戶(hù) id 的文件即可。
因?yàn)樯弦粭l通知消息因?yàn)榕坎迦氩襟E沒(méi)有全部完成，所以推送狀態(tài)是失敗。后續(xù)等開(kāi)發(fā)人員處理一下臟數(shù)據(jù)即可。
大事務(wù)
@Transactional 是 Spring 框架提供得事務(wù)注解，相信這是許多人都知道的，但是在一些高性能場(chǎng)景下，是不建議使用的，推薦通過(guò)編程式事務(wù)來(lái)手動(dòng)控制事務(wù)提交或者回滾，減少事務(wù)影響范圍，因而提升性能。
使用事務(wù)注解
如下是一段訂單超時(shí)未支付回滾業(yè)務(wù)數(shù)據(jù)得代碼，采用 @Transactional 事務(wù)注解
@Transactional(rollbackFor = Exception.class)
public void doUnPaidTask(Long orderId) {
// 1. 查詢(xún)訂單是否存在
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("秒殺商品貨品庫(kù)存增加失敗");
}
}
// 4. 返還用戶(hù)優(yōu)惠券
couponService.releaseCoupon(orderId);
log.info("---------------訂單orderId:{}，未支付超時(shí)取消成功"， orderId);
}可以看到上面訂單回滾的代碼邏輯有四個(gè)步驟，如下，
- 查詢(xún)訂單是否存在
- 更新訂單為已取消狀態(tài)
- 訂單商品數(shù)量增加
- 返還用戶(hù)優(yōu)惠券
這里面有個(gè)問(wèn)題，訂單回滾方法里面其實(shí)只有 2、3、4 步驟是需要在一個(gè)事物里執(zhí)行的，第 1 步其實(shí)可以放在事物外面來(lái)執(zhí)行，以此縮小事物范圍。
使用編程式事務(wù)
使用編程式事務(wù)對(duì)其優(yōu)化后，代碼如下，
@Resource
private PlatformTransactionManager platformTransactionManager;
@Resource
private TransactionDefinition transactionDefinition;
public void doUnPaidTask(Long orderId) {
// 啟用編程式事務(wù)
// 1. 在開(kāi)啟事務(wù)錢(qián)查詢(xún)訂單是否存在
Order order = orderService.getById(orderId);
...
// 2. 開(kāi)啟事務(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("秒殺商品貨品庫(kù)存增加失敗");
}
}
// 5. 返還優(yōu)惠券
couponService.releaseCoupon(orderId);
// 6. 所有更新操作完成后，提交事務(wù)
platformTransactionManager.commit(transaction);
log.info("---------------訂單orderId:{}，未支付超時(shí)取消成功"， orderId);
} catch (Exception e) {
log.info("---------------訂單orderId:{}，未支付超時(shí)取消失敗"， orderId， e);
// 7. 發(fā)生異常，回滾事務(wù)
platformTransactionManager.rollback(transaction);
}
}可以看到采用編程式事務(wù)后，我們將查詢(xún)邏輯排除在事務(wù)之外，這樣也就減小了事物影響范圍。
在極高性能優(yōu)先的場(chǎng)景下，我們甚至可以考慮不使用事務(wù)，使用本地消息表 + 消息隊(duì)列來(lái)實(shí)現(xiàn)最終一致性就行 。
海量日志采集
公司線上有一個(gè)項(xiàng)目的客戶(hù)端，采用 tcp 協(xié)議與后端的一個(gè)日志采集服務(wù)建立連接，用來(lái)上報(bào)客戶(hù)端日志數(shù)據(jù)。
在業(yè)務(wù)高峰期下，會(huì)有同時(shí)成千上萬(wàn)個(gè)客戶(hù)端建立連接，實(shí)時(shí)上報(bào)日志數(shù)據(jù)。
在上面的高峰期場(chǎng)景下，日志采集服務(wù)會(huì)有不小的壓力，如果程序代碼邏輯處理稍有不當(dāng)，就會(huì)造成服務(wù)卡頓、CPU 占用過(guò)高、內(nèi)存溢出等問(wèn)題。
為了解決上面的大量連接實(shí)施上報(bào)數(shù)據(jù)的場(chǎng)景，日志采集服務(wù)決定使用 Netty 框架進(jìn)行開(kāi)發(fā)。
這里直接給出日志采集程序使用 Netty 后的一些優(yōu)化點(diǎn)，
采集日志異步化
針對(duì)客戶(hù)端連接上報(bào)日志的采集流程異步化處理有三個(gè)方案，給大家介紹一下，
- 普通版：采用阻塞隊(duì)列 ArrayBlockingQueue 得生產(chǎn)者消費(fèi)者模式，對(duì)上報(bào)的日志數(shù)據(jù)進(jìn)行異步批量處理，在此場(chǎng)景下，通過(guò)生產(chǎn)者將數(shù)據(jù)緩存到內(nèi)存隊(duì)列中，然后再消費(fèi)者中批量獲取內(nèi)存隊(duì)列的日志數(shù)據(jù)保存入庫(kù)，好處是簡(jiǎn)單易用，壞處是有內(nèi)存溢出風(fēng)險(xiǎn)。
- 進(jìn)階版：采用 Disruptor 隊(duì)列，也是一個(gè)基于內(nèi)存的高性能生產(chǎn)者消費(fèi)者隊(duì)列，消費(fèi)速度對(duì)比 ArrayBlockingQueue 有一個(gè)數(shù)量級(jí)以上得性能提升，附簡(jiǎn)介說(shuō)明：https://www.jianshu.com/p/bad7b4b44e48。
- 終極版：也是公司日志采集程序最后采用的方案。采用 kfaka 消息隊(duì)列中間件，先持久日志上報(bào)數(shù)據(jù)，然后慢慢消費(fèi)。雖然引入第三方依賴(lài)會(huì)增加系統(tǒng)復(fù)雜度，但是 kfaka 在大數(shù)據(jù)場(chǎng)景表現(xiàn)實(shí)在是太優(yōu)秀了，這一點(diǎn)也是值得。
采集日志壓縮
對(duì)上報(bào)后的日志如果要再發(fā)送給其他服務(wù)，是需要進(jìn)行壓縮后再處理，這一步是為了避免消耗過(guò)多網(wǎng)絡(luò)帶寬。
在 Java 里通常是指序列化方式，Jdk 自帶得序列化方式對(duì)比 Protobuf、fst、Hession 等在序列化速度和大小的表現(xiàn)上都沒(méi)有優(yōu)勢(shì)，甚至可以用垃圾形容。
Java 常用的序列化框架有下面這些，
- JDK 自帶的序列化：性能較差，占用空間大，無(wú)法跨語(yǔ)言，好處是簡(jiǎn)單易用，通用性強(qiáng)。
- JSON：常用的 JSON 庫(kù)有 Jackson、Gson、Fastjson 等。性能較好，占用空間少，跨語(yǔ)言支持廣泛，但是無(wú)法序列化復(fù)雜對(duì)象。
- Protocol Buffers：由 Google 開(kāi)源，基于 IDL 語(yǔ)言定義格式，編譯器生成對(duì)象訪問(wèn)代碼。性能高效占用空間小，但是需要提前定義 Schema。
- Thrift：Facebook 開(kāi)源，與 Protocol Buffers 類(lèi)似。定制生態(tài)不如 PB 完善，但是支持多語(yǔ)言交互。
- Avro：Hadoop 生態(tài)圈序列化框架，支持?jǐn)?shù)據(jù)隔離與進(jìn)化，動(dòng)態(tài)讀寫(xiě)，性能可靠性好，占用空間較小。但是使用復(fù)雜，通用性較差。
- Hessian：一款開(kāi)源的二進(jìn)制遠(yuǎn)程通訊協(xié)議，使用簡(jiǎn)單方法提供了RMI功能，主要用于面向?qū)ο蟮南⑼ㄐ拧ＶС挚缙脚_(tái)、多語(yǔ)言支持、使用簡(jiǎn)單，缺點(diǎn)是傳遞復(fù)雜對(duì)象性能會(huì)下降，不適合安全性高的應(yīng)用。
如果兼容性要求不高可以選擇 JSON，如果要求效率以及傳輸數(shù)據(jù)量越小越好則 PB/Thrift/Avro/Hessian 更合適。
數(shù)據(jù)落庫(kù)選型
像日志這種大數(shù)據(jù)量落庫(kù)，都是新增且無(wú)修改得場(chǎng)景建議使用 Clickhouse 進(jìn)行存儲(chǔ)，好處是相同數(shù)據(jù)量下對(duì)比 MySQL 占用存儲(chǔ)更少，查詢(xún)速度更快，壞處就是并發(fā)查詢(xún)性能比較低，相比 MySQL 使用不算那么成熟。
最后聊兩句
到這里本文所介紹三個(gè)線上業(yè)務(wù)優(yōu)化實(shí)戰(zhàn)就講完了，其實(shí)這種實(shí)戰(zhàn)案例還有很多，但是礙于篇幅本文就沒(méi)講那么多拉，后續(xù)有機(jī)會(huì)也會(huì)繼續(xù)更新這類(lèi)文章，希望大家能夠喜歡。
