Memcached 的惹禍，.NET 5.0 的背鍋

抱歉，拖到如今才寫這篇爲 .NET 5.0 洗白的博文（以前的博文），很差意思，又錯了，不是洗白，是還 .NET 5.0 的清白。

抱歉，就在今天上午寫這篇博客的過程當中，因爲一個bug被迫在訪問高峯發佈，在10:30~11:10再次引起上次遇到的一樣故障，由此給您帶來麻煩，請您諒解。

2020年10月14日晚上咱們發佈了升級至 .NET 5.0 RC 2 的博客系統，在正式版發佈以前進行升級不是咱們想追求前衛，而是由於：

1. 微軟官博已經說明能夠用於生產環境

RC2 is a 「go live」 release; you are supported using it in production.

2. 正則表達式性能大幅提高（Regular expression performance improvements）

On many of the expressions we’ve tried, these improvements routinely result in throughput improvements of 3-6x, and in some cases, much more.

3. Json 序列化性能提高

JsonSerializer performance is significantly improved in .NET 5.0.

4. 想使用 EF Core 5.0 的新特性（What's New in EF Core 5.0）

最吸引咱們的是第2點，博客系統的代碼中用了不少正則表達式，是耗CPU大戶。

並且升級很簡單：

• TargetFramework 由 netcoreapp3.1 改成 net5.0
• 更新 nuget 包
• 容器鏡像 mcr.microsoft.com/dotnet/core/sdk:3.1 改成 mcr.microsoft.com/dotnet/sdk:5.0，mcr.microsoft.com/dotnet/core/aspnet:3.1 改成 mcr.microsoft.com/dotnet/aspnet:5.0

發佈後從第2天上午訪問高峯的監控數據看，CPU消耗降了10%，效果不錯。

輕鬆升級，提早享受 .NET 5.0 的性能提高，印象中這是咱們在 .NET Core 大版本升級歷史中最愜意的一次。

下午咱們帶着升級後的喜悅心情歡迎新人的加入，如今可以遇到有興趣學習 .NET 的新人也是不容易的，好了，如今能夠直接學 .NET 5.0 了。就在新人歡迎會期間，網站出現了故障，昨晚升級到 .NET 5.0，今天下午就出故障，最大的嫌疑對象顯然是 .NET 5.0，當機立斷地進行回退操做，若是回退到升級以前的版本能恢復正常，那 .NET 5.0 就罪責難逃。

用下面的腳本在k8s集羣上將部署回退到升級以前的容器鏡像

./deploy-blog.sh 2.3.73

回退完成以後，很快恢復正常，鐵證如山，隨後咱們當即發博宣判——博客系統升級到 .NET 5.0 引起的故障，讓還未正式出茅廬的 .NET 5.0 就背上一口沉重的鍋。

幸虧有開發同事沒有這麼片面地看待問題，對故障進行了進一步分析，發現故障與 memcached 服務器的 tcp 鏈接數異常高有關，大量的數據庫鏈接超時是由於連不上 memcached （達到了1萬的最大鏈接數限制）形成大量請求直接訪問數據庫引發的。更進一步地，還找到了重現問題的方法，屢次點擊某些博客，就能讓 memcached tcp 鏈接數飆升，排查後發現這些博客須要被緩存的數據超過了1M，超出了 memcached 單個緩存項的大小限制（默認就是1M），形成數據永遠沒法被緩存，但每次都要徒勞地讀寫 memcached 服務器。咱們針對這個問題進行了修復，修復後從新發布了 .NET 5.0 版，觀察幾天後沒有再次出現故障。

咱們錯怪了 .NET 5.0，咱們的一時武斷讓 .NET 5.0 在即將出道以前先背鍋，咱們向 .NET 5.0 說抱歉，向被誤導的 .NET 開發者說抱歉，咱們會吸收教訓，在故障發生後不要急於發博文，先全面分析問題，不能由於咱們的一時誤判產生誤導。

雖然修復了問題，用上了 .NET 5.0，但問題背後的真正緣由至今沒有弄明白——僅僅幾回鼠標點擊，緩存數據超過1M，就能讓 memcached 服務器的 tcp 鏈接數飆升？可能與咱們使用的 memcached 客戶端 EnyimMemcachedCore，待之後再找時間研究。

今天在寫這篇博文的期間，再次遇到這個故障，看來有緣分，想躲也躲不過去了。今天發生故障與訪問高峯發佈有關，但以前咱們評估過訪問高峯發佈的影響，也就5-10分鐘左右訪問速度變慢，不會產生如此大的重創。此次故障與上次是一樣的表現，memcached tcp 鏈接數異常高，頻頻達到1萬的最大鏈接數限制，打開網頁速度慢就是由於在等待與 memcached 服務器創建 tcp 鏈接，重啓 memcaced 服務器也於事無補，很快就會再次飆升至1萬，平時訪問高峯也就5000左右的鏈接。

從 memcached 服務器的其餘指標看，雖然上萬的 tcp 鏈接，但並無不堪重負，難道僅僅是車多路窄形成的堵車引發你們都通行緩慢？那把路拓寬不就好了，因而將 memcached 服務器的 tcp 最大鏈接數限制由1萬拓寬到2萬，本擔憂鏈接數會飆升到2萬，但沒想到居然恢復正常了。多是某種特殊狀況形成須要稍過萬的 tcp 鏈接，但最大鏈接數限制把你們都堵住了，看來代碼世界也最怕堵車。

今天集中3個多小時的時間才完成這篇粗糙的博文，在故障後分享一篇博文也不是一件容易的事。