記一次重構實戰的邏輯梳理記錄

最近聚餐，小七被公司公認代碼寫的很優雅的朱大神表揚了，說看了這麼多代碼，就隻有邀請短信那個功能的多線程用的好，這裡把重構這塊代碼的思路寫出來，畢竟思考一整天，程式設計半小時，重要的是思維。

業務需求

起飛前一定時間内，給滿足條件的旅客發送可升艙資訊。

邏輯整理

（1）查詢可升艙航班（集合）

（2）查詢每一個航班下可升艙旅客（集合）

（3）過濾旅客

（4）給滿足條件的旅客，發送邀請升艙的短信

改造前

1、未做幂等和加鎖，同一個接口，調多次，會造成資料積壓和資料錯誤。

2、判斷是否已經邀請，直接通過資料庫查詢，資料庫壓力過大。

3、發送短信需要旅客姓名，需要調用另一個接口擷取旅客中文姓名，且接口調用時間過長需要1s左右。

4、整個接口都是同步的，包括發送短信。

5、資料入庫時，是一條一條存儲的。

改造後

1、增加分布式鎖，防并發。

2、增加redis緩存。過濾資料，減少與資料庫的操作，且查詢時先通過緩存查找，提高系統吞吐量。

3、啟用多線程調用第三方接口，并組裝資料，提升效率。

4、使用mq解耦異步發送短信，因為發送結果不是重點，異步同步即可。

5、使用mysql批量插入，減少與資料庫的互動。

程式運作速度對比

改造前，一個航班，100名乘客，邀請時長5-10分鐘左右。

改造後，一個航班，100名乘客，初始化邀請需要2分鐘（第一次邀請），第二次邀請2-4秒左右。