今年是第三個618昔驱，進(jìn)公司也25個月了。前兩年的618基本上是平穩(wěn)度過洛史，沒什么波瀾惯殊。但是今年的618有些不尋常，業(yè)務(wù)范圍有了些調(diào)整也殖。一個是原先的店鋪業(yè)務(wù)被交接出去土思，另一個是接手了領(lǐng)券中心業(yè)務(wù)。
對于店鋪業(yè)務(wù)忆嗜，由接手的BJ團(tuán)隊(duì)負(fù)責(zé)618的準(zhǔn)備工作己儒。
對于領(lǐng)券中心業(yè)務(wù)，由原先的團(tuán)隊(duì)負(fù)責(zé)捆毫，我們這邊做了618前的一個需求闪湾，新增了幾個接口，這幾個接口需要我們這邊自己壓測绩卤，并負(fù)責(zé)接口的所有問題途样。
所以江醇，看上去這次618壓力應(yīng)該不大，但是問題卻出了不少何暇。很不幸陶夜，其中有兩個是我埋坑。一個是店鋪裆站，一個是領(lǐng)券中心条辟。

1、店鋪
在2018年1月宏胯，開發(fā)上線了店鋪的拼購商品打標(biāo)功能捂贿。也就是給店鋪中的拼購商品打上拼購的標(biāo)，讓用戶一眼能看出是拼購商品胳嘲，促成用戶下單。很簡單的功能扣草，也很順利的上線了了牛。但是到了6月8號（618活動已經(jīng)開始），產(chǎn)品經(jīng)理突然說有些店鋪的拼購商品沒有打標(biāo)辰妙。
～～晴天霹靂～～
撥上VPN鹰祸，仔細(xì)查看日志。發(fā)現(xiàn)拼購信息在緩存中設(shè)置的有效時間不對密浑，導(dǎo)致了拼購活動還沒結(jié)束蛙婴，緩存中的拼購信息也就沒有了。店鋪中的拼購商品沒有打標(biāo)尔破。

【直接原因分析】
緩存中沒有拼購信息 >> 拼購信息的緩存時間小于活動時間 >> 拼購信息的緩存時間計算錯誤街图。

緩存時間的計算方法如下：
拿到拼購活動的結(jié)束時間（結(jié)束時間實(shí)際就是Long型，單位是秒）懒构。在Java中餐济，這個時間是一個long值。為了計算距離現(xiàn)在的失效時間胆剧，只需要拿活動失效時間乘以1000絮姆，再減去現(xiàn)在的時間long值即可。此時得到的有效時間是毫秒級別的秩霍，再除以1000即得到實(shí)際的秒數(shù)篙悯。這個時間就是這個拼購信息的過期時間了。

計算思路很簡單铃绒，問題出在了最后一步鸽照。在拿到緩存有效時間（毫秒級）后，直接使用了Long.intVal()匿垄，此時是強(qiáng)制轉(zhuǎn)換移宅，把long型的64位值归粉，截取了低位的32位。這種轉(zhuǎn)換是很危險的漏峰。如果long型的值超過了Integer.Max的值糠悼，強(qiáng)制轉(zhuǎn)換后，可能是負(fù)數(shù)浅乔，也可能是正數(shù)倔喂。對于負(fù)數(shù)，寫緩存的時候靖苇，代碼會認(rèn)為沒有設(shè)置緩存有效時間席噩，這個還好，不會對業(yè)務(wù)有影響贤壁。但是對于轉(zhuǎn)換成正數(shù)的悼枢，實(shí)際產(chǎn)生的效果是緩存時間變小了（比如，本來10年的有效期脾拆，由于存在強(qiáng)制的截斷馒索，現(xiàn)在變成了24天以內(nèi)的有效期）。

【解決問題】
1）優(yōu)先解決線上問題名船。使用預(yù)發(fā)布環(huán)境把線上錯誤的緩存時間給刷回來绰上。也就是批量查詢數(shù)據(jù)庫，從數(shù)據(jù)庫中獲取正確的結(jié)束時間渠驼，重新刷新緩存蜈块。
說干就干，寫了代碼立刻上預(yù)發(fā)布迷扇，并開始了刷新任務(wù)百揭。跑了一夜，發(fā)現(xiàn)還沒結(jié)束谋梭，查看線上原來沒有拼購的幾個店鋪信峻，恢復(fù)了拼購打標(biāo)，更加證實(shí)了是這個原因瓮床。只是盹舞，無法確認(rèn)所有的店鋪都好了。為了不影響線上白天的業(yè)務(wù)隘庄，停止了任務(wù)踢步。
為什么這么慢，慢在了哪里成了問題丑掺。查詢了數(shù)據(jù)庫获印，發(fā)現(xiàn)有2000w+條記錄。數(shù)據(jù)量大是刷新慢的一部分原因街州。
只有一臺預(yù)發(fā)布容器也是一部分原因兼丰。
同時查看代碼玻孟，發(fā)現(xiàn)之前遍歷數(shù)據(jù)庫的方法有些問題。使用的是設(shè)置limit的方式去做鳍征，這么做降低了查詢的效率黍翎。而且是越往后，查詢效率越低艳丛，因?yàn)樵酵蟛樵兿坏В琹imit查詢需要查詢的內(nèi)容在不斷增加，查詢效率急劇下降氮双，從一開始的10ms碰酝，變成了后開的數(shù)秒。這是整個刷新任務(wù)慢的主要原因戴差。
更換了刷新思路送爸，改用有索引的id來查詢。首先查出max(id)暖释，然后分出5個區(qū)間來碱璃，讓5臺機(jī)器分擔(dān)著去刷。這么一來饭入，不到30分鐘，2000w+的數(shù)據(jù)刷新就完畢了肛真⌒扯火是滅了，得治里了蚓让。

2）代碼修復(fù)
long到int的轉(zhuǎn)換乾忱，做了判斷。對于超過Integer.Max的long值历极，直接使用Integer.Max（實(shí)際的拼購時間不可能超過10年）窄瘟，小于等于的long值直接轉(zhuǎn)換成int（截斷也是安全的）。

至此趟卸，問題算是全部解決蹄葱。后續(xù)跟蹤日志，也沒有發(fā)現(xiàn)有問題锄列。線上也沒有再爆有問題的拼購打標(biāo)图云。小小的數(shù)值轉(zhuǎn)換，埋下了禍根邻邮。
萬幸的是竣况，這個問題是產(chǎn)品經(jīng)理發(fā)現(xiàn)的，而不是業(yè)務(wù)方投訴筒严，未造成大的影響丹泉。另外情萤，只是打標(biāo)有問題，點(diǎn)擊商品后摹恨，商詳中顯示的還是拼購商品筋岛，可能有些人還不知道店鋪商品列表中應(yīng)該需要打標(biāo)。所以沒有被發(fā)現(xiàn)和投訴吧睬塌。
本bug的影響范圍也有限泉蝌，因?yàn)樵谄促彆r間超過24天的拼購信息中，有一部分設(shè)置成了永久緩存（強(qiáng)制轉(zhuǎn)換成負(fù)數(shù)的情況）揩晴；剩余的設(shè)置成了短于結(jié)束時間的過期時間勋陪，而且只有等到時間過期后才會發(fā)現(xiàn)有問題的拼購打標(biāo)。

【根本原因分析】
1硫兰、代碼開發(fā)不夠嚴(yán)謹(jǐn)诅愚。當(dāng)時沒有想到會有這么長時間的拼購時間，沒有跟產(chǎn)品確認(rèn)實(shí)際的時間需求劫映，考慮不足违孝。雖然寫代碼的時候隱約感覺到了問題，但是沒有仔細(xì)地?fù)Q算緩存時間是否夠用泳赋，想當(dāng)然的覺得1個月肯定沒啥問題雌桑。
2、代碼Review不足祖今，只有在合并master代碼的時候才有一次Review校坑，而且只是一位同事Review，也不是會議的方式展開千诬，比較隨意耍目，效果不好。
3徐绑、產(chǎn)品經(jīng)理的PRD中沒有明確的寫出拼購有效時間的范圍邪驮，也是導(dǎo)致開發(fā)時考慮遺漏的一個重要原因。產(chǎn)品經(jīng)理的PRD過于粗糙傲茄，需要開發(fā)進(jìn)一步細(xì)化毅访，并加以提醒。

2盘榨、領(lǐng)券中心
6月1號左右俺抽，領(lǐng)券中心的監(jiān)控中，有個接口的可用率始終在99%左右徘徊较曼。線上沒有投訴領(lǐng)券中心有什么問題磷斧。但是618大促期間，不敢怠慢。趕緊張羅調(diào)查原因弛饭。

【直接原因分析】
查看日志冕末，發(fā)現(xiàn)時不時會出現(xiàn)NullPointerException，顯然是代碼邏輯問題侣颂。定位到代碼档桃，發(fā)現(xiàn)有個對象是可能為Null的。在我新增需求代碼的時候憔晒，沒有完全考慮全版本控制代碼藻肄，忽視了低版本中某個對象為null的可能性（客戶端版本小于6.5.0時會出現(xiàn)）。
這個問題之所以之前沒有被發(fā)現(xiàn)拒担，是因?yàn)樵谖倚薷那暗睦洗a中嘹屯，監(jiān)控代碼存在問題，對于異常情況并沒有上報監(jiān)控从撼，導(dǎo)致監(jiān)控中看到的接口調(diào)用始終是100%州弟。原來的開發(fā)者發(fā)現(xiàn)了監(jiān)控的問題，加上了完整的監(jiān)控并上線（6月1日上線）低零，6月1日該問題得以暴露婆翔。
雖然線上沒什么投訴，但是從分析來看掏婶，這個確實(shí)是個BUG啃奴。

【根本原因分析】
1、客觀上第一次在領(lǐng)券中心代碼中開發(fā)新需求雄妥，在沒有完全理解代碼的情況下做了新功能擴(kuò)展纺腊，導(dǎo)致了異常的發(fā)生。
2茎芭、開發(fā)周期縮短近一半，由于618前會封網(wǎng)誓沸，時間卡的比較死梅桩，急于上線的心態(tài)也是一個原因。
3拜隧、原作者review了代碼宿百，但是也沒有發(fā)現(xiàn)問題。還是Review的方式存在問題洪添，不夠嚴(yán)謹(jǐn)垦页。
4、對于異常情況干奢，沒有在最外層進(jìn)行捕捉和處理痊焊，特別是異常的上報，導(dǎo)致上線后沒有能夠發(fā)現(xiàn)這個問題。

3薄啥、總結(jié)
以上是我在今年618期間所處理的兩個線上問題辕羽。處理的過程中，心情復(fù)雜的垄惧。焦急刁愿、緊張、自責(zé)到逊、歉疚铣口、煎熬......五味雜陳。教訓(xùn)是深刻的觉壶，我想以后一看到long和int脑题，一想到接口設(shè)計，這次的教訓(xùn)就會浮現(xiàn)出來掰曾。也許這就是這次經(jīng)歷的價值所在吧旭蠕。