嘿!不用太过于担心的单点故障
不知道從什么時候開始,咱們的面試問題清單里,就明明白白寫了,如何處理大流量高并發(fā)問題,如何實現(xiàn)高可用?所以,我也經(jīng)常會去考慮這些問題(哈哈,當(dāng)然不是為了面試)。
大流量,高并發(fā)問題,好像已經(jīng)成了教科書類的問題,無非就是集群,分布式,緩存,讀寫分離,分庫分表,主備,活動預(yù)熱……
如果自己僅停留在這些教科書式的回答,那就顯得太膚淺或者不屑回答這種問題了,不管怎么樣,我還是沒明白其中的好多問題。所以我也經(jīng)常會問自己。。。
首先,集群的概念,個人感覺和負(fù)載均衡是一致的,就是讓一個服務(wù)背后有n個服務(wù)器在提供服務(wù),使外部請求能夠分擔(dān)到多個機器,主要目的在于減輕單機壓力。那么,該怎么做呢?如果是自己搭服務(wù)器,那么,入門級nginx這種工具是一目了然的產(chǎn)品,網(wǎng)上一搜都是這么干的,一個nginx可以支持幾千甚至上萬的請求,所以應(yīng)對一時的壓力自是沒有問題了。如果不是自建呢,比如用阿里云,這里面提供的服務(wù)就比較全了,slb提供天然的集群能力,點點按鈕就搞定,你要做的就是把n臺服務(wù)器部署成完全一致的樣子,讓負(fù)載均衡器能夠調(diào)用過來就行。所以,簡單的集群已經(jīng)不是問題了,解決初步的流量增長,妥妥的。但是,集群有什么問題嗎?或者說是注意的點?主要注意集群和單機的不同,單機做session之類的東西是沒有問題的,但是集群就不能簡單這樣干了,應(yīng)盡量脫離會話保持這種架構(gòu),雖然類似slb這樣服務(wù)都會提供會話保持功能,但是都是以犧牲性能為代價的。日志的打印,線上服務(wù)的日志是一個重要的排查依據(jù),但是隨著集群的部署,打在本機的日志就會不全,導(dǎo)致你查某個問題時,無法很好收集到需要的日志。當(dāng)然解決方案是有的,你可以通過拉取所有機器上日志,一臺臺搜索就可以得到想要的了(太low),salt搜索(高級),日志中心(高級)……
分布式和集群是比較容易搞混的,到少我以前是這么覺得。分布式表現(xiàn)也是多個服務(wù)器同時提供一個功能,不同的是分布式應(yīng)該是使用不同的應(yīng)用提供不同的服務(wù),最終被聚合到一處對外表現(xiàn)出一個功能。分布式分應(yīng)用分布式和數(shù)據(jù)分布式。應(yīng)用分布式,其實轉(zhuǎn)為當(dāng)下流行的詞就叫,微服務(wù),拆分現(xiàn)有的功能為一個個小功能,使其各司一小領(lǐng)域,減小復(fù)雜度提高可用性。數(shù)據(jù)分布式主要是將數(shù)據(jù)分布在不同的地方,從而減輕放在一處帶來的在存儲壓力,通過某種關(guān)系關(guān)聯(lián)起來提供完整服務(wù)。
是的,緩存很重要。所有的服務(wù)都不敢保證不怕壓力的,功夫再高也怕菜刀。減少不必要的訪問壓力是對自己的一種保護更是一種提升能力的方式。梳理用戶的訪問路徑,逐級緩存應(yīng)用,到最后基本壓力就沒了。比如,大名鼎鼎的dns服務(wù)就是這樣,全世界那么多的訪問都通過dns進行解析,隨隨便便同時訪問上億,想想都覺得這個壓力可怕吧,但是通過逐級緩存,使所有的dns服務(wù)器都壓力小了很多。可見緩存的重要性。同樣,在應(yīng)用層面也可以做到逐級緩存,cdn,預(yù)加載,應(yīng)用1..n級服務(wù)器緩存,數(shù)據(jù)緩存。具體到技術(shù)層面有,前端localstorage,本地緩存,cdn就近內(nèi)容緩存,上級應(yīng)用緩存下級應(yīng)用數(shù)據(jù),redis,memcache,mongo,本地緩存,熱點數(shù)據(jù)緩存,數(shù)據(jù)庫設(shè)置查詢緩存策略。如此,把真正最重要的數(shù)據(jù)落到最后的壓力上,應(yīng)對壓力就沒問題了!
? ? 是的,負(fù)載均衡其實也只是用一個單點去代替了另一個單點,但是這個代價是值得的。因為負(fù)載均衡器無需處理業(yè)務(wù)邏輯,只是負(fù)載請求轉(zhuǎn)發(fā),所以能夠承受的壓力自然大得多,所以此時的單點就先不要再去考慮了。同理,如果再在負(fù)載均衡器上面再加一層lvs之類的,其原理也只是用一個單點代替了另一個單點罷了。重點在于,新的單點是否優(yōu)于原有單點。起點也是終點,最終的壓力都可以仍至dns去解決。
? ? 這個技術(shù)的根本目的在于減輕單表數(shù)據(jù)量變大的壓力,意義還是比較大的。但是真正到單表壓力特別大的時候,可能也是公司需要尋找新的數(shù)據(jù)存儲解決方案的時候了。說回分庫分表,分庫分表后,就基本做不到關(guān)聯(lián)查詢了,數(shù)據(jù)庫提供的許多高級工具可能會因此而失效,因此,在做分庫分表時,一定會面臨一場浩浩蕩蕩的技術(shù)改造過程。當(dāng)然還有人在項目初期就已經(jīng)考慮進去了,那就沒啥問題了。
? ? 讀寫分離還是很棒的,有比較大的業(yè)務(wù)都是讀占主要部分,做了讀寫分離后,數(shù)據(jù)庫就可以做主從集群了,壓力就會分?jǐn)偂5?#xff0c;一個重要的問題就是,如何保證讀到數(shù)據(jù)是準(zhǔn)確的?另外,寫數(shù)據(jù)庫壓力依然沒變,對寫場景沒有一點好處。
? ? ?隨著集群功能的便捷易用,服務(wù)器擴展已經(jīng)不是問題,外部壓力大,只要加機器就可以,但是到了數(shù)據(jù)庫呢?經(jīng)常擔(dān)心這些問題,其實也是多慮了。都說了做到多級緩存,到數(shù)據(jù)庫時壓力也不大了。把分布式應(yīng)用的數(shù)據(jù)庫分散到多個數(shù)據(jù)服務(wù)器上,天然的集群。歸檔無用的數(shù)據(jù),減輕單表壓力。數(shù)據(jù)庫的單點還是存在的,那么就把數(shù)據(jù)庫服務(wù)器配置搞好點唄。mycat做路由做分布式數(shù)據(jù)庫。
? ? ?單點問題永遠是存在的,只要沒有達到你的預(yù)警值,就不要太操心。比如,我們往往擔(dān)心集群后,數(shù)據(jù)庫是單點,感覺很麻煩,然后就想分庫分表,讀寫分享,其實還是沒必要的,看具體數(shù)據(jù)再說話。遇到問題了,總能解決。
? ? ? 9. ?技術(shù)預(yù)加載,預(yù)熱……
?
轉(zhuǎn)載于:https://www.cnblogs.com/yougewe/p/9153257.html
總結(jié)
以上是生活随笔為你收集整理的嘿!不用太过于担心的单点故障的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: linux系统最大打开文件数(/etc/
- 下一篇: Ubuntu关于apt-get remo