你好，我是yes。

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

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

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

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

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

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

批處理思想

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

一個 for 循環(huán)闖天下：

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

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

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

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

現(xiàn)在知道了，一條一條插入太慢了，涉及到網(wǎng)絡的開銷，數(shù)據(jù)的解析等等。

所以特別在 for 循環(huán)的時候要想到批處理思想

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

不僅僅是我提到的數(shù)據(jù)庫操作，還有 RPC、HTTP 調(diào)用也是一樣，需要提供批量處理的接口替換 for 循環(huán)的一次次調(diào)用。

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

事務

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

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

開始事務
修改A
RPC調(diào)用
修改B
結束事務

不推薦在事務中使用遠程調(diào)用（或HTTP調(diào)用）。

因為遠程調(diào)用（或HTTP調(diào)用）可能因為網(wǎng)絡等其他原因?qū)е马憫苈绻愕氖聞瞻诉@些調(diào)用，可能會因為處理慢而長時間持有數(shù)據(jù)庫連接，或阻塞后續(xù)其他請求修改對應的值，使得連接池的連接耗盡，然后就都堵著，就都掛了。

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

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

這種想法是錯的，因為調(diào)用可能是超時或其他網(wǎng)絡情況，這不能代表對方的業(yè)務執(zhí)行失敗，所以如果對方執(zhí)行成功，你還是回滾了本地事務，其實數(shù)據(jù)還是不一致的。

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

異步

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

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

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

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

可以通過 MQ 或者線程池來實現(xiàn)異步。

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

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

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

重試

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

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

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

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

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

冪等

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

一切接口，如果可以，就按冪等實現(xiàn)，也是說一個接口同樣的入?yún)?，調(diào)用多次都跟調(diào)用一次產(chǎn)生的結果是一樣的。

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

并且有時候需要補償?shù)葎幼鲿r，冪等的接口可以讓你補償更加方便且沒有后顧之憂。

緩存

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

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

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

而緩存不僅僅是分布式緩存，還有本地緩存，也要善于利用本地緩存來實現(xiàn)優(yōu)化。

總結

我稍微總結下以上內(nèi)容：

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

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

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