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

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

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

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

先說昨天有人反應的問題：有網友提醒，說數據查詢只能用到一個索引，這個表達不精確，只限于單表的查詢，而聯表查詢實際上每個表都可以有其獨立的索引被用到。

非常感謝這個提醒，其實呢，這里必須額外解釋一下。

我剛工作的時候呢，特別喜歡寫復雜的SQL，覺得自己特酷，寫出一個復雜的連表查詢邏輯感覺智商優越感爆棚，然后還十分得瑟的給人看這SQL寫的思路多牛逼。但是工作十多年后呢，慢慢意識到這樣其實不對，特別是面對高并發，高處理請求的時候，聯表查詢所帶來的問題不僅僅是效率的問題，更包括分布式，擴展性的問題，后來我們就制定了一個原則，禁止使用聯表查詢。所以我系列文章里不會提及任何涉及聯表查詢的優化問題。可能有的朋友會覺得這樣是不是有些極端，是的。但是對于應對高并發的業務場景，這一條其實并不是我個人的規定，很多公司和架構師也都有這樣的規定。

那么禁止聯表查詢會帶來一系列無法滿足查詢需求的問題，這個在后面的文章我會提到，在計劃中這是第四篇的內容。

另外，我可能是跟草根打交道比較多，加上我自己學數據庫和編程基本都是野路子，所以特別理解草根創業者，以及野路子程序員面對技術問題的困境和糾結，實話說，因為一直以來跟草根創業者溝通比較多，在實戰中遇到的各種優化問題和處理場景，我敢說要比很多大公司的架構師還要多，但也實話說可能并不是那些大公司所遇到的問題那么深。所以我的風格一直是，讓菜鳥能夠更容易理解和領悟，達到處理較高量級的性能優化水平。但是從幾年前架構師大會上，就總有一些逼格很高的技術人員瞧不起我的路數，覺得太low太沒技術含量，這個，我也是承認的，不過，敬請自便吧。

我所提到的幾個案例大家可以看到，其實都是非常典型的，使用場景廣泛的，一般小公司很可能撞死在里面的案例，昨天還有人留言以前一直被蜘蛛拖死論壇，看了我的文章后才恍然大悟。但是昨天沒有完全解讀解決方案，請允許我挖個坑，因為飯要一口口吃，我這個系列會逐漸把處理思路一步步貫通。

很多人都知道說，如果查詢請求過多，其實可以用內存來做緩存，比如memcache，比如redis，很多緩存方案，但是如果更新請求過多，那么緩存就沒法用了。而更新請求往往比查詢請求更消耗資源，這樣系統i/o壓力就非常大。

當然，這里我要額外說一句，并不是查詢請求緩存化了系統效率就會提升，和緩存設計有關，同時緩存的使用也會帶來新的風險。

1、如果緩存命中率不高，可能反而是負擔

很多人覺得加了緩存就能提高效率，未必。如果緩存命中率不高，查詢完緩存沒有再去查詢數據庫，那么實際上是額外開銷，只有命中率超過50%，才是有價值的緩存。

2、如果緩存設計不合理，系統開銷只會更高

這個我們自己也遇到過，比如有些人喜歡把大量記錄扔在緩存里，一條記錄可能內容幾百k甚至幾兆，但是在我們用的時候可能只用到這個記錄的某幾個字段，這時候通過緩存去讀取記錄然后再從記錄中拆解到這個字段的開銷，比直接從數據庫中讀取這個記錄的指定字段，系統開銷要大不少。導致你需要更多的緩存服務器，當然，好處是數據庫畢竟壓力降了（數據庫分布式比緩存服務器分布式設計上要復雜一些），但是對于我這樣的摳門