記住這兩幅重要的圖
今天給大家分享兩幅圖，它們是如此的重要，以至于你看到的很多軟件的設計都和他們相關， 可以說圖中展示的問題都是計算機的本質問題。
圖1 計算機各個部件的速度
可以看到，CPU最快，一個時鐘周期是0.3納秒，內存訪問需要120納秒，固態硬盤訪問需要50-150微秒，傳統硬盤訪問需要1-10毫秒， 網絡訪問最慢，都是幾十毫秒。
這幅圖最有趣的地方在于它把計算機世界的時間和人類世界的時間做了對比，我常常把CPU比喻成跑得很快，但是記不住事情的“阿甘”， 他的一個時鐘周期如果按1秒算：
- 內存訪問就是6分鐘
- 固態硬盤是2-6天
- 傳統硬盤是1-12個月
- 網絡訪問就是幾年了!
(1秒= 1000毫秒= 1000,000 微秒 = 1000,000,000納秒)
如果你是CPU，你會覺得這個世界真是慢死了!從硬盤訪問數據得等待“幾天”甚至“幾個月”!
圖2 存儲器的層次結構
來源：《深入理解計算機系統》第3版
圖2把圖1的信息變成了層次化的方式，并且增加了價格信息，它展示了一個真理：世界上沒有免費的午餐。
存儲器越往上速度越快，但是價格越來越貴， 越往下速度越慢，但是價格越來越便宜。
這兩幅圖有什么意義呢?正是由于計算機各個部件的速度不同，容量不同，價格不同，導致了計算機系統/編程中的各種問題以及相應的解決方案， 我來舉幾個例子。
案例1
CPU的速度超級快，不能老是讓它閑著，要充分地壓榨它!
這里有兩個強勁的理由：
1. 人類需要多個程序“同時”運行
我們要把CPU的時間進行分片，讓各個程序在CPU上輪轉，造成一種多個程序同時在運行的假象，即并發。
2. 當CPU遇到IO操作(硬盤，網絡)時，不能坐在那里干等“幾個月”甚至“幾年”
在等待的時候，一定要切換，去執行別的程序。
說起來簡單，但是程序的切換需要保存程序執行的現場，以便以后恢復執行，于是需要一個數據結構來表示，這就是進程了。
如果一個進程只有一個“執行流”， 如果進程去等待硬盤的操作，那這個程序就會被阻塞，無法響應用戶的輸入了，所以必須得有多個“執行流”，即線程。
案例2
需要持久化的數據一定要保存到硬盤中，但是硬盤超級慢，支持不了大量的并發訪問，那怎么辦呢?
可以把最常訪問的熱點數據放到CPU的緩存中嘛， 其實CPU也是這么做的，但是CPU的L1, L2, L3級緩存實在是太小， 根本滿足不了需求。
于是只好退而求其次，把熱點數據放到速度稍慢的內存中，于是應用程序的緩存就出現了。
緩存雖然是解決了問題，但是也帶來了更多的問題，例如：
緩存數據和數據庫數據怎么保持一致性?
緩存如果崩潰了該怎么處理?
數據在一臺機器的內存放不下了，要分布到多個機器上，怎么搞分布式啊，用什么算法?.....
案例3
考慮一個像Tomcat這樣的應用服務器，對于每個請求都要用一個線程來處理，如果現在有一萬個請求進來， Tomcat會建立1萬個線程來處理嗎?
不會的，因為線程多了開銷會很大 ，線程切換起來也很慢，所以它只好用個線程池來復用線程。
現在假設線程池中有一千個可用線程(已經非常多了)，它們都被派去訪問硬盤，數據庫，或者發起網絡調用，這是非常慢的操作，導致這一千個線程都在等待結果的返回(阻塞了)，那剩下的九千個請求就沒法處理了，對吧?
所以后來人們就發明了新的處理辦法，僅使用幾個線程(例如和CPU核心數量一樣)，讓他們瘋狂運行，遇到I/O操作，程序就注冊一個鉤子函數放在那里，然后線程就去處理別的請求，等到I/O操作完成了，系統會給這個線程發送一個事件， 線程就回過頭來調用之前的鉤子函數(也叫回調函數)來處理。
這就是異步，非阻塞的處理方式。Node.js，Vert.x等采用的都是類似的思想。
案例4
Redis使用單線程的方式來處理請求的，為什么用單線程就可以呢? 它為什么不像Tomcat那樣使用多線程和線程池呢?
因為它面對的僅僅是內存，內存的速度在計算機的體系中僅次于CPU，比那些網絡操作不知道要快到哪里去了(可以回頭看看第一幅圖中網絡速度有多慢!)
所以這個唯一的線程就可以快速地執行內存的讀寫操作，完成從許多網絡過來的緩存請求了。單線程還有個巨大的優勢，沒有競爭，不需要加鎖!
看到了吧，我們軟件中的很多問題，其根源都是計算機各個部件的速度差異導致的。
這里可以開一個腦洞，如果硬盤的速度和內存的速度一樣快，并且可以持久化存儲，不會像內存一樣斷電以后數據就丟失了，那我們的電腦和系統會變成什么樣子呢?
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
