點擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

回復(fù)”666“獲取新整理的1000+GB資料

1. 二階提交

通常當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)有變化時，它會被寫入本地服務(wù)器的內(nèi)存和磁盤中。但是，當(dāng)數(shù)據(jù)庫是集群或者分布式系統(tǒng)的話，一個提交不僅會發(fā)生在本地，還會發(fā)生在遠程。二階提交意味著必須等待遠程服務(wù)確認(rèn)。然后由于網(wǎng)絡(luò)和其他的延遲問題，這樣的提交相比單機數(shù)據(jù)庫的提交要慢很多。

主從的同步復(fù)制也有這樣的問題，因此，MySQL的解決辦法是半同步（semi-synchronous：MySQL5.5才有的特性，半同步只需要等待slave寫成功日志響應(yīng)即可，并不需要等待slave完成真正的提交），這實際上是二階提交的妥協(xié)。

2. 串行處理

當(dāng)顧客在等待擁有10臺收銀機的超市結(jié)賬時，這是并行工作的。如果有9個收銀員正在休息午餐，只有1個收銀機是開放的，那就變成串行的了。突然，超市就會因為收銀機問題而排起長長的隊伍，讓顧客非常沮喪。

WEB應(yīng)用一定要不惜一切代價避免串行，典型的串行比如分布式鎖。否則，有串行處理的地方就會成為你整個系統(tǒng)的瓶頸。

3. 內(nèi)存不足

對于每一層來說，內(nèi)存都是非常重要的。緩存最合適的地方有哪些呢？接下來舉幾個栗子。

瀏覽器

瀏覽器緩存似乎遙不可及，直到您意識到瀏覽器直接從Web服務(wù)器獲取它渲染頁面需要的數(shù)據(jù)。因此，如果頁面中包含的對象有很長的過期時間，瀏覽器就能否把它們緩存起來，而不需要多次重復(fù)抓取。不僅對用戶體驗更快更好，而且也減輕了服務(wù)端的壓力。

頁面緩存

頁面緩存（不是操作系統(tǒng)層面的pagecache）需要用到比如Varnish（https://www.varnish-cache.org/，淘寶和拼多多都有用過該技術(shù)）這樣的技術(shù)組件。它不能像Apache那樣處理復(fù)雜的頁面，但是它相比Apache能更好的處理簡單的頁面，因此它一般會被部署在Apache前面用來先處理簡單的頁面。

對象緩存

一般會用redis（或者memcache）來處理對象緩存，對象先序列化成比如json，然后保存到redis中。我們的應(yīng)用在訪問數(shù)據(jù)庫前，先訪問redis看是否有我們需要的對象，如果Redis中有，那么從Redis中獲取對象的速度是MySQL數(shù)據(jù)庫的幾十倍甚至上百倍。從而能提高服務(wù)的響應(yīng)速度，一眨眼就返回用戶請求的所有數(shù)據(jù)，讓用戶體驗更好。

4. 監(jiān)控和指標(biāo)不足

監(jiān)控應(yīng)該是如此基礎(chǔ)的東西，你無法想象沒有它的工作。然而，有些公司和項目就是沒有，或者不足，沒有足夠的監(jiān)控，一些服務(wù)器或關(guān)鍵組件被遺漏了。

隨著時間的推移，收集系統(tǒng)和服務(wù)器級數(shù)據(jù)以及應(yīng)用程序和業(yè)務(wù)級可用性的數(shù)據(jù)同樣重要。

5. 日志不足

日志和監(jiān)控關(guān)系非常密切，尤其當(dāng)你定位問題或者調(diào)試的時候，你恨不得需要更多的日志。無論是服務(wù)器系統(tǒng)日志，Apache和MySQL日志，緩存日志等。而且需要做好日志滾動，以及歷史日志備份或者清理。

6. 數(shù)據(jù)庫單點

你的數(shù)據(jù)庫至少應(yīng)該有一個slave，它的好處是當(dāng)master出現(xiàn)問題后，slave頂上來能更快的恢復(fù)數(shù)據(jù)庫從而提供服務(wù)。哪怕你的slave不承擔(dān)讀的壓力，你也應(yīng)該有一個冷備份的slave。

7. 把數(shù)據(jù)庫當(dāng)作隊列

MySQL數(shù)據(jù)庫很擅長存儲關(guān)系型的表數(shù)據(jù)。不幸的是，它不太擅長作為隊列服務(wù)。盡管如此，很多開發(fā)者依然有一些不好的使用習(xí)慣，例如：你的應(yīng)用有一些JOB任務(wù)表，也許有一個狀態(tài)列，這個列的值有這些：INIT，PROCESSING，INQUEUE，FINISHED等。如果是這樣，那么你無形之中把數(shù)據(jù)庫表當(dāng)作隊列來使用了。

由于鎖爭奪以及掃描和輪詢以便找到更多可執(zhí)行任務(wù)，這種解決方案最終會遇到可伸縮性問題，而且這種狀態(tài)列不太適合創(chuàng)建索引。如果有隊列方面的需求，更推薦使用RabbitMQ或者kafka。

8. 使用數(shù)據(jù)庫全文檢索

對任何一個應(yīng)用來說，搜索都是非常重要的功能。盡管MySQL有全文檢索功能，但是它的前提是表必須是MyISAM引擎。然而MyISAM表沒有事務(wù)特性，而且它的性能和體驗都非常差。

成熟的方案都會借助于專業(yè)的搜索服務(wù)，比如：Solr和ElasticSearch。而且這些專業(yè)的搜索服務(wù)客戶端支持非常多的語言，訪問速度也非?？臁６覐椥陨炜s能力都做的很好。

9. ORM

ORM有助于快速原型設(shè)計，并允許那些不擅長SQL的開發(fā)人員讀寫數(shù)據(jù)庫。它們更快，更干凈，并提供更快的功能交付。

然后，當(dāng)DBA發(fā)現(xiàn)一個運行緩存的SQL，并要你的團隊修復(fù)時，你會發(fā)現(xiàn)使用ORM框架的話，排查問題是非常困難的。但是，對于開發(fā)人員來說，排查并優(yōu)化問題SQL是經(jīng)常要做的事情。如果你的項目使用的是ORM，就會帶來巨大的技術(shù)債，而且替換的代價也非常大。所以建議項目使用MyBatis這樣的框架。

10. 沒有儀表盤

汽車如果沒有儀表盤，你將沒辦法開車。同樣的，如果你的應(yīng)用沒有儀表盤，也會帶來很多阻礙。應(yīng)用儀表盤能夠暴露應(yīng)用程序內(nèi)部工作的信息。他們記錄時間并提供有關(guān)應(yīng)用程序花費時間的反饋。

一個非常流行的Web服務(wù)儀表盤解決方案是New Relic（http://newrelic.com/），它提供了吸引所有人的可視化儀表板 - 項目經(jīng)理，開發(fā)人員，運營團隊，甚至業(yè)務(wù)部門都可以在圖表中查看并查看 發(fā)生了什么。

11. 沒有代碼倉庫或者版本控制

盡管在今天來說，這樣的情況是非常罕見的?？傊?#xff0c;你的公司千萬不要在這個方面成為“鶴立雞群”的那一家，一定要把代碼放到代碼倉庫中，強烈推薦Git+Gitlab組合管理。

如果你不用版本控制和代碼倉庫，那么當(dāng)你的項目越來越復(fù)雜時，欠下的技術(shù)債就會越來越多，最終導(dǎo)致整個迭代舉步維艱。

12. 單點問題

如果你的數(shù)據(jù)只存在某一單實例數(shù)據(jù)庫，這就是一個單點問題。如果你的服務(wù)全部部署在一臺服務(wù)器上或者一塊磁盤上，這也是單點問題。

這些單點問題必須不惜一切代價徹底消除它們。此外，意識到系統(tǒng)的單點問題也比較困難。比如，依賴單一的云廠商，這實際上也是單點問題。因為假如你的服務(wù)全部在AWS上，當(dāng)AWS出問題時，你的服務(wù)是完全不可用的。AirBNB就在AWS出現(xiàn)故障時避免了這個問題，欲知更多，請戳鏈接：http://www.iheavy.com/2012/10/23/airbnb-didnt-have-to-fail/。

13. 預(yù)覽模式缺失

如果你嘗試在頭條上發(fā)表評論，或者在微信上發(fā)送一條朋友圈動態(tài)。你可能會收到這樣的提示信息：“對不起，請稍后再試！”?；蛘吣阍谔詫毶现荒茴A(yù)覽商品，但是不能下單。

這種現(xiàn)象就是指，應(yīng)用允許你讀，但不允許你寫。這可能是master庫宕機了，但是slave庫還健在。我們的系統(tǒng)需要具備這種能力，當(dāng)master庫宕機后，slave能正常的處理讀取操作，只是寫操作暫時受到影響。

14. 缺少溝通

在這里談?wù)摐贤赡苡悬c奇怪。但是強大的溝通渠道是非常有必要的，團隊成員必須知道在遇到麻煩時應(yīng)該去找哪些人。而良好的溝通需要自信和知識淵博的領(lǐng)導(dǎo)力，以及傾聽和改進的開放性。

15. 缺乏文檔

文檔發(fā)生在Web應(yīng)用程序的許多層中，比如：前端、UI、后端、運維等。開發(fā)人員需要設(shè)計文檔，以便為查看該代碼的后來者提供提示和參考。運營團隊需要為配置文件添加注釋，以便在事情中斷時提供更改歷史記錄和洞察力。并且應(yīng)該在公司的wiki中記錄業(yè)務(wù)流程和關(guān)系，以幫助人們找到自己問題的解決方案。

文檔在各個層面都非常有幫助，寫文檔是每個人都應(yīng)該具備的習(xí)慣。

16. 缺少故障演練

故障演練總是被一推再推。團隊可能會說，“我們有備份，我們能cover住這個事情?！?沒錯，直到他們嘗試根據(jù)備份恢復(fù)時才并發(fā)現(xiàn)它們不完整，可能丟失了一些配置文件或關(guān)鍵數(shù)據(jù)。

故障演練能夠幫助團隊在他們真正需要之前完成動作。您的公司應(yīng)該把它當(dāng)作運營團隊的一部分日常工作，每年幾次故障恢復(fù)整個應(yīng)用程序。而且使用云服務(wù)器會讓這個事情變得更容易。在這個過程中，您將了解需要多長時間，困難的步驟在哪里，以及需要注意什么。從而在當(dāng)故障真正來臨時，能夠做到從容應(yīng)對！

17. 魯莽行為

你騎著快馬進入小鎮(zhèn)，帶著槍走進沙龍，你覺得你會交朋友嗎？不，你只會嚇唬所有人。信心很好，但最好與團隊合作，團隊的智慧比任何個人都要強。

團隊之間需要傳達正在改變的東西，以管理的方式進行溝通，任何意外等等都應(yīng)該有應(yīng)對計劃。謹(jǐn)慎才能贏得了勝利。并且始終有一個B計劃（Plan B），做的事情做好有回退的辦法，要知道哪些命令具有破壞性，哪些命令無法撤銷。

18. 日益增長的技術(shù)債

隨著應(yīng)用程序多年來不斷發(fā)展，團隊可能會花費越來越多的時間來維護歷史代碼，解決歷史問題。因此，他們沒有多少時間投入新功能。如果您發(fā)現(xiàn)技術(shù)債不斷增加，可能是時候咬緊牙關(guān)來一次重構(gòu)了。重構(gòu)需要時間，而且重構(gòu)不會和開發(fā)新功能、滿足客戶需求一樣帶來立竿見影的效果，但從長遠來看，這是非常值得去做的。

本文翻譯自：http://highscalability.com/blog/2013/8/28/sean-hulls-20-biggest-bottlenecks-that-reduce-and-slow-down.html

想知道更多？掃描下面的二維碼關(guān)注我

---

加技術(shù)群入口（備注：Tech）：

免費星球入口：

最近整理了一份資料，包含Java技術(shù)棧、消息中間件、分布式存儲、大數(shù)據(jù)、高可用架構(gòu)、通用型技術(shù)架構(gòu)等。獲取方式：點擊「在看」，關(guān)注公眾號并在后臺回復(fù)“666”即可獲取。

朕已閱?

總結(jié)

以上是生活随笔為你收集整理的面试官：限制系统扩展能力的瓶颈有哪些？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。