文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲   。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。

 之前的時(shí)候，阿粉一直在看同事面試，但是呢，阿粉并沒(méi)有自己去面試，而無(wú)意間打開(kāi)Boss的時(shí)候，發(fā)現(xiàn)一家公司私聊了我，我回復(fù)了一下之后，竟然說(shuō)我可以去面試，不曾想，面試一個(gè)問(wèn)題，讓我的薪資瞬間被砍掉了5K，你如果不想自己出去要的薪資被砍，那么你要會(huì)設(shè)計(jì)這個(gè)。

[[335203]]

一般的普通項(xiàng)目架構(gòu)

像阿粉的朋友所在的公司屬于一個(gè)中小型的公司，公司的項(xiàng)目都是按照客戶(hù)的要求來(lái)定制進(jìn)行開(kāi)發(fā)的，而服務(wù)器的數(shù)量那是少的可憐，什么高并發(fā)，不考慮，什么高可用，也不考慮，一臺(tái)服務(wù)器上面部署了自己的項(xiàng)目，有時(shí)候連個(gè)圖片服務(wù)器都沒(méi)有，他們的圖就是這個(gè)樣子的。

是不是看著很簡(jiǎn)陋的樣子，直接瀏覽器客戶(hù)端和單一服務(wù)器之間進(jìn)行交流了，如果訪(fǎng)問(wèn)人數(shù)在千人以上，比如秒殺個(gè)限量款，那估計(jì)可能直接就涼了，“Boom”的一下就訪(fǎng)問(wèn)失敗了。

稍微進(jìn)階版本的項(xiàng)目架構(gòu)

這個(gè)時(shí)候一般網(wǎng)站架構(gòu)還是采用單體架構(gòu)，但是服務(wù)器也相對(duì)的增加了，終于增加了數(shù)據(jù)庫(kù)服務(wù)器和應(yīng)用類(lèi)服務(wù)器在加上圖片服務(wù)器，算是組成了一個(gè)小小的進(jìn)階版本的項(xiàng)目架構(gòu)。

也就是說(shuō)我們?cè)诓渴饝?yīng)用的時(shí)候，手動(dòng)把應(yīng)用服務(wù)器上的Tomcat給關(guān)掉，然后替換系統(tǒng)的代碼war包，接著重新啟動(dòng)Tomcat。

這時(shí)候把數(shù)據(jù)單獨(dú)的部署在另外的一個(gè)服務(wù)器上面，存放網(wǎng)站的全部核心數(shù)據(jù)。

然后在另外一臺(tái)獨(dú)立的服務(wù)器上部署NFS作為圖片服務(wù)器，存放網(wǎng)站的全部圖片。

這時(shí)候呢，代碼執(zhí)行的是請(qǐng)求，數(shù)據(jù)訪(fǎng)問(wèn)在另外一臺(tái)服務(wù)器，而圖片在另外一臺(tái)服務(wù)器上面，這樣就通過(guò)增加了服務(wù)器來(lái)部署的普通版本的項(xiàng)目架構(gòu)就完成了，而大部分的項(xiàng)目都是這個(gè)樣子的吧，畢竟小公司人力有限呀。

簡(jiǎn)單的支持高并發(fā)，高可用的項(xiàng)目架構(gòu)

不知道大家在面試的時(shí)候說(shuō)這個(gè)的時(shí)候面試官有沒(méi)有問(wèn)過(guò)，如果你們的應(yīng)用服務(wù)器掛了，你們?cè)趺刺幚?

是的，應(yīng)用服務(wù)器真的會(huì)出事，那在項(xiàng)目的應(yīng)用服務(wù)器真的出事之后，我們?cè)趺刺幚?，在換個(gè)服務(wù)器，那么你很多想對(duì)應(yīng)的配置就要做出更改，需要更改一大堆的東西，那么你會(huì)有很長(zhǎng)時(shí)間的維護(hù)期，維護(hù)代價(jià)很高了呀。

這時(shí)候我們就出現(xiàn)了這個(gè)：

如果說(shuō)我們有一臺(tái)其中的應(yīng)用服務(wù)器宕機(jī)了，不干活了，那么接下來(lái)，另外的一臺(tái)服務(wù)器就會(huì)正常的使用，并且，在同時(shí)使用的時(shí)候，我們還能夠把從瀏覽器來(lái)的大量的請(qǐng)求分發(fā)一下，直接對(duì)半劈成2份，如果說(shuō)其中有一個(gè)服務(wù)器的配置“高的飛起”，那么我們還可以通過(guò)配置，給他的請(qǐng)求讓他多一點(diǎn)，“設(shè)置權(quán)重”，這樣讓他分擔(dān)更多的壓力，而那個(gè)比較 low 的服務(wù)器的話(huà)，承擔(dān)的相應(yīng)的請(qǐng)求就會(huì)減少一點(diǎn)，畢竟性能比較低。

而在這個(gè)時(shí)候還會(huì)出現(xiàn)另外一種意外，那就是數(shù)據(jù)庫(kù)服務(wù)器宕機(jī)了，怎么辦?相同的原理，增加另外的一個(gè)數(shù)據(jù)庫(kù)服務(wù)器，也就是主從數(shù)據(jù)庫(kù)。

那么為什么要做主從復(fù)制，不單單是因?yàn)檫@一個(gè)服務(wù)器宕機(jī)的問(wèn)題，還有如果對(duì)數(shù)據(jù)庫(kù)的讀和寫(xiě)都在同一個(gè)數(shù)據(jù)庫(kù)服務(wù)器中操作，業(yè)務(wù)系統(tǒng)性能會(huì)降低。

而我們很多的項(xiàng)目在數(shù)據(jù)上面需要的就是比較重要的，就很多就是做讀寫(xiě)分離，而為了提升業(yè)務(wù)系統(tǒng)性能，優(yōu)化用戶(hù)體驗(yàn)，可以通過(guò)做主從復(fù)制(讀寫(xiě)分離)來(lái)減輕主數(shù)據(jù)庫(kù)的負(fù)載。

一臺(tái)用于寫(xiě)入數(shù)據(jù)，一臺(tái)用于同步主的數(shù)據(jù)并用于數(shù)據(jù)查詢(xún)操作。

配置好主從復(fù)制之后，同一張表，只能對(duì)一個(gè)服務(wù)器寫(xiě)操作。

業(yè)務(wù)分離

現(xiàn)在很多項(xiàng)目的架構(gòu)都是所有人的業(yè)務(wù)代碼都寫(xiě)在了一起，亂七八糟的，好幾個(gè)人的代碼，維護(hù)起來(lái)那叫一個(gè)崩潰，當(dāng)你看到這樣的項(xiàng)目的時(shí)候，你就會(huì)發(fā)現(xiàn)，人都傻了，這是個(gè)什么鬼，改動(dòng)一點(diǎn)，其他的不好用了，那叫一個(gè)崩潰呀。

這時(shí)候我們就需要把我們的業(yè)務(wù)徹底的做出分割，比如商城里面的，訂單屬于一塊的業(yè)務(wù)，積分屬于一部分的業(yè)務(wù)，物流屬于另外一部分的業(yè)務(wù)，這時(shí)候我們就需要分成三塊的業(yè)務(wù)模塊。

也就是相當(dāng)于每一塊的內(nèi)容都屬于一個(gè)服務(wù)，而這些服務(wù)疊加起來(lái)可就不是1+1=2的問(wèn)題了，這些業(yè)務(wù)服務(wù)相加起來(lái)，這時(shí)候完整的項(xiàng)目和你把所有的內(nèi)容同一寫(xiě)到一個(gè)部分的內(nèi)容差距是非常大的，尤其是在代碼冗余方面，做的那是相當(dāng)透徹的。

而說(shuō)到這些內(nèi)容的話(huà)，其實(shí)已經(jīng)算差不多了，但是再更深的阿粉是真的沒(méi)有了解到那么多，而阿粉之前沒(méi)想過(guò)這些內(nèi)容會(huì)在你面試的時(shí)候問(wèn)到，可能阿粉當(dāng)時(shí)只是想自己做個(gè)咸魚(yú)，不去關(guān)心架構(gòu)方面的事情，而架構(gòu)方面的事情確實(shí)很多公司很看重的一點(diǎn)。

在這里阿粉給大家再次貢獻(xiàn)出此次面試的其他的問(wèn)題，并且給出詳細(xì)的解答，并且阿粉也是很欣慰的，只是壓了工資，而沒(méi)有說(shuō)直接拒絕。

1.Redis分區(qū)實(shí)現(xiàn)方案

• 客戶(hù)端分區(qū)：

客戶(hù)端分區(qū)就是在客戶(hù)端就已經(jīng)決定數(shù)據(jù)會(huì)被存儲(chǔ)到哪個(gè)redis節(jié)點(diǎn)或者從哪個(gè)redis節(jié)點(diǎn)讀取。大多數(shù)客戶(hù)端已經(jīng)實(shí)現(xiàn)了客戶(hù)端分區(qū)。

• 代理分區(qū)：

代理分區(qū) 意味著客戶(hù)端將請(qǐng)求發(fā)送給代理，然后代理決定去哪個(gè)節(jié)點(diǎn)寫(xiě)數(shù)據(jù)或者讀數(shù)據(jù)。代理根據(jù)分區(qū)規(guī)則決定請(qǐng)求哪些Redis實(shí)例，然后根據(jù)Redis的響應(yīng)結(jié)果返回給客戶(hù)端。

• 查詢(xún)路由：

查詢(xún)路由(Query routing) 的意思是客戶(hù)端隨機(jī)地請(qǐng)求任意一個(gè)redis實(shí)例，然后由Redis將請(qǐng)求轉(zhuǎn)發(fā)給正確的Redis節(jié)點(diǎn)。Redis Cluster實(shí)現(xiàn)了一種混合形式的查詢(xún)路由，但并不是直接將請(qǐng)求從一個(gè)redis節(jié)點(diǎn)轉(zhuǎn)發(fā)到另一個(gè)redis節(jié)點(diǎn)，而是在客戶(hù)端的幫助下直接redirected到正確的redis節(jié)點(diǎn)。

這些都是阿粉死記硬背背下來(lái)的，關(guān)于這種東西，沒(méi)有實(shí)際親身實(shí)踐過(guò)的，沒(méi)有遇到過(guò)的問(wèn)題的，都是屬于被diss的，但是面試官好像理解也不是很深，也是知道，但是具體的也沒(méi)有仔細(xì)的深挖我這塊的內(nèi)容。

2.SpringBean的生命周期

說(shuō)實(shí)話(huà)，這個(gè)問(wèn)題，面試好像現(xiàn)在都是必問(wèn)的知識(shí)點(diǎn)了，阿粉的同事面試也是被問(wèn)，但是巧了，之前阿粉就寫(xiě)過(guò)關(guān)于SpringBean的生命周期的，文章鏈接給大家送上，大家可以仔細(xì)查看，可以共同交流呦。

面試官：兄弟你來(lái)闡述一下Spring框架中Bean的生命周期?

所以大家一定要把這個(gè)準(zhǔn)備好呦，SpringBean的生命周期，從初始化到最終的銷(xiāo)毀中間經(jīng)歷了什么，過(guò)程是什么，流程怎么理解。

3.HashMap 和 Hashtable

這個(gè)問(wèn)題我在回答的時(shí)候我就分開(kāi)了，分門(mén)別類(lèi)的比較比如說(shuō)：

• 線(xiàn)程安全
• 性能優(yōu)劣
• NULL
• 實(shí)現(xiàn)方式
• 容量擴(kuò)容

我分成了五塊的內(nèi)容作答，如果說(shuō)你只能夠剛剛想起來(lái)其中的三到四點(diǎn)也是不錯(cuò)的，至少比你只會(huì)說(shuō)他們的線(xiàn)程安全和是否允許鍵為空來(lái)的好很多，如果大家有興趣，請(qǐng)尋找集合系列文章，在過(guò)往的歷史當(dāng)中尋找一下，有很多關(guān)于HashMap 和 Hashtable的面試點(diǎn)。

4.JVM內(nèi)存模型和優(yōu)化

這個(gè)我相信只要是工作了兩到三年的程序員肯定都會(huì)，我就給大家簡(jiǎn)單說(shuō)說(shuō)，之前的文章圖解，

關(guān)于其他的問(wèn)題，都不是比較經(jīng)典的，都是屬于項(xiàng)目業(yè)務(wù)中的了，阿粉就不再一一給大家介紹了，總結(jié)起來(lái)就一句話(huà)，基礎(chǔ)你要掌握，擴(kuò)展你更要會(huì)，不然面試想要高工資?那是不可能的，畢竟不是每家公司都缺“大爺”，不是么?

阿粉在這里希望大家找到自己理想的工作，等疫情穩(wěn)定了，直接跳槽工資“Double”。