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