之前有用戶聯(lián)系我們阿里云，反映在使用OCS時(shí)會(huì)出現(xiàn)超時(shí)錯(cuò)誤，希望我們阿里云技術(shù)團(tuán)隊(duì)能夠幫忙解決。通常用戶會(huì)將熱點(diǎn)數(shù)據(jù)存放到OCS中，用以提高用戶的業(yè)務(wù)處理響應(yīng)速度，因此超時(shí)問(wèn)題對(duì)于OCS來(lái)講非常敏感，這引起了阿里云OCS團(tuán)隊(duì)的重視，隨即開(kāi)始了調(diào)查分析。

對(duì)于一個(gè)網(wǎng)絡(luò)服務(wù)，通常導(dǎo)致超時(shí)的原因包括：網(wǎng)絡(luò)抖動(dòng)、CPU某個(gè)核心負(fù)載過(guò)高、內(nèi)存不足導(dǎo)致的頻繁swap、網(wǎng)卡負(fù)載過(guò)高、協(xié)議BUG導(dǎo)致的回包有誤。通過(guò)分析，我們發(fā)現(xiàn)了客戶端自身存在的某些問(wèn)題導(dǎo)致OCS超時(shí)；除此之外，進(jìn)一步的分析表明在某些特殊情況下OCS自身的一些問(wèn)題也會(huì)導(dǎo)致超時(shí)。下面我們來(lái)看看阿里云OCS團(tuán)隊(duì)的工程師們是怎么樣分析并解決這些超時(shí)問(wèn)題的。

在進(jìn)入技術(shù)細(xì)節(jié)分析之前，先簡(jiǎn)單介紹一下阿里云OCS的大致工作機(jī)制：基于Memcached協(xié)議的用戶請(qǐng)求從阿里云ECS服務(wù)器上發(fā)出，通過(guò)阿里云SLB（負(fù)載均衡）連到阿里云OCS的前端proxy，再連接后端底層的服務(wù)器集群進(jìn)行最終處理。

對(duì)于超時(shí)問(wèn)題，我們最先考慮問(wèn)題可能在于客戶端到SLB，SLB到proxy之間的網(wǎng)絡(luò)及協(xié)議問(wèn)題。為了直觀分析排查問(wèn)題，在考慮proxy承受能力之后，我們建議用戶不經(jīng)過(guò)阿里云SLB直接連我們的proxy，這樣可以直接在服務(wù)器抓包了解異常情況時(shí)的報(bào)文交互，同時(shí)也排除了SLB可能出問(wèn)題的干擾。

在用戶將自己的服務(wù)器切到我們的proxy上后，我們對(duì)每個(gè)客戶端抓包，其中一臺(tái)的報(bào)文如下：

我們看到截圖片段中有兩個(gè)客戶端給proxy的回報(bào)，超過(guò)了200ms，這說(shuō)明客戶端負(fù)載有問(wèn)題，經(jīng)過(guò)與用戶確認(rèn)這一情況得到了證實(shí)。由此我們知道：某些情況下使用OCS出現(xiàn)超時(shí)是用戶客戶端負(fù)載問(wèn)題導(dǎo)致，只要合理配置客戶端就能解決此類問(wèn)題。

接下來(lái)我們進(jìn)一步調(diào)查發(fā)現(xiàn)，另外還有一些超時(shí)是因?yàn)榘⒗镌芆CS自身的原因?qū)е碌摹０⒗镌芆CS對(duì)于存儲(chǔ)數(shù)據(jù)的大小是有限制的，即Value最大為1MB。若超出此限制，客戶端會(huì)收到“Value too large”的錯(cuò)誤信息。某些OCS超時(shí)錯(cuò)誤恰恰是這個(gè)尺寸大小導(dǎo)致的。上文提到OCS的處理流程是proxy調(diào)用底層后端服務(wù)，我們分析OCS代碼發(fā)現(xiàn)底層后端代碼中對(duì)報(bào)文Value長(zhǎng)度的限制是 1000 * 1000字節(jié)，而proxy層根據(jù)memcached協(xié)議是1024 * 1024字節(jié)。這種不一致導(dǎo)致當(dāng)客戶端發(fā)送的Value長(zhǎng)度處于1000 * 1000 ~ 1024 * 1024字節(jié)的臨界區(qū)間時(shí)， set eplaceadd操作沒(méi)有任何信息返回，即沒(méi)有response；而客戶端會(huì)一直等待這個(gè)response，直到拋出超時(shí)異常。雖然是個(gè)看起來(lái)很初級(jí)的BUG，但由于它僅在某些特殊情況下出現(xiàn)，所以定位它還是花了一點(diǎn)時(shí)間。找到了這個(gè)問(wèn)題，解決起來(lái)就容易了。

解決了上述客戶端負(fù)載和尺寸檢測(cè)BUG的問(wèn)題，仍有另外的用戶給我們報(bào)告OCS超時(shí)問(wèn)題。莫非還有其他的原因？

對(duì)于新出現(xiàn)的這些超時(shí)情況，我們還是采取在客戶端抓包的辦法，看到的數(shù)據(jù)如下：

從圖中可以得知，客戶端10.162.108.239到OCS服務(wù)器端10.160.124.220的連接在18:06分開(kāi)始休眠到18:41被喚醒，發(fā)起一次Get請(qǐng)求；之后客戶端經(jīng)歷多次重試后，TCP才知道連接已斷。這期間客戶端未從服務(wù)器端收到任何報(bào)文。

上文提到過(guò)，用戶的請(qǐng)求要通過(guò)阿里云SLB（負(fù)載均衡）連到阿里云OCS的多臺(tái)proxy，再連接后端底層的服務(wù)器集群。所以我們考慮是否存在SLB導(dǎo)致超時(shí)問(wèn)題的可能性。

經(jīng)過(guò)與阿里云SLB部門(mén)的同學(xué)溝通得知，SLB會(huì)斷開(kāi)15分鐘未活躍的連接，且不會(huì)給客戶端和服務(wù)器發(fā)任何FIN或RST報(bào)文。這樣就可能出現(xiàn)一個(gè)問(wèn)題，即客戶端和服務(wù)器都認(rèn)為連接正常。然而當(dāng)客戶端應(yīng)用層發(fā)起一個(gè)請(qǐng)求時(shí)，該請(qǐng)求被交至TCP層，而TCP層不知道此時(shí)鏈接已經(jīng)斷開(kāi)，于是重發(fā)該請(qǐng)求數(shù)次，直到應(yīng)用層的超時(shí)時(shí)間到，就返回Timeout。在某些極端情況下，如果應(yīng)用層沒(méi)有設(shè)過(guò)期或者過(guò)期時(shí)間非常長(zhǎng)，就會(huì)一直等到TCP層超時(shí)才會(huì)返回。

在得知了SLB的這個(gè)情況后，為了繞開(kāi)這個(gè)問(wèn)題，我們?cè)贠CS服務(wù)器上設(shè)置了TCP層的keepAlive包。將/proc/sys/net/ipv4/tcp_keepalive_time由默認(rèn)的7200s改為450s一次。接著我們做測(cè)試，客戶端連接到OCS服務(wù)器上，然后抓包如下：

圖中顯示在20:58分時(shí)，服務(wù)端TCP層觸發(fā)keepalive包，但始終不能發(fā)出去。即客戶端依然收不到任何信息。在客戶端同時(shí)抓包，抓不到任何來(lái)自服務(wù)器11211端口的KeepAlive報(bào)文。接下來(lái)我們查看客戶端的netstat狀態(tài)如下：

即客戶端依然認(rèn)為自己還處于連接狀態(tài)，因?yàn)闆](méi)有收到服務(wù)器的任何消息。如果此時(shí)用戶發(fā)起請(qǐng)求，仍然會(huì)得到最初用戶反饋的現(xiàn)象，即繼續(xù)重傳直至超時(shí)。

看來(lái)這個(gè)問(wèn)題還沒(méi)有解決。我們繼續(xù)分析，考慮到一個(gè)可能性：我們阿里云OCS的客戶端都是跑在阿里云ECS上，會(huì)不會(huì)這里有什么情況？

于是我們與阿里云ECS團(tuán)隊(duì)的同學(xué)溝通了解到：ECS上開(kāi)啟了netfilter，其中一條過(guò)濾規(guī)則是對(duì)于空閑時(shí)間大于180s的連接，netfilter會(huì)將它從established表中剔除，且不會(huì)通知客戶端服務(wù)器，當(dāng)客戶端或者服務(wù)端還在該鏈接上面發(fā)送報(bào)文時(shí)，NODE將不再轉(zhuǎn)發(fā)。

至此情況大致明朗了：因?yàn)槭峭ㄟ^(guò)ECS和SLB建立的連接，而ECS和SLB對(duì)于連接空閑時(shí)間都有各自不同的限制，所以可能出現(xiàn)OCS服務(wù)器與客戶端之間的KeepAlive包丟失，從而導(dǎo)致超時(shí)情況的發(fā)生。于是我們把OCS服務(wù)器的KeepAlive改為90s，繞過(guò)SLB、ECS，啟動(dòng)應(yīng)用再重新測(cè)試，問(wèn)題解決。

表面上看起來(lái)同樣都是OCS超時(shí)的問(wèn)題，其真正的原因卻是各不相同。我們?cè)谶@里描述起來(lái)看似很輕松，但是在實(shí)際工作中能夠迅速及時(shí)的解決這些問(wèn)題卻絕非易事。有的很容易就被發(fā)現(xiàn)解決，有的原因找起來(lái)卻是破費(fèi)腦筋。通過(guò)我們阿里云工程師們的努力，能夠讓用戶更好的使用阿里云服務(wù)，這是我們工作最大的樂(lè)趣和價(jià)值所在。