關於大型網站技術演進的思考（十九）--網站靜態化處理—web前端優化—上（11）
對於一個網路請求的處理，是由兩個不同型別的操作共同完成，這兩個操作是CPU的計算操作和IO操作，如果我們以處理效率角度來評判這兩個操作，CPU操作效率是光速的，而IO操作就不盡然了，計算機裡的IO操作就是對儲存資料介質的操作，計算機裡有如下幾個介質可以儲存資料，它們分別是：CPU的一級快取、二級快取、記憶體、硬碟和網路，一級快取儲存和讀取資料的能力接近光速，它比二級快取快個5倍到6倍，但是不管是一級快取還是二級快取，它們儲存資料量太少了，做不了什麼大事情，下面就是記憶體了，以一級快取的效率做參照，一級快取比記憶體速度快100多倍，到了硬碟儲存和讀取資料效率就更慢了，一級快取比硬碟要快1000多萬倍，到了網路就慢的更不像話了，一級快取比網路要快一億多倍，可見一個請求處理的效率瓶頸都是由IO引起的。
相關推薦
關於大型網站技術演進的思考（十九）--網站靜態化處理—web前端優化—上（11）
對於一個網路請求的處理，是由兩個不同型別的操作共同完成，這兩個操作是CPU的計算操作和IO操作，如果我們以處理效率角度來評判這兩個操作，CPU操作效率是光速的，而IO操作就不盡然了，計算機裡的IO操作就是對儲存資料介質的操作，計算機裡有如下幾個介質可以儲存資料，它們分別是：CPU的一級快取、二級快取、記憶
關於大型網站技術演進的思考（十四）--網站靜態化處理—前後端分離—上（6）
前文講到了CSI技術，這就說明網站靜態化技術的講述已經推進到了瀏覽器端了即真正到了web前端的範疇了，而時下web前端技術的前沿之一就是前後端分離技術了，那麼在這裡網站靜態化技術和前後端分離技術產生了交集，所以今天我將討論下前後端分離技術，前後端分離技術討論完後，下一篇文章我將會以網站靜態化技術的角度回過
關於大型網站技術演進的思考（十五）--網站靜態化處理—前後端分離—中（7）
上篇裡我講到了一種前後端分離方案，這套方案放到服務端開發人員面前比放在web前端開發人員面前或許得到的掌聲會更多，我想很多資深前端工程師看到這樣的技術方案可能會有種說不出來的矛盾心情，當我的工作逐漸走向越來越專業化的前端開發後，我就時常被這套前後端分離方案所困惑，最近我終於明白了這個困惑的本源在哪裡了，那
關於大型網站技術演進的思考（十六）--網站靜態化處理—前後端分離—下（8）
我第一次聽說nodejs技術大概是在2009年年末，不過我真正認真在網路上進一步瞭解nodejs還是在2010年年中，當時對nodejs的認識和我現在對nodejs的認識有著天壤的區別，開始想了解nodejs我只是為了感慨谷歌公司開發的V8引擎居然如此強大，它不僅僅可以作為chrome瀏覽器的javasc
資料庫系統概論（第九章： 關係查詢處理和查詢優化）
第9章 關係查詢處理和查詢優化 查詢優化分類 ： 代數優化：指關係代數表示式的優化 物理優化：指存取路徑和底層操作演算法的選擇9.1 關係資料庫系統的查詢處理 9.1.1 查詢處理步驟 ※關係資料庫管
關於大型網站技術演進的思考（十）--網站靜態化處理—動靜整合方案（2）
上篇文章我簡要的介紹了下網站靜態化的演進過程，有朋友可能認為這些知識有點過於稀鬆平常了，而且網站靜態化的技術基點也不是那麼高深和難以理解，因此它和時下日新月異的web前端技術相比，就顯得不倫不類了。其實當我打算寫本系列的之前我個人覺得web前端有一個點是很多人都知道重要，但是有常常低估它作用的，那就是we
關於大型網站技術演進的思考（十七）--網站靜態化處理—滿足靜態化的前後端分離（9）
前後端分離的主題雖然講完了，但是前後端分離的內容並沒有結束，本篇將繼續前後端分離的問題，只不過這次前後端分離的講述將會圍繞著本系列的主題網站靜態化進行。在講本篇主題之前，我需要糾正一下前後端分離主題講述中會讓朋友們產生誤導的地方，這種誤導就是對時下流行的一些前後端分離方案（沒有使用nodejs的前後端分離
關於大型網站技術演進的思考（九）--網站靜態化處理--總述（1）
在儲存瓶頸的開篇我提到像hao123這樣的導航網站只要它部署的web伺服器數量足夠，它可以承載超大規模的併發訪問量，如果是一個動態的網站，特別是使用到了資料庫的網站是很難做到通過增加web伺服器數量的方式來有效的增加網站併發訪問能力的。但是現實情況是像淘寶、京東這樣的大型動態網站在承擔高併發的情況下任然能
關於大型網站技術演進的思考（十一）--網站靜態化處理—動靜分離策略（3）
前文裡我講到了網站靜態化的關鍵點是動靜分離，動靜分離是讓動態網站裡的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以後，我們就可以根據靜態資源的特點將其做快取操作，這就是網站靜態化處理的核心思路。由此可見，網站靜態化處理的核心就是動靜分離和快取兩大方面，上篇我簡單講述了動靜整合
關於大型網站技術演進的思考（十八）--網站靜態化處理—反向代理（10）
反向代理也是一種可以幫助實現網站靜態化的重要技術，今天我就來講講反向代理這個主題。那麼首先我們要了解下什麼是反向代理。和反向代理相對應的是正向代理，正向代理也就是我們常說的代理服務，正向代理是非常常見的，例如在某些公司裡我們想使用網際網路，那麼我們就得在瀏覽器裡設定一個代理伺服器，通過代理伺服器我們才能正
關於大型網站技術演進的思考（十二）--網站靜態化處理—快取（4）
上篇我補充了下SSI的知識，SSI是一個十分常見的技術，記得多年前我看到很多入口網站頁面的字尾是.shtml，那麼這就說明很多入口網站都曾經使用過SSI技術，其實現在搜狐網站也還在用shtml，如下圖所示： 由此可見SSI在網際網路的應用還是非常廣泛的。其實網際網路很多網頁如果我們按照動靜分離
關於大型網站技術演進的思考（五）--存儲的瓶頸（5）
做了 技術分享 表數 例子 執行 同時 設備 系統重啟 拆分 原引：http://www.cnblogs.com/sharpxiajun/p/4265853.html 上文裏我遺留了兩個問題，一個問題是數據庫做了水平拆分以後，如果我們對主鍵的設計采取一種均勻分布的策略，那麽
關於大型網站技術演進的思考（二）--儲存的瓶頸（2）
上篇裡我講到某些網站在高併發下會報出503錯誤，503錯誤的含義是指網站服務端暫時無法提供服務的含義，503還表達了網站服務端現在有問題但是以後可能會提供正常的服務，對http協議熟悉的人都知道，5開頭的響應碼錶達了服務端出現了問題，在我們開發測試時候最為常見的是500錯誤，500代表的含義是服務端程式出
關於大型網站技術演進的思考（六）--儲存的瓶頸（6）
在講資料庫水平拆分時候，我列出了水平拆分資料庫需要解決的兩個難題，它們分別是主鍵的設計問題和單表查詢的問題，主鍵問題前文已經做了比較詳細的講述了，但是第二個問題我沒有講述，今天我將會講講如何解決資料表被水平拆分後的單表查詢問題。 要解決資料表被水平拆分後的單表查詢問題，我們首先要回到問題的源頭，我們
關於大型網站技術演進的思考（一）--儲存的瓶頸（1）
前不久公司請來了位網際網路界的技術大牛跟我們做了一次大型網站架構的培訓，兩天12個小時資訊量非常大，知識的廣度和難度也非常大，培訓完後我很難完整理出全部聽到的知識，今天我換了個思路是回味這次培訓，這個思路就是通過本人目前的經驗和技術水平來思考下大型網站技術演進的過程。 首先我們要思考一個問題，什麼樣
關於大型網站技術演進的思考（四）--儲存的瓶頸（4）
如果資料庫需要進行水平拆分，這其實是一件很開心的事情，因為它代表公司的業務正在迅猛的增長，對於開發人員而言那就是有不盡的專案可以做，雖然會感覺很忙，但是人過的充實，心裡也踏實。 資料庫水平拆分簡單說來就是先將原資料庫裡的一張表在做垂直拆分出來放置在單獨的資料庫和單獨的表裡後更進一步的把本來是一個整體
關於大型網站技術演進的思考（七）--儲存的瓶頸（7）
本文開篇提個問題給大家，關係資料庫的瓶頸有哪些？我想有些朋友看到這個問題肯定會說出自己平時開發中碰到了一個跟資料庫有關的什麼什麼問題，然後如何解決的等等，這樣的答案沒問題，但是卻沒有代表性，如果出現了一個新的儲存瓶頸問題，你在那個場景的處理經驗可以套用在這個新問題上嗎？這個真的很難說。 其實不管什麼
關於大型網站技術演進的思考（五）--儲存的瓶頸（5）
上文裡我遺留了兩個問題，一個問題是資料庫做了水平拆分以後，如果我們對主鍵的設計採取一種均勻分佈的策略，那麼它對於被水平拆分出的表後續的查詢操作將有何種影響，第二個問題就是水平拆分的擴容問題。這兩個問題在深入下去，本系列就越來越技術化了，可能最終很多朋友讀完後還是沒有找到解決實際問題的啟迪，而且我覺得這些問
關於大型網站技術演進的思考（三）--儲存的瓶頸（3）
儲存的瓶頸寫到現在就要進入到深水區了，如果我們所做的網站已經到了做資料庫垂直拆分和水平拆分的階段，那麼此時我們所面臨的技術難度的挑戰也會大大增強。 這裡我們先回顧下資料庫的垂直拆分和水平拆分的定義： 垂直拆分：把一個數據庫中不同業務單元的資料分到不同的資料庫裡。 水平拆分：是根據一定的規
關於大型網站技術演進的思考（十三）--網站靜態化處理—CSI（5）
講完了SSI，ESI，下面就要講講CSI了 ，CSI是瀏覽器端的動靜整合方案，當我文章發表後有朋友就問我，CSI技術是不是就是通過ajax來載入資料啊，我當時的回答只是說你的理解有點片面，那麼到底什麼是CSI技術了？這個其實要和動靜資源整合的角度來定義。 CSI技術其實是在頁面進行動靜分離後，將頁面