你好，我是yes。

之前不是稍微吐槽了下一個項目的代碼嘛，有幾個同學（1V1問答的同學）就順著問了我幾個平日里一些編碼的問題。

不同人寫代碼其實分了好幾種情況：

• 有些人完全沒意識到問題，這個屬于個人知識瓶頸，需要多加學習。
• 有些人就隨意寫，趕時間，沒責任心，當下能跑就行，后面管它洪水滔天。
• 有些人就賊糾結，寫個小功能想七想八，腦子總往著億級流量上懟，可能項目黃了之前其實都只幾個人用。

這幾個情況我都經歷過，寫代碼雖被戲稱搬磚，但咱畢竟也是類似阿提斯特一樣的創作型工作，跟心情有一定的關系。

工期緊心情差，將就將就，閑得很心情好，我綴一口咖啡精雕細琢。

咳咳，扯遠了，回到今天的主題。其實平日里想要寫好代碼，沒那么難，這篇我就總結下需要注意的幾個要點，不是很全，但是都是比較常見的點。

批處理思想

遙想當年我還是實習生的時候，寫個代碼風風火火闖九州！就沒有我不敢莽的代碼。

一個 for 循環闖天下：

for (YesDTO dto : yesDTOList) {
     //do sh
     save(xx);//插入數據庫
}

dev 和 qa 庫里就幾條數據，跑的好好的，一上線幾千條數據，直接干蒙 mentor。

我當時都沒意識到問題所在，但從他的眼神中我看到了殺氣。

影響不大，這鍋還得他背，誰讓他不 check 我的代碼？

現在知道了，一條一條插入太慢了，涉及到網絡的開銷，數據的解析等等。

所以特別在 for 循環的時候要想到批處理思想

for (YesDTO dto : yesDTOList) {
     //do sh
     xxList.add(xx);//添加列表
}
//批量插入
saveBatch(xxList);

不僅僅是我提到的數據庫操作，還有 RPC、HTTP 調用也是一樣，需要提供批量處理的接口替換 for 循環的一次次調用。

批處理能顯著提高吞吐，如果你看過一些中間件的源碼或底層一些實現你肯定能 get 里面很多批處理的思想。

事務

本地操作，如果涉及多個表的修改，不要忘了上事務，不然一旦中間處理出了差錯，數據就不一致了，意味著需要補數據，而補數據是一件非常麻煩且敏感的事情。

如果本地操作，涉及多個表的修改，又涉及遠程調用（或HTTP調用），需要注意事務的范圍。

開始事務
修改A
RPC調用
修改B
結束事務

不推薦在事務中使用遠程調用（或HTTP調用）。

因為遠程調用（或HTTP調用）可能因為網絡等其他原因導致響應很慢，而如果你的事務包裹了這些調用，可能會因為處理慢而長時間持有數據庫連接，或阻塞后續其他請求修改對應的值，使得連接池的連接耗盡，然后就都堵著，就都掛了。

所以寫代碼的時候要想著上事務保證數據的一致性，又得想著事務內部的行為會不會阻塞連接的釋放導致后續雪崩問題。

還有要注意一點，有些同學在事務里面包了 RPC 調用（或HTTP）是想著如果 RPC 調用失敗本地事務就回滾，通過這樣的手段來保證一致性。

這種想法是錯的，因為調用可能是超時或其他網絡情況，這不能代表對方的業務執行失敗，所以如果對方執行成功，你還是回滾了本地事務，其實數據還是不一致的。

如果需要確保一致性，就只能上分布式事務，可以看下我這篇：??分布式事務匯總??

異步

異步化改造是提升服務性能的一個有力手段！

如果某個模塊流量高，異步能減輕壓力。

如果某個模塊處理流程復雜且緩慢，異步能避免同步調用超時。

在編碼中遇到以上這兩個問題，就可以考慮異步。（當然還有其他場景，但這兩個比較常見）

可以通過 MQ 或者線程池來實現異步。

在平日工作的場景中，我更多使用  MQ 來實現異步，因為線程池的任務畢竟是存儲在內存中的，它沒有自帶的持久化操作，而且任務隊列大小也有限，而 MQ 自帶持久化且能存儲的任務量更大。

你想，假設你線程池堆積了1千個任務，然后服務掛了，那不又得考慮補償的機制了？而 MQ 就沒有這個煩惱。

當然，一些定時批處理任務類的場景還是要利用線程池的，不過這種場景的數據源已經持久化在數據庫中了，不會丟失。

重試

就像我前面說的，RPC 調用或 HTTP 調用可能因為網絡問題沒拿到正確的響應，這時候你必須要有重試的操作。

比如有個業務是異步的，別人調了你之后，你慢慢處理，等你處理完了需要通知別人，這就涉及到回調。

而回調別人接口的時候，腦子里一點要想著會遇到網絡問題，比如超時等，你必需要設計一個重試機制來保證通知到對方。

這個重試機制最好是間隔延遲的，比如1s、5s、30s、1min 、5min這種間隔重試，也就是說需要給對方一點時間來恢復服務，避免對方服務出問題的前幾分鐘把重試都用了，導致后面需要人工介入補償。

還有需要限制重試次數，因為我們的資源也是有限的，不可能給它無限重試，當達到一定的失敗次數后進行記錄，后續人工介入處理。

冪等

提到重試，那肯定伴隨著冪等。

一切接口，如果可以，就按冪等實現，也是說一個接口同樣的入參，調用多次都跟調用一次產生的結果是一樣的。

因為現在基本上都是微服務，遠程調用非常頻繁，基本上 RPC 框架都會自帶重試機制，你的接口很有可能在你沒準備的情況下被被重復調用，所以冪等就很重要。

并且有時候需要補償等動作時，冪等的接口可以讓你補償更加方便且沒有后顧之憂。

緩存

緩存是提高服務性能的一個重要手段之一。

很多大流量高并發服務基本上業務層的數據源都來自于緩存，對于一些精細化拆分的業務組來說，可能幾年都沒寫過 SQL。

我相信市面上公司基本都會接入  Redis（或類似組件），咱也不是說啥都要上緩存，只是說編碼時候考慮下這塊是否需要利用緩存來減少服務的壓力，比如一些頻繁調用且基本上不會更改的固定配置等等。

而緩存不僅僅是分布式緩存，還有本地緩存，也要善于利用本地緩存來實現優化。

總結

我稍微總結下以上內容：

1. 編碼時要有批處理思維，避免 for 循環單條保存數據和遠程調用（效率極低）。
2. 注意事務的范圍，避免事務中進行遠程調用或分布式鎖競爭等可能長時間造成數據庫連接不釋放的場景，也就是說不要無腦用 @Transactional 包裹整個方法；
3. 異步改造提高性能，但是要注意異步后如何保證異步的邏輯一定會被執行，且異步邏輯出錯如何補償等問題；
4. 網絡是不穩定的未知的，重試機制必不可少，要注意重試間隔，給對端多點時間恢復，減少需要人工介入的場景；
5. 盡可能按冪等實現方法，防止被重復調用導致數據錯亂；
6. 緩存，緩存大法YYDS，但是要注意失效時間以及大 key 問題。

雖說咱是打工人，不是給人賣命，但是一些基本職業素養還是要有的，我們還是需要有責任地管一管，避免后面的“洪水滔天”。

好了，今天就暫時分享這么多，后期我看著再整理一下實現的細節點。