建站
咨詢
售后
建站咨詢
新聞中心
你好，我是yes。
創(chuàng)新互聯(lián)建站憑借專業(yè)的設(shè)計團隊扎實的技術(shù)支持、優(yōu)質(zhì)高效的服務(wù)意識和豐厚的資源優(yōu)勢，提供專業(yè)的網(wǎng)站策劃、成都網(wǎng)站制作、做網(wǎng)站、網(wǎng)站優(yōu)化、軟件開發(fā)、網(wǎng)站改版等服務(wù)，在成都十多年的網(wǎng)站建設(shè)設(shè)計經(jīng)驗，為成都上千中小型企業(yè)策劃設(shè)計了網(wǎng)站。
之前不是稍微吐槽了下一個項目的代碼嘛，有幾個同學(xué)（1V1問答的同學(xué)）就順著問了我?guī)讉€平日里一些編碼的問題。
不同人寫代碼其實分了好幾種情況：
- 有些人完全沒意識到問題，這個屬于個人知識瓶頸，需要多加學(xué)習(xí)。
- 有些人就隨意寫，趕時間，沒責(zé)任心，當下能跑就行，后面管它洪水滔天。
- 有些人就賊糾結(jié)，寫個小功能想七想八，腦子總往著億級流量上懟，可能項目黃了之前其實都只幾個人用。
這幾個情況我都經(jīng)歷過，寫代碼雖被戲稱搬磚，但咱畢竟也是類似阿提斯特一樣的創(chuàng)作型工作，跟心情有一定的關(guān)系。
工期緊心情差，將就將就，閑得很心情好，我綴一口咖啡精雕細琢。
咳咳，扯遠了，回到今天的主題。其實平日里想要寫好代碼，沒那么難，這篇我就總結(jié)下需要注意的幾個要點，不是很全，但是都是比較常見的點。
批處理思想
遙想當年我還是實習(xí)生的時候，寫個代碼風(fēng)風(fē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)絡(luò)的開銷，數(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 里面很多批處理的思想。
事務(wù)
本地操作，如果涉及多個表的修改，不要忘了上事務(wù)，不然一旦中間處理出了差錯，數(shù)據(jù)就不一致了，意味著需要補數(shù)據(jù)，而補數(shù)據(jù)是一件非常麻煩且敏感的事情。
如果本地操作，涉及多個表的修改，又涉及遠程調(diào)用（或HTTP調(diào)用），需要注意事務(wù)的范圍。
開始事務(wù)
修改A
RPC調(diào)用
修改B
結(jié)束事務(wù)
不推薦在事務(wù)中使用遠程調(diào)用（或HTTP調(diào)用）。
因為遠程調(diào)用（或HTTP調(diào)用）可能因為網(wǎng)絡(luò)等其他原因?qū)е马憫?yīng)很慢，而如果你的事務(wù)包裹了這些調(diào)用，可能會因為處理慢而長時間持有數(shù)據(jù)庫連接，或阻塞后續(xù)其他請求修改對應(yīng)的值，使得連接池的連接耗盡，然后就都堵著，就都掛了。
所以寫代碼的時候要想著上事務(wù)保證數(shù)據(jù)的一致性，又得想著事務(wù)內(nèi)部的行為會不會阻塞連接的釋放導(dǎo)致后續(xù)雪崩問題。
還有要注意一點，有些同學(xué)在事務(wù)里面包了 RPC 調(diào)用（或HTTP）是想著如果 RPC 調(diào)用失敗本地事務(wù)就回滾，通過這樣的手段來保證一致性。
這種想法是錯的，因為調(diào)用可能是超時或其他網(wǎng)絡(luò)情況，這不能代表對方的業(yè)務(wù)執(zhí)行失敗，所以如果對方執(zhí)行成功，你還是回滾了本地事務(wù)，其實數(shù)據(jù)還是不一致的。
如果需要確保一致性，就只能上分布式事務(wù)，可以看下我這篇：??分布式事務(wù)匯總??
異步
異步化改造是提升服務(wù)性能的一個有力手段！
如果某個模塊流量高，異步能減輕壓力。
如果某個模塊處理流程復(fù)雜且緩慢，異步能避免同步調(diào)用超時。
在編碼中遇到以上這兩個問題，就可以考慮異步。（當然還有其他場景，但這兩個比較常見）
可以通過 MQ 或者線程池來實現(xiàn)異步。
在平日工作的場景中，我更多使用 MQ 來實現(xiàn)異步，因為線程池的任務(wù)畢竟是存儲在內(nèi)存中的，它沒有自帶的持久化操作，而且任務(wù)隊列大小也有限，而 MQ 自帶持久化且能存儲的任務(wù)量更大。
你想，假設(shè)你線程池堆積了1千個任務(wù)，然后服務(wù)掛了，那不又得考慮補償?shù)臋C制了？而 MQ 就沒有這個煩惱。
當然，一些定時批處理任務(wù)類的場景還是要利用線程池的，不過這種場景的數(shù)據(jù)源已經(jīng)持久化在數(shù)據(jù)庫中了，不會丟失。
重試
就像我前面說的，RPC 調(diào)用或 HTTP 調(diào)用可能因為網(wǎng)絡(luò)問題沒拿到正確的響應(yīng)，這時候你必須要有重試的操作。
比如有個業(yè)務(wù)是異步的，別人調(diào)了你之后，你慢慢處理，等你處理完了需要通知別人，這就涉及到回調(diào)。
而回調(diào)別人接口的時候，腦子里一點要想著會遇到網(wǎng)絡(luò)問題，比如超時等，你必需要設(shè)計一個重試機制來保證通知到對方。
這個重試機制最好是間隔延遲的，比如1s、5s、30s、1min 、5min這種間隔重試，也就是說需要給對方一點時間來恢復(fù)服務(wù)，避免對方服務(wù)出問題的前幾分鐘把重試都用了，導(dǎo)致后面需要人工介入補償。
還有需要限制重試次數(shù)，因為我們的資源也是有限的，不可能給它無限重試，當達到一定的失敗次數(shù)后進行記錄，后續(xù)人工介入處理。
冪等
提到重試，那肯定伴隨著冪等。
一切接口，如果可以，就按冪等實現(xiàn)，也是說一個接口同樣的入?yún)ⅲ{(diào)用多次都跟調(diào)用一次產(chǎn)生的結(jié)果是一樣的。
因為現(xiàn)在基本上都是微服務(wù)，遠程調(diào)用非常頻繁，基本上 RPC 框架都會自帶重試機制，你的接口很有可能在你沒準備的情況下被被重復(fù)調(diào)用，所以冪等就很重要。
并且有時候需要補償?shù)葎幼鲿r，冪等的接口可以讓你補償更加方便且沒有后顧之憂。
緩存
緩存是提高服務(wù)性能的一個重要手段之一。
很多大流量高并發(fā)服務(wù)基本上業(yè)務(wù)層的數(shù)據(jù)源都來自于緩存，對于一些精細化拆分的業(yè)務(wù)組來說，可能幾年都沒寫過 SQL。
我相信市面上公司基本都會接入 Redis（或類似組件），咱也不是說啥都要上緩存，只是說編碼時候考慮下這塊是否需要利用緩存來減少服務(wù)的壓力，比如一些頻繁調(diào)用且基本上不會更改的固定配置等等。
而緩存不僅僅是分布式緩存，還有本地緩存，也要善于利用本地緩存來實現(xiàn)優(yōu)化。
總結(jié)
我稍微總結(jié)下以上內(nèi)容：
- 編碼時要有批處理思維，避免 for 循環(huán)單條保存數(shù)據(jù)和遠程調(diào)用（效率極低）。
- 注意事務(wù)的范圍，避免事務(wù)中進行遠程調(diào)用或分布式鎖競爭等可能長時間造成數(shù)據(jù)庫連接不釋放的場景，也就是說不要無腦用 @Transactional 包裹整個方法；
- 異步改造提高性能，但是要注意異步后如何保證異步的邏輯一定會被執(zhí)行，且異步邏輯出錯如何補償?shù)葐栴}；
- 網(wǎng)絡(luò)是不穩(wěn)定的未知的，重試機制必不可少，要注意重試間隔，給對端多點時間恢復(fù)，減少需要人工介入的場景；
- 盡可能按冪等實現(xiàn)方法，防止被重復(fù)調(diào)用導(dǎo)致數(shù)據(jù)錯亂；
- 緩存，緩存大法YYDS，但是要注意失效時間以及大 key 問題。
雖說咱是打工人，不是給人賣命，但是一些基本職業(yè)素養(yǎng)還是要有的，我們還是需要有責(zé)任地管一管，避免后面的“洪水滔天”。
好了，今天就暫時分享這么多，后期我看著再整理一下實現(xiàn)的細節(jié)點。
文章標題：聊聊寫代碼與洪水滔天
鏈接地址：http://www.dlmjj.cn/article/cogcisi.html
