曹政(caoz)如何應對并發系列文章

如何應對并發(3) - 需求裁剪

如何應對并發(2) - 請求合并及異步處理

如何應對并發(1) - 關于數據索引

今天講一下，應對并發，應對海量數據請求的一個關鍵策略，也是很多程序員的盲區，需求裁剪。

這個，很多公司，技術人員會說，產品經理提需求，我們完成需求，怎么可能去裁剪需求，而且，裁剪需求會不會顯得很low，說明水平很差呢。

其實，這是一個對需求理解的問題。

所謂需求，并不僅僅是功能實現，還包括性能指標，以及所謂的邊界條件。

實際上，即便是我們所熟知的巨頭，面對性能負載問題，也會采取限定邊界條件的方式來滿足絕大部分用戶的正常請求。

下面，案例說話

案例1：搜索大翻頁問題，還記得我提過的這個搜索翻頁越多，負載越高的問題么。

請問，

淘寶搜索一個關鍵詞，最多翻多少頁？百度呢？google呢？

你們自行測試一下，這些巨頭給出的搜索結果條目數，我跟你們實話說，都是估算值，最大翻頁數，基本不超過100頁。

這就是設定了邊界條件。

正好前幾天一個做比價的創業公司問我技術問題，他們抓了很多商品定價數據，雖然并發不高，但是數據量很大，要在每個搜索中給出結果數和精確翻頁數，結果一個帶搜索條件的 count(*)的問題出來了，效率特別低，執行開銷特別大，跑來問我怎么優化，我告訴他，連百度和谷歌都沒法做這樣的精確結果，你讓我怎么優化。這事就必須從需求出發，第一，不需要精確的返回結果數，第二，翻頁做限定。

案例2：雪崩效應的處理。

前天講的，當緩存扛不住，負載傳遞給數據庫，瞬間過載，怎么處理？你說我多加數據庫行不行？那要緩存干嘛用的呢？你說我緩存做實時同步實時備份？這緩存的存儲效率多高啊，網速能跟的上？

這就涉及一個災難應急機制，簡單說就是 降級服務，有損服務。

在出現類似問題的時候，系統自動降級，將部分用戶請求頻次低，價值低但是系統開銷不低的功能或者數據臨時阻斷停止響應，確保整體系統的穩定性。

比如說，大量用戶會訂閱熱門內容，而少數用戶會訂閱冷門內容，那么在緩存崩潰的情況下，系統優先恢復熱門內容，暫停冷門內容的請求的響應，可能可以在開銷可控的情況下先滿足了90%的訪問請求，當數據庫負載已經回落后再逐步恢復冷門內容的請求，從而使系統在開銷可控的情況下自動完全恢復，避免雪崩效應導致全局崩潰。

那么，有人會問，這個降級會不會很low？ 其實騰訊郵箱和新浪微博都有過類似的處理策略。

在 caoz談能力成長 - 取舍之道 這篇其實提過一些類似案例，在早期我技術并不高明的時候，實現CNZZ統計的功能，其實有非常多的數據是有損服務的，但是實際上用戶并不會感受到，因為你損失的那些邊界條件外的數據是1000個用戶也不會有1個去查詢的內容，而如果你要滿足這些可能需要付出500%甚至更多的系統開銷和研發工作量，這種對于很多早期創業公司來說，非常非常重要。

我們說需求裁剪，說有損服務，并不是說不滿足用戶需求，我知道很多人有技術潔癖或者說追求技術完美，某些文章會說中國的創業太山寨太草根，美國人的創業都是以完美為導向。那么今天我就說一點，如果不看這篇文章，有幾個人知道，google原來搜索的結果是不能翻出超過100頁的？大家天天用淘寶吧，請問有誰知道淘寶搜索的最大翻頁是100頁？ 除了寫蜘蛛抓人家數據的人之外，who care ?

很多站長都用CNZZ，或其他第三方統計對吧，看數據的時候，看看自己網站的來源網頁，請問誰會翻到第20頁之后？

這就是思路的關鍵，用戶對功能的需求，你的滿足度的邊界在哪里？很多程序員沒有這個概念，對于數據規模小，請求并發少的應用來說，這個東西你不考慮也沒什么大不了，但是如果面對數據規模大，請求并發大，你就應該有一個概念，如何設定需求的邊界條件，既能滿足用戶的正常請求可以順暢的響應，同時保證系統在開銷可控的情況下穩定健壯的運營；而當系統出現類似單點故障，雪崩效應呈現的時候，如何設定新的邊界條件，讓用戶在基本可用的情況下給系統一個恢復周期。這些問題都是需要提前思考，并且不斷隨著業務規模的增加而調整的。

案例3：關于主從分離同步的案例

這個案例很好玩，我們剛開始做數據庫主從讀寫分離的時候，經驗也不是很豐富，然后發現一個問題，主從同步經常會有一個時延，雖然時間很短，大部分在1秒以內，但是在應用中，我們發現，用戶發一個帖子，然后發完后就應該進入這個帖子的展示頁吧，帖子發布到主數據庫，而展示頁調用的是從數據庫，結果部分用戶發完帖子，因為延遲，就看到了一個該帖子不存在的界面，這肯定是一個不好的情況么。當然，技術上肯定有各種解決方法，比如對這種新內容選擇從主數據庫訪問，做一些標定等等，但是呢，我們就做了一個特別偷懶取巧的方案。什么方案呢？用戶發完帖子后，先進入一個中轉頁，告訴用戶您的帖子發布成功，3秒后自動進入帖子頁。（對這個場景很多人都熟悉吧），就這么一個特簡單甚至有點不是很友好的設計，主從同步延遲的問題就基本解決了。

這不是一個完美方案，但是簡單有效，而且對用戶來說，雖然體驗略有不好，但其實也不會有非常大的困擾。 當然，今天，我不推薦這樣的方案，但是小團隊，創業公司，遇到一些比較頭疼的技術問題，其實完全可以通過需求的一點點微調就繞開，我希望分享的是這個觀點。

每次看到創業團隊的技術把一個簡單的項目做的又累又復雜的時候，我都想說一句，能不能簡化一下，從需求到技術方案。很多所謂的復雜根本沒有任何實際意義，除了浪費時間和精力外。

最后，留一個思考題

還是大翻頁問題，一些論壇系統確實有大翻頁的實際需要，在這種情況下，我說，只要不允許任意指定頁碼的跳轉翻頁，而是只允許上翻頁下翻頁（或者可以加上上五頁，下五頁這樣的快速翻頁）那么就會有特別高的效率的實現方法，有興趣的同學思考一下。 就是用索引的思路去思考。