想了(le／liǎo)想,還是(shì)先畫一系列的(de)圖,再來(lái)解釋一下什麽是(shì)WEB開發.

第一層 入門介紹圖

适合:剛入門互聯網,沒多少基礎知識和(hé / huò)專業知識.

爲(wéi / wèi)嘛這(zhè)個(gè)圖上(shàng)傳的(de)不(bù)清楚?算了(le／liǎo).我也(yě)不(bù)知道(dào)

對于(yú)大(dà)多數剛剛接觸到(dào)互聯網這(zhè)個(gè)職業的(de)人(rén)來(lái)說(shuō),對于(yú)軟件是(shì)怎麽編寫的(de),大(dà)概的(de)職業是(shì)怎麽劃分的(de),理解到(dào)這(zhè)個(gè)程度就(jiù)夠了(le／liǎo).

整個(gè)系統架構可以(yǐ)分成三層(分層是(shì)碼農必備思維).

第一層,叫展示層,又被稱之(zhī)爲(wéi / wèi)前端.展示層這(zhè)個(gè)名字,其實有點不(bù)精确,确切的(de)來(lái)說(shuō),應該叫用戶層,或者是(shì)輸入輸出(chū)層,或者叫用戶交互層.

它的(de)目标很簡單,就(jiù)是(shì)接受用戶的(de)輸入,并将結果反饋給用戶.

什麽叫做輸入呢?鍵盤,鼠标,聲音,圖像等等都是(shì)輸入,最簡單的(de)輸入就(jiù)是(shì)鍵盤和(hé / huò)鼠标,你們如果看過各種黑客電影,不(bù)管是(shì)在(zài)鍵盤上(shàng)啪啪啪,還是(shì)在(zài)空氣中點點點,都是(shì)輸入.

輸出(chū)就(jiù)是(shì)展示出(chū)來(lái)的(de)結果,在(zài)屏幕上(shàng)就(jiù)是(shì)文字動畫,在(zài)音箱就(jiù)是(shì)聲音之(zhī)類的(de).

叫展示層的(de)原因,是(shì)因爲(wéi / wèi)大(dà)部分的(de)情況下,都是(shì)用戶隻需要(yào / yāo)看,少部分才是(shì)操作.

所以(yǐ)通常是(shì)用展示層來(lái)代指用戶的(de)輸入輸出(chū)層.

爲(wéi / wèi)什麽要(yào / yāo)分層?

其實最早在(zài)互聯網沒有出(chū)現之(zhī)前,分層是(shì)一個(gè)相對而(ér)言,軟件設計裏的(de)概念.但是(shì)在(zài)現在(zài),就(jiù)很簡單了(le／liǎo),你可以(yǐ)理解爲(wéi / wèi),在(zài)你的(de)手機,電腦,智能手環上(shàng)運行的(de),都是(shì)展示層.

在(zài)過去,單機軟件的(de)時(shí)代,你可以(yǐ)簡單理解爲(wéi / wèi)它不(bù)是(shì)分層的(de)(雖然在(zài)系統的(de)内部依然有層次的(de)劃分).

而(ér)在(zài)聯網的(de)時(shí)代,所有的(de)數據和(hé / huò)交互都是(shì)由雲端的(de)服務器來(lái)存儲和(hé / huò)處理.

這(zhè)個(gè)層次就(jiù)很好理解了(le／liǎo),就(jiù)是(shì)一個(gè)在(zài)用戶端,一個(gè)是(shì)在(zài)雲端.

所以(yǐ)上(shàng)面的(de)這(zhè)個(gè)圖更新一下,應該就(jiù)是(shì)這(zhè)樣的(de).

這(zhè)樣能否理解清楚一點?

所以(yǐ)從簡單的(de)意義上(shàng)來(lái)說(shuō),前端就(jiù)是(shì)指的(de)用戶這(zhè)一端,後端就(jiù)是(shì)指的(de)服務器這(zhè)一端,也(yě)是(shì)雲端.

什麽叫做服務器呢?

你在(zài)家裏看到(dào)的(de)電腦叫PC, PC一般而(ér)言,都是(shì)配置比較低,給個(gè)人(rén)使用.

除了(le／liǎo)PC還有小型機,大(dà)型機等等,這(zhè)種服務器不(bù)是(shì)你現在(zài)看到(dào)的(de)樣子(zǐ),而(ér)是(shì)這(zhè)種.

算了(le／liǎo)不(bù)找圖了(le／liǎo),我也(yě)沒怎麽見過,畢竟不(bù)經常去機房,對型号什麽的(de)也(yě)沒那麽熟悉,搜"刀片服務器"就(jiù)好.

在(zài)過去,有一個(gè)笑話是(shì)這(zhè)麽說(shuō)的(de):

"不(bù),您不(bù)可以(yǐ)在(zài)公司的(de)電腦是(shì)複制,在(zài)家裏的(de)電腦上(shàng)粘貼.多貴的(de)電腦都不(bù)行"

可是(shì)現在(zài)真不(bù)是(shì)什麽問題了(le／liǎo),這(zhè)就(jiù)是(shì)最近幾年雲的(de)價值,很多軟件都改成Sass平台,或者是(shì)App這(zhè)種應用,或者是(shì)多端統一.

數據放在(zài)雲端,才可以(yǐ)做到(dào)多端統一,不(bù)需要(yào / yāo)本地(dì / de)存儲.

雲端的(de)電腦就(jiù)叫做服務器,業務層和(hé / huò)持久層,就(jiù)是(shì)在(zài)雲端.

這(zhè)也(yě)是(shì)前後端區分的(de)重要(yào / yāo)區别,不(bù)是(shì)以(yǐ)語言來(lái)區分前端和(hé / huò)後端,而(ér)是(shì)看程序是(shì)運行在(zài)用戶端,還是(shì)運行在(zài)雲端.在(zài)用戶端的(de),就(jiù)是(shì)前端,在(zài)雲端的(de),就(jiù)是(shì)後端.

這(zhè)個(gè)概念區分了(le／liǎo)以(yǐ)後,我們再來(lái)看看,爲(wéi / wèi)什麽之(zhī)前叫WEB應用,和(hé / huò)現在(zài)的(de)前端又有什麽區别.

在(zài)過去,沒有SPA,沒有客戶端的(de)時(shí)候,流行兩種模式,一種叫CS架構,一種叫BS架構.

現在(zài)已經很久沒人(rén)提到(dào)了(le／liǎo).

CS架構,其實指的(de)就(jiù)是(shì)桌面端,就(jiù)是(shì)PC的(de)應用軟件,一般都是(shì)用C來(lái)寫(還是(shì)C++或C#?我對C這(zhè)套體系不(bù)夠熟悉,對桌面端接觸的(de)不(bù)多.)

BS架構,指的(de)就(jiù)是(shì)網頁端.過去的(de)網頁端,原生JS+JQuery是(shì)主流,網頁又分成兩種類型,一種叫靜态網頁,一種叫動态網頁.

靜态網頁就(jiù)是(shì)隻有Html(不(bù)考慮JS),内容是(shì)在(zài)Html裏寫死的(de).一般都用于(yú)不(bù)經常修改的(de)部分,比如說(shuō)關于(yú)我們,公司介紹之(zhī)類的(de),每一個(gè)網頁都有自己的(de)獨有設計,不(bù)好統一,也(yě)不(bù)經常修改,沒有必要(yào / yāo)做成動态.

動态網頁就(jiù)是(shì)指,頁面的(de)框架一緻,但是(shì)内空不(bù)同,比如說(shuō)知乎的(de)個(gè)人(rén)主頁,結構是(shì)相似的(de),但是(shì)不(bù)同的(de)人(rén)看到(dào)的(de)數據不(bù)一樣.這(zhè)就(jiù)是(shì)通過前端傳過來(lái)的(de)用戶ID,去後端取數據的(de)過程.

之(zhī)前的(de)動态網頁,把數據變成Html的(de)這(zhè)個(gè)過程,是(shì)在(zài)服務器端完成的(de),我把它稱之(zhī)爲(wéi / wèi)渲染,因爲(wéi / wèi)這(zhè)個(gè)術語,還有人(rén)說(shuō)我不(bù)懂Http,說(shuō)渲染就(jiù)是(shì)浏覽器做的(de)事兒.

這(zhè)也(yě)是(shì)在(zài)過去,很多老的(de)工程師,後端和(hé / huò)前端一塊寫的(de)原因,也(yě)是(shì)很多全菜工程師的(de)來(lái)源.

所以(yǐ)那個(gè)時(shí)候,說(shuō)到(dào)WEB工程師,其實在(zài)某種程度上(shàng),就(jiù)是(shì)跟CS工程師做區分而(ér)來(lái)的(de).你想要(yào / yāo)做一個(gè)WEB程序,你大(dà)概要(yào / yāo)懂數據庫,要(yào / yāo)能讀寫,還要(yào / yāo)能展示給用戶.

即使在(zài)現在(zài),在(zài)傳統行業中也(yě)會有很多人(rén)這(zhè)麽做,外包公司和(hé / huò)二三線城市非常常見.

所以(yǐ)題主的(de)原話是(shì)這(zhè)樣的(de)

"目前正在(zài)學習JAVA WEB開發（主要(yào / yāo)後台，有時(shí)間也(yě)會學習前端）。"

這(zhè)裏其實就(jiù)是(shì)指的(de)是(shì)傳統意義上(shàng)的(de)WEB開發,前端後端都包括,這(zhè)個(gè)方向,嚴格意義上(shàng)來(lái)說(shuō),不(bù)屬于(yú)互聯網,更多的(de)見于(yú)企業軟件,銀行,證券,學校.

通常沒有産品經理,隻有項目經理,每一個(gè)工程師,比技術更重要(yào / yāo)的(de)往往是(shì)業務知識.

醫療和(hé / huò)财務也(yě)經常有這(zhè)種,OA和(hé / huò)稅務其實挺常見的(de).因此,站在(zài)這(zhè)個(gè)角度上(shàng),題主的(de)描述沒有什麽大(dà)的(de)問題.

當然這(zhè)裏還有一個(gè)錯誤的(de)術語使用,就(jiù)是(shì)後台.确切的(de)來(lái)說(shuō),應該叫後端.

後端是(shì)指運行在(zài)雲端的(de)代碼.

前端是(shì)指運行在(zài)用戶端的(de)代碼.

前台是(shì)指外部用戶使用的(de)系統.

後台是(shì)指公司内部使用的(de)系統.

這(zhè)是(shì)正确的(de)描述方式.因此,題主應該是(shì)指做後端,也(yě)就(jiù)是(shì)Java,但是(shì)同時(shí)也(yě)會寫一些前端代碼,JS和(hé / huò)CSS這(zhè)些.

這(zhè)個(gè)提前搞清楚了(le／liǎo),再來(lái)說(shuō)說(shuō)看.

現在(zài)的(de)App這(zhè)麽多,小程序這(zhè)麽火,WEB開發是(shì)不(bù)是(shì)就(jiù)沒什麽價值了(le／liǎo)?

答案當然是(shì)錯的(de).

看了(le／liǎo)上(shàng)邊的(de)圖,其實已經描述很清楚了(le／liǎo).

在(zài)過去,把靜态網頁,變成動态網頁的(de)過程,是(shì)由服務器端來(lái)完成的(de).

而(ér)現在(zài),SPA的(de)天下,把靜态網頁變成動态網頁,是(shì)由浏覽器端完成的(de).

這(zhè)要(yào / yāo)感謝兩個(gè)人(rén),一個(gè)是(shì)Ajax前端,一個(gè)是(shì)App大(dà)人(rén).

Ajax最早隻是(shì)用來(lái)無刷新獲取數據,減少網絡傳輸的(de)數據量.

現在(zài)被原來(lái)當成是(shì)前端和(hé / huò)後端的(de)标準訪問方式.

App其實是(shì)脫胎在(zài)于(yú)原有的(de)CS架構,在(zài)CS架構中,過去是(shì)通過WEBService等傳輸數據,用XML來(lái)描述,而(ér)在(zài)現在(zài),多半是(shì)用Json.

而(ér)手機端,Android和(hé / huò)Ipone,其實就(jiù)是(shì)兩台小小計算機,手機手機,現在(zài)可以(yǐ)理解爲(wéi / wèi)就(jiù)是(shì)拿在(zài)手裏的(de)計算機.

所以(yǐ)Android和(hé / huò)Iphone理所當然的(de)選擇了(le／liǎo)用Http的(de)方式,用Json格式來(lái)向後端傳輸數據.

用圖來(lái)表示,就(jiù)是(shì)這(zhè)樣的(de).

畫個(gè)圖用了(le／liǎo)13分鍾.

這(zhè)是(shì)過去的(de)樣子(zǐ),那個(gè)時(shí)候,說(shuō)是(shì)WEB開發要(yào / yāo)學Java和(hé / huò)JS,不(bù)算太過分.

　那麽Andriod和(hé / huò)IOS是(shì)什麽樣子(zǐ)的(de)呢？他(tā)們理論上(shàng)來(lái)講和(hé / huò)CS架構是(shì)等同的(de).所以(yǐ)他(tā)們是(shì)這(zhè)樣的(de).

很好,這(zhè)次隻用了(le／liǎo)三分鍾.

看到(dào)客戶端和(hé / huò)服務器端之(zhī)間的(de)差别了(le／liǎo)麽?

靜态頁面,素材,代碼是(shì)提前安裝在(zài)用戶手機上(shàng)的(de).在(zài)Android是(shì)就(jiù)是(shì)APK,在(zài)IOS上(shàng)就(jiù)是(shì)IPA.爲(wéi / wèi)什麽客戶端的(de)用戶體驗比在(zài)網頁端好,就(jiù)在(zài)于(yú)客戶是(shì)需要(yào / yāo)你先安裝,在(zài)安裝的(de)時(shí)候,把一些模闆和(hé / huò)素材提前下載到(dào)本地(dì / de),和(hé / huò)後端的(de)通信,隻獲取數據就(jiù)好.

這(zhè)直接導緻了(le／liǎo)移動移動的(de)流行,很早之(zhī)前智能手機就(jiù)可以(yǐ)訪問網頁,但是(shì)網頁做不(bù)到(dào)這(zhè)種流暢的(de)體驗,原因就(jiù)在(zài)于(yú)是(shì),每打開一次網頁,都需要(yào / yāo)加載一次資源,代碼,樣式等等,而(ér)在(zài)過去4G還沒有那麽流暢,手機的(de)内存和(hé / huò)CPU沒有那麽大(dà)和(hé / huò)快的(de)時(shí)候,浏覽器的(de)應用體驗很差,基本上(shàng)是(shì)不(bù)可用的(de)狀态.

現在(zài)呢?你其實很難感知到(dào),你的(de)手機和(hé / huò)雲端一直相連.

所以(yǐ)這(zhè)個(gè)時(shí)候的(de)後端工程師做什麽呢?

一邊繼續提供WEB服務,一邊給Android和(hé / huò)IOS提供數據接口.

兩者之(zhī)間的(de)差别,就(jiù)在(zài)于(yú)是(shì)過去需要(yào / yāo)在(zài)服務器端用模闆技術,把靜态網頁變成動态網頁.

而(ér)現在(zài),需要(yào / yāo)生成JSON的(de)數據接口,不(bù)用再關心頁面如何跳轉.

那後端的(de)工程量是(shì)減輕了(le／liǎo)多少呢?

其實跟沒減輕相差不(bù)多,因爲(wéi / wèi)一旦到(dào)了(le／liǎo)雲端,後端的(de)主要(yào / yāo)工作,其實是(shì)在(zài)架構方面.這(zhè)個(gè)等下,我還是(shì)會圖來(lái)表示一下.

我們先接着往下看,看看WEB怎麽改變這(zhè)種被App不(bù)斷蠶食的(de)狀态.

App應用增多,大(dà)量的(de)開發人(rén)員轉向了(le／liǎo)Andriod和(hé / huò)IOS,難道(dào)網頁就(jiù)死了(le／liǎo)麽?

移動時(shí)代造就(jiù)了(le／liǎo)很多英雄,性能和(hé / huò)用戶體驗是(shì)必不(bù)可少的(de)環節.

而(ér)WEB可不(bù)可以(yǐ)和(hé / huò)Android和(hé / huò)IOS一樣,也(yě)能夠提前把資源加載到(dào)本地(dì / de),提前把代碼放到(dào)本地(dì / de),和(hé / huò)後端隻通過數據接口來(lái)通信?

答案當然是(shì)可以(yǐ)的(de).Manifest+Ajax就(jiù)是(shì)解決這(zhè)個(gè)問題的(de)好方案.

Manifest可以(yǐ)讓浏覽器離線使用網頁,所以(yǐ),理論上(shàng)來(lái)講,你的(de)網頁也(yě)隻需要(yào / yāo)讓用戶加載第一次.通過版本号來(lái)判斷是(shì)否需要(yào / yāo)更新本地(dì / de)的(de)文件.再通過Ajax獲取數據,就(jiù)可以(yǐ)實現和(hé / huò)App一樣的(de)功能.

畫成圖可能是(shì)這(zhè)個(gè)樣子(zǐ)的(de).

SPA技術的(de)發展更是(shì)給了(le／liǎo)前端更好用的(de)工具,完美的(de)複用框架,隻更換其中的(de)内容,很适合網頁的(de)結構.

所以(yǐ)再回過頭來(lái)看題主的(de)問題.

感覺現在(zài)很多WEB網站都隻是(shì)展示性的(de)，用戶主要(yào / yāo)活躍在(zài)移動APP上(shàng)。不(bù)知道(dào)現在(zài)WEB開發還有什麽應用的(de)前景？

因爲(wéi / wèi)題主之(zhī)前說(shuō)了(le／liǎo),自己主要(yào / yāo)是(shì)做後台(Java),=>其實應該是(shì)自己主做後端,也(yě)會寫一點JS.

那麽從現在(zài)的(de)結構圖上(shàng)來(lái)看,所謂的(de)用戶活躍在(zài)移動App上(shàng),對後端人(rén)員的(de)影響有多大(dà)呢?

1.在(zài)Android和(hé / huò)IOS的(de)使用場景下,後端人(rén)員的(de)職責減輕,不(bù)再用模闆語言,将靜态網頁轉變成動态網頁,隻需要(yào / yāo)提供Json數據接口.

2.在(zài)SPA的(de)使用場景下,後端人(rén)員的(de)職責減輕,和(hé / huò)App端一樣,也(yě)是(shì)隻需要(yào / yāo)提供數據接口.

這(zhè)代表什麽含義?代表後端很開心啊,本來(lái)後端的(de)職責就(jiù)是(shì)架構的(de)穩定和(hé / huò)可擴容性,業務邏輯什麽的(de)都是(shì)小菜,負責前端展示也(yě)不(bù)是(shì)後端這(zhè)幫悶騷男的(de)High點.

所以(yǐ)用戶活躍在(zài)App上(shàng),對後端人(rén)員的(de)影響就(jiù)是(shì),把一些原本不(bù)想專注,也(yě)不(bù)願意專注的(de)技術棧移走了(le／liǎo),繼續專注于(yú)自己的(de)架構穩定上(shàng).

什麽算後端架構呢,後端不(bù)是(shì)畫了(le／liǎo)一個(gè)增删改查麽,不(bù)就(jiù)是(shì)在(zài)圖裏一個(gè)方框表示麽.

我們等會再看一下,後端倒底是(shì)什麽樣的(de).你就(jiù)會明白,爲(wéi / wèi)什麽說(shuō)移動App的(de)發展,包括SPA的(de)發展,以(yǐ)及小程序的(de)發展,不(bù)但不(bù)會對後端有沖擊,反而(ér)讓後端的(de)地(dì / de)位更穩重.

第二層,初級架構圖,系統若隻如初建,寫什麽架構來(lái)現眼.

一切一切的(de)開端,都來(lái)自于(yú)互聯網的(de)用戶壓力.

如果沒有來(lái)自用戶訪問的(de)壓力,那麽後端的(de)世界就(jiù)太簡單了(le／liǎo).

再重新回過頭來(lái)看這(zhè)張圖.

在(zài)這(zhè)裏,業務層的(de)一個(gè)目标就(jiù)是(shì)把數據取出(chū)來(lái),再轉換成Json數據接口給前端.

而(ér)持久層呢,通常是(shì)用數據庫,而(ér)數據最常用的(de)還是(shì)關系數據庫,在(zài)關系數據庫中,最常見的(de)是(shì)Mysql.

Mysql本身是(shì)不(bù)提供Json接口的(de),所以(yǐ)才會出(chū)來(lái)ORM這(zhè)種東西,把數據庫中的(de)表結構變成Java裏的(de)Model,再進一步拼裝成Json數據.

Mysql靠什麽和(hé / huò)業務層交互呢?靠Sql語句.

Sql語句定義了(le／liǎo)一套語法規則,最簡單的(de)就(jiù)是(shì) select id from user where name = '暗滅'

這(zhè)種單表查詢,意思是(shì)我要(yào / yāo)用戶名表查詢名字=暗滅的(de)人(rén)的(de)ID.

然而(ér)Mysql并不(bù)是(shì)單純的(de)存取數據,它還支持多種查詢方式,還支持函數.這(zhè)表示什麽呢?

很多數據我都可以(yǐ)通過Sql語句,讓Mysql來(lái)幫我實現了(le／liǎo)~~

如果你有機會看到(dào)很多外包團隊的(de)代碼,你會發現他(tā)們的(de)特點就(jiù)是(shì),Java做爲(wéi / wèi)中間件,幾乎不(bù)做任何的(de)業務邏輯處理,寫代碼的(de)套路就(jiù)是(shì)先設計表結構,再寫一堆Sql語句,然後Java隻是(shì)做爲(wéi / wèi)一個(gè)中間件把SqL語句的(de)結果,傳達給前端而(ér)已.幾乎沒有什麽業務邏輯.

甚至連接口都沒有...隻有一個(gè)通用的(de)接口(這(zhè)種代碼我看完之(zhī)後也(yě)是(shì)醉了(le／liǎo).)

他(tā)的(de)壞處在(zài)哪裏呢?

不(bù)好調試,這(zhè)是(shì)問題之(zhī)一,但是(shì)不(bù)好調試并不(bù)是(shì)不(bù)能調試,忍一忍還能過去.

性能不(bù)好,這(zhè)是(shì)問題之(zhī)二.

這(zhè)個(gè)性能問題是(shì)緻命的(de)問題啊.

Mysql本身,并不(bù)是(shì)爲(wéi / wèi)了(le／liǎo)支持高并發的(de)性能而(ér)出(chū)現的(de),他(tā)提供的(de)各種複雜的(de)Sql語法,也(yě)很難在(zài)性能上(shàng)達标.

簡單說(shuō),Mysql在(zài)性能上(shàng)的(de)支持,最重要(yào / yāo)的(de)就(jiù)是(shì)索引.

各種Sql優化的(de)核心也(yě)就(jiù)是(shì)怎麽樣多利用Mysql的(de)索引.

但是(shì)SQL的(de)優化總是(shì)有瓶頸的(de).這(zhè)種瓶頸體現在(zài)兩個(gè)地(dì / de)方.

一個(gè)是(shì)複雜的(de)Sql語句執行的(de)速度非常慢,有可能幾十秒.

另一個(gè)是(shì)一旦并發到(dào)200以(yǐ)上(shàng)或者更高,Mysql就(jiù)會搞不(bù)定.

像淘寶雙11這(zhè)種訪問量,單純靠Mysql可以(yǐ)麽?

噢,剛剛還漏說(shuō)了(le／liǎo)一句,性能還可能靠分庫分表來(lái)解決一部分.

包括讀寫分離等.但是(shì)無論哪種解決方案,其實給我們的(de)思考就(jiù)是(shì),有沒有一種比較簡單的(de)方式,能夠承擔起用戶的(de)高并發,并且擴展性好,又足夠的(de)穩定?

這(zhè)時(shí)候有兩種方案誕生.

一種是(shì)找到(dào)關系數據庫的(de)弱點,直接升級爲(wéi / wèi)Kev-Value數據庫,又被稱之(zhī)爲(wéi / wèi)NoSql數據庫.

一種是(shì)緩存.

緩存是(shì)出(chū)現在(zài)KV數據庫之(zhī)前的(de),如果我沒記錯的(de)話.

什麽叫緩存呢?

Mysql自己有緩存.

舉個(gè)例子(zǐ),在(zài)修真院的(de)課程體系中,所有的(de)職業都有15個(gè)任務,每個(gè)任務都有任務詳情,操作步驟.

如果我查詢的(de)是(shì)Java的(de)任務體系,我會訪問數據庫.

網絡傳輸啊,并發請求啊還是(shì)會讓Mysql搞不(bù)定大(dà)并發的(de)場景.

怎麽解決?

我可不(bù)可以(yǐ)在(zài)Java的(de)虛拟機裏,把取過來(lái)的(de)任務數據全部用對象存儲?

很簡單啊,一個(gè)Map<Long,List<Task>> id_taskList 就(jiù)搞定了(le／liǎo).

前端來(lái)請求的(de)時(shí)候,隻要(yào / yāo)是(shì)告訴我ID,我就(jiù)從id_taskList裏去,根本不(bù)用去訪問數據庫.

這(zhè)個(gè)時(shí)候如果有并發請求,我會害怕麽?

根本不(bù)怕~~

而(ér)且我完全可以(yǐ)做負載均衡啊.理論上(shàng)來(lái)說(shuō),如果隻是(shì)請求這(zhè)麽一個(gè)任務列表的(de)話,這(zhè)種方式就(jiù)足夠了(le／liǎo).

具體單機能扛多少壓力,可以(yǐ)去試一下.TPS在(zài)1000應該問題不(bù)大(dà).