新聞動(dòng)態(tài)
計(jì)算機(jī)的本質(zhì)問(wèn)題
常見(jiàn)問(wèn)題 發(fā)布者:cya 2020-01-03 08:50 訪問(wèn)量:213
來(lái)自:碼農(nóng)翻身(微信號(hào):coderising)
今天給大家分享兩幅圖,它們是如此的重要,以至于你看到的很多軟件的設(shè)計(jì)都和他們相關(guān), 可以說(shuō)圖中展示的問(wèn)題都是計(jì)算機(jī)的本質(zhì)問(wèn)題。
圖1 計(jì)算機(jī)各個(gè)部件的速度
可以看到,CPU最快,一個(gè)時(shí)鐘周期是0.3納秒,內(nèi)存訪問(wèn)需要120納秒,固態(tài)硬盤(pán)訪問(wèn)需要50-150微秒,傳統(tǒng)硬盤(pán)訪問(wèn)需要1-10毫秒, 網(wǎng)絡(luò)訪問(wèn)最慢,都是幾十毫秒。
這幅圖最有趣的地方在于它把計(jì)算機(jī)世界的時(shí)間和人類(lèi)世界的時(shí)間做了對(duì)比,我常常把CPU比喻成跑得很快,但是記不住事情的“阿甘”, 他的一個(gè)時(shí)鐘周期如果按1秒算:
內(nèi)存訪問(wèn)就是6分鐘
固態(tài)硬盤(pán)是2-6天
傳統(tǒng)硬盤(pán)是1-12個(gè)月
網(wǎng)絡(luò)訪問(wèn)就是幾年了!
(1秒= 1000毫秒= 1000,000 微秒 = 1000,000,000納秒)
如果你是CPU,你會(huì)覺(jué)得這個(gè)世界真是慢死了!從硬盤(pán)訪問(wèn)數(shù)據(jù)得等待“幾天”甚至“幾個(gè)月”!
圖2 存儲(chǔ)器的層次結(jié)構(gòu)
來(lái)源:《深入理解計(jì)算機(jī)系統(tǒng)》第3版
圖2把圖1的信息變成了層次化的方式,并且增加了價(jià)格信息,它展示了一個(gè)真理:世界上沒(méi)有免費(fèi)的午餐。
存儲(chǔ)器越往上速度越快,但是價(jià)格越來(lái)越貴, 越往下速度越慢,但是價(jià)格越來(lái)越便宜。
這兩幅圖有什么意義呢?正是由于計(jì)算機(jī)各個(gè)部件的速度不同,容量不同,價(jià)格不同,導(dǎo)致了計(jì)算機(jī)系統(tǒng)/編程中的各種問(wèn)題以及相應(yīng)的解決方案, 我來(lái)舉幾個(gè)例子。
CPU的速度超級(jí)快,不能老是讓它閑著,要充分地壓榨它!
這里有兩個(gè)強(qiáng)勁的理由:
1. 人類(lèi)需要多個(gè)程序“同時(shí)”運(yùn)行
我們要把CPU的時(shí)間進(jìn)行分片,讓各個(gè)程序在CPU上輪轉(zhuǎn),造成一種多個(gè)程序同時(shí)在運(yùn)行的假象,即并發(fā)。
2. 當(dāng)CPU遇到IO操作(硬盤(pán),網(wǎng)絡(luò))時(shí),不能坐在那里干等“幾個(gè)月”甚至“幾年”
在等待的時(shí)候,一定要切換,去執(zhí)行別的程序。
說(shuō)起來(lái)簡(jiǎn)單,但是程序的切換需要保存程序執(zhí)行的現(xiàn)場(chǎng),以便以后恢復(fù)執(zhí)行,于是需要一個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)表示,這就是進(jìn)程了。
如果一個(gè)進(jìn)程只有一個(gè)“執(zhí)行流”, 如果進(jìn)程去等待硬盤(pán)的操作,那這個(gè)程序就會(huì)被阻塞,無(wú)法響應(yīng)用戶的輸入了,所以必須得有多個(gè)“執(zhí)行流”,即線程。
需要持久化的數(shù)據(jù)一定要保存到硬盤(pán)中,但是硬盤(pán)超級(jí)慢,支持不了大量的并發(fā)訪問(wèn),那怎么辦呢?
可以把最常訪問(wèn)的熱點(diǎn)數(shù)據(jù)放到CPU的緩存中嘛, 其實(shí)CPU也是這么做的,但是CPU的L1, L2, L3級(jí)緩存實(shí)在是太小, 根本滿足不了需求。
于是只好退而求其次,把熱點(diǎn)數(shù)據(jù)放到速度稍慢的內(nèi)存中,于是應(yīng)用程序的緩存就出現(xiàn)了。
緩存雖然是解決了問(wèn)題,但是也帶來(lái)了更多的問(wèn)題,例如:
緩存數(shù)據(jù)和數(shù)據(jù)庫(kù)數(shù)據(jù)怎么保持一致性?
緩存如果崩潰了該怎么處理?
數(shù)據(jù)在一臺(tái)機(jī)器的內(nèi)存放不下了,要分布到多個(gè)機(jī)器上,怎么搞分布式啊,用什么算法?.....
考慮一個(gè)像Tomcat這樣的應(yīng)用服務(wù)器,對(duì)于每個(gè)請(qǐng)求都要用一個(gè)線程來(lái)處理,如果現(xiàn)在有一萬(wàn)個(gè)請(qǐng)求進(jìn)來(lái), Tomcat會(huì)建立1萬(wàn)個(gè)線程來(lái)處理嗎?
不會(huì)的,因?yàn)榫€程多了開(kāi)銷(xiāo)會(huì)很大 ,線程切換起來(lái)也很慢,所以它只好用個(gè)線程池來(lái)復(fù)用線程。
現(xiàn)在假設(shè)線程池中有一千個(gè)可用線程(已經(jīng)非常多了),它們都被派去訪問(wèn)硬盤(pán),數(shù)據(jù)庫(kù),或者發(fā)起網(wǎng)絡(luò)調(diào)用,這是非常慢的操作,導(dǎo)致這一千個(gè)線程都在等待結(jié)果的返回(阻塞了),那剩下的九千個(gè)請(qǐng)求就沒(méi)法處理了,對(duì)吧?
所以后來(lái)人們就發(fā)明了新的處理辦法,僅使用幾個(gè)線程(例如和CPU核心數(shù)量一樣),讓他們瘋狂運(yùn)行,遇到I/O操作,程序就注冊(cè)一個(gè)鉤子函數(shù)放在那里,然后線程就去處理別的請(qǐng)求,等到I/O操作完成了,系統(tǒng)會(huì)給這個(gè)線程發(fā)送一個(gè)事件, 線程就回過(guò)頭來(lái)調(diào)用之前的鉤子函數(shù)(也叫回調(diào)函數(shù))來(lái)處理。
這就是異步,非阻塞的處理方式。Node.js,Vert.x等采用的都是類(lèi)似的思想。
Redis使用單線程的方式來(lái)處理請(qǐng)求的,為什么用單線程就可以呢? 它為什么不像Tomcat那樣使用多線程和線程池呢?
因?yàn)樗鎸?duì)的僅僅是內(nèi)存,內(nèi)存的速度在計(jì)算機(jī)的體系中僅次于CPU,比那些網(wǎng)絡(luò)操作不知道要快到哪里去了(可以回頭看看第一幅圖中網(wǎng)絡(luò)速度有多慢?。?nbsp;
所以這個(gè)唯一的線程就可以快速地執(zhí)行內(nèi)存的讀寫(xiě)操作,完成從許多網(wǎng)絡(luò)過(guò)來(lái)的緩存請(qǐng)求了。單線程還有個(gè)巨大的優(yōu)勢(shì),沒(méi)有競(jìng)爭(zhēng),不需要加鎖!
看到了吧,我們軟件中的很多問(wèn)題,其根源都是計(jì)算機(jī)各個(gè)部件的速度差異導(dǎo)致的。
這里可以開(kāi)一個(gè)腦洞,如果硬盤(pán)的速度和內(nèi)存的速度一樣快,并且可以持久化存儲(chǔ),不會(huì)像內(nèi)存一樣斷電以后數(shù)據(jù)就丟失了,那我們的電腦和系統(tǒng)會(huì)變成什么樣子呢?
作者簡(jiǎn)介:
劉欣,前IBM架構(gòu)師,近20年從業(yè)經(jīng)驗(yàn),"碼農(nóng)翻身"公眾號(hào)作者,暢銷(xiāo)書(shū)《碼農(nóng)翻身》作者,用故事講解技術(shù)是拿手好戲。撥開(kāi)技術(shù)迷霧,輕松了解技術(shù)本質(zhì),從"碼農(nóng)翻身"開(kāi)始。
●編號(hào)941,輸入編號(hào)直達(dá)本文
●輸入m獲取到文章目錄
前端開(kāi)發(fā) 更多推薦《25個(gè)技術(shù)類(lèi)微信公眾號(hào)》 涵蓋:程序人生、算法與數(shù)據(jù)結(jié)構(gòu)、黑客技術(shù)與網(wǎng)絡(luò)安全、大數(shù)據(jù)技術(shù)、前端開(kāi)發(fā)、Java、Python、Web開(kāi)發(fā)、安卓開(kāi)發(fā)、iOS開(kāi)發(fā)、C/C++、.NET、Linux、數(shù)據(jù)庫(kù)、運(yùn)維等。
【推薦閱讀】
豐富優(yōu)質(zhì)的內(nèi)容對(duì)網(wǎng)站的作用
網(wǎng)頁(yè)設(shè)計(jì)的核心技術(shù)
關(guān)鍵字: 計(jì)算機(jī)的本質(zhì)問(wèn)題 開(kāi)封晨展科技
文章連接: http://www.hsjyfc.com.cn/cjwt/665.html
版權(quán)聲明:文章由 晨展科技 整理收集,來(lái)源于互聯(lián)網(wǎng)或者用戶投稿,如有侵權(quán),請(qǐng)聯(lián)系我們,我們會(huì)立即刪除。如轉(zhuǎn)載請(qǐng)保留
晨展解決方案
晨展新聞