寫在前面:
這本書陸陸續(xù)續(xù)讀了兩周的 還只讀了三分之一
也就300多頁的書 就是很久沒有學(xué)習過了
失去學(xué)習的能力了
所以現(xiàn)在試試新的方法
每本書寫個讀書筆記
然后限個時 效果好就推廣 效果不好就想辦法優(yōu)化
如果今天的derrick和昨天的derrcik一樣
那么今天還有什么意義
Life is too short, do not live the same day twice.
本書閱讀時間 20180527-痰驱？
網(wǎng)站基礎(chǔ)知識
網(wǎng)站的架構(gòu)及其演變過程
- 其實TCP/IP參考的模型也可以看作一種協(xié)議。BA結(jié)構(gòu)中TCP/IP模型中的網(wǎng)絡(luò)接入層沒有相應(yīng)協(xié)議瞳浦，網(wǎng)際互聯(lián)層時IP協(xié)議担映，傳輸層是TCP協(xié)議，應(yīng)用層是HTTP協(xié)議
- 緩存和頁面靜態(tài)化
數(shù)據(jù)量大這個問題最直接的解決方案就是使用緩存叫潦，緩存就是將數(shù)據(jù)從數(shù)據(jù)庫中獲取的結(jié)果暫時保存起來蝇完，在下次使用的時候無需重新到數(shù)據(jù)庫中獲取，這樣可以大大降低數(shù)據(jù)庫的壓力
緩存的使用方式可以分為通過程序直接保存到內(nèi)存中使用和使用緩存框架兩種方式矗蕊。程序直接操作主要是使用Map短蜕，尤其是ConcurrentHashMap，而常用的緩存框架有Ehcashe傻咖、Memcache和Redis等朋魔。緩存使用過程中最重要的問題什么時候創(chuàng)建緩存和緩存的失效機制。緩存可以在第一次獲取的時候創(chuàng)建也可以在程序啟動和緩存失效之后立即創(chuàng)建卿操，緩存的失效可以定期失效警检，也可以在數(shù)據(jù)發(fā)生變化的時候失效孙援，如果按數(shù)據(jù)發(fā)生變化讓緩存失效，還可以分粗粒度失效和細粒度失效扇雕。
緩存中空數(shù)據(jù)的管理方法
如果緩存是在第一次獲取的時候創(chuàng)建的赃磨，那么在使用緩存的時候最好將沒有數(shù)據(jù)的緩存使用特定的類型值來保存，因為這種方式下如果從緩存中獲取不到數(shù)據(jù)就會從數(shù)據(jù)庫中獲取洼裤，如果數(shù)據(jù)庫中本來就沒有相應(yīng)的數(shù)據(jù)就不會創(chuàng)建緩存，這樣將每次都會查詢數(shù)據(jù)庫溪王。比如有個專門保存文章評論的緩存腮鞍，不同的評論按照不同文章的ID來保存，如果有一篇文章本來就沒有評論莹菱，那么就沒有相應(yīng)的緩存或者緩存的值為null移国，這樣程序在每次調(diào)用這篇文章的評論時都會查詢數(shù)據(jù)庫道伟。這就沒起到緩存的作用蜜徽，我們可以創(chuàng)建一個專門的類（如NoComment）來保存沒有評論的緩存拘鞋，這樣程序從緩存中查詢后就可以知道是還沒有創(chuàng)建緩存還是本來就沒有評論內(nèi)容灰蛙。
- 跟緩存相似的另外一種技術(shù)叫頁面靜態(tài)化摩梧，它在原理上跟緩存非常相似仅父，緩存是將從數(shù)據(jù)庫獲取到的數(shù)據(jù)（當然也可以是別的任何可以序列化的東西）保存起來驾霜，而頁面靜態(tài)化是將程序最后生成的頁面保存起來买置，使用頁面靜態(tài)化就不需要每次調(diào)用都重新生成頁面了蓉冈，這樣不但不要查詢數(shù)據(jù)庫寞酿，而且連應(yīng)用程序處理都省了拉馋，所以頁面靜態(tài)化同時對數(shù)據(jù)量大和并發(fā)量高兩大問題都有好處煌茴。（后續(xù)看看頁面靜態(tài)化怎么實現(xiàn) 相關(guān)的模板技術(shù) Freemarker Velocity 相關(guān)名詞了解一哈）
-
分離活躍數(shù)據(jù)
之前看到是緩存熱點數(shù)據(jù) 我們進一步想 就可以延伸出在數(shù)據(jù)庫層面分離活躍數(shù)據(jù)和非活躍數(shù)據(jù)（這種思路了解一哈） - 數(shù)據(jù)庫集群（讀寫分離）的作用是將多個請求分配到不同服務(wù)器處理，從而減輕單臺服務(wù)器的壓力，而分布式數(shù)據(jù)庫是解決單個請求本身就非常復(fù)雜的問題，它可以將單個請求分配到多個服務(wù)器處理，使用分布式后的每個節(jié)點還可以同時使用讀寫分離褐桌，從而組成多個節(jié)點群。（我“天真”地感覺又要集群又要分布式對架構(gòu)是一種考驗，后續(xù)了解一哈）
- 集群和分布式處理都是使用多臺服務(wù)器處理的，集群是每臺服務(wù)器都具有相同的功能（就是gx的廊坊+馬駒橋機房嘛哈哈哈哈）浩蓉，處理請求時調(diào)用哪臺服務(wù)器都可以，主要起分流的作用宾袜，分布式時將不同的業(yè)務(wù)放到不同的服務(wù)器中捻艳，處理一個請求可能需要用到多臺服務(wù)器，這樣就可以提高一個請求的處理速度庆猫，而且集群和分布式也可以同時使用认轨。
- 集群又分靜態(tài)資源集群和應(yīng)用程序集群。應(yīng)用程序集群因為需要用到一些緩存的數(shù)據(jù)月培，所以就存在同步的問題嘁字，其中最重要的就是Session恩急，Session同步也是應(yīng)用程序集群中非常核心的一個問題。Session同步有兩種處理方式：一種是在Session發(fā)生變化后自動同步到其他服務(wù)器（tomcat就是默認這種方式）纪蜒，另外一種方式是用一個程序統(tǒng)一管理Session（可以使用專門的服務(wù)器安裝Memecached等高效的緩存程序來統(tǒng)一管理Session衷恭，然后再應(yīng)用程序中通過重寫Request并覆蓋getSession方法來獲取指定服務(wù)器中Session）。
另外我也想到一種思路可以簡單地解決Session同步的問題纯续，Session需要同步的本質(zhì)原因就是要使用不同的服務(wù)器給同一個用戶提供服務(wù)随珠，如果均衡負載在分配請求時可以將同一個用戶（如按IP）分配到同一臺服務(wù)器進行處理就不需要Session同步了，二期這種方法一般也不會對負載均衡帶來太大的問題猬错，如果考慮到穩(wěn)定性牙丽，為了防止有服務(wù)器宕機后丟失數(shù)據(jù)還可以將集群的服務(wù)器分成多個組，然后在小范圍的組內(nèi)同步Session兔魂。
//一些后續(xù)的問題，如果用戶切換了IP登錄該怎么處理举娩，對頻繁切換ip的用戶有沒有什么策略析校，以及傳統(tǒng)方式和這種思路的優(yōu)劣，他們各自適合什么類型的應(yīng)用及用戶群
-
反向代理
反向代理指的是客戶端直接訪問的服務(wù)器并不真正提供服務(wù)铜涉，它從別的服務(wù)器獲取資源然后將結(jié)果返回該用戶的
反向代理服務(wù)器主要有三個作用：1.作為前端服務(wù)器跟實際處理請求的服務(wù)器（如tomcat集成）2.可以用作負載均衡 3.轉(zhuǎn)發(fā)請求 -
CDN
就是一種特殊的集群頁面緩存服務(wù)器智玻，和普通的多臺頁面緩存服務(wù)器比主要是它存放的位置是分步在全國各地的，當接受到用戶的請求后會將請求分配到最合適的CDN服務(wù)器節(jié)點獲取數(shù)據(jù) - 底層的優(yōu)化
我們前面講到的所有的架構(gòu)都是建立在最前面介紹的基礎(chǔ)架構(gòu)之上的芙代，而且很多地方都需要通過網(wǎng)絡(luò)傳輸數(shù)據(jù)吊奢，如果可以加快網(wǎng)絡(luò)傳輸?shù)乃俣龋菍屨麄€系統(tǒng)從根本上得到改善纹烹。網(wǎng)絡(luò)傳輸數(shù)據(jù)都是按照各種協(xié)議進行的页滚，不過協(xié)議并不是不可以改變，Google就邁出了這一步铺呵，它制定了Quic裹驰、Spdy等協(xié)議來傳輸數(shù)據(jù)，Quic比TCP效率高而且不UDP安全片挂，Spdy協(xié)議比現(xiàn)有HTTP協(xié)議的基礎(chǔ)上增加了很多新特性幻林，提高了傳輸?shù)男剩贿^有些特性已經(jīng)包含到了HTTP/2協(xié)議中音念，而且Google也已經(jīng)放棄了Spdy而使用HTTP/2了沪饺。 - 小結(jié)
網(wǎng)站架構(gòu)的整個演變過程主要是圍繞大數(shù)據(jù)和高并發(fā)兩個問題展開的，解決的方案主要分為使用緩存和使用多資源兩種類型闷愤。多資源主要指多存儲（包括多內(nèi)存）整葡、多CPU和多網(wǎng)絡(luò)，對于多資源來說又可以分為單個資源處理一個完整請求和多個資源合作處理一個請求兩種類型肝谭，如多存儲和多CPU中的集群和分布式掘宪，多網(wǎng)絡(luò)中的CDN和靜態(tài)資源分離蛾扇。理解了整個思路之后就抓住了架構(gòu)演變的本質(zhì)，二期自己可能還可以設(shè)計出更好的架構(gòu)魏滚。
常見的協(xié)議和標準
- 三次握手和四次揮手
理解這兩個過程需要理解TCP中的兩個序號和三個標志位的含義
seq ack ACK SYN FIN（這個可以后續(xù)詳細分析） - DDOS攻擊中的SYN flood攻擊
兩次握手成功后故意不握第三次镀首，這時服務(wù)端就會認為是第二次握手的數(shù)據(jù)在傳輸過程中丟失了，會重新發(fā)送第二次握手鼠次，默認情況會一直發(fā)五次更哄。
對于這種攻擊的一種應(yīng)對方法是設(shè)置第二次請求的重發(fā)次數(shù)（tcp_synack_retries），不過重發(fā)的次數(shù)太小也可能導(dǎo)致正常的請求中因為網(wǎng)絡(luò)沒有收到第二次握手而連接失敗的情況腥寇，具體設(shè)置為多少合適成翩，還需要根據(jù)實際情況判斷，當然如果資金充足也可以使用硬防赦役。（什么是硬防） - TCP與UDP
用于傳輸層的協(xié)議除了TCP還有UDP麻敌，它們的區(qū)別主要是TCP是有連接的，UPD是沒有連接的掂摔，也就是說TCP協(xié)議是在溝通好后才會傳數(shù)據(jù)术羔，而UDP協(xié)議是拿到地址后直接傳了，這樣產(chǎn)生的結(jié)果就是TCP協(xié)議的傳輸速度更快乙漓。TCP就像打電話级历，需要先撥通對方號碼才能通信，而UDP就像是使用對講機叭披，拿起來就可以直接講話寥殖。 -
HTTP協(xié)議
HTTP協(xié)議是應(yīng)用層的協(xié)議，在TCP/IP協(xié)議接收到數(shù)據(jù)之后需要通過HTTP協(xié)議來解析才可以使用涩蜘。就像過去發(fā)電報一樣嚼贡，電報機就相當于Socket，負責選好發(fā)是送的目標并將內(nèi)容發(fā)過去同诫，但是直接發(fā)過去的數(shù)據(jù)“滴滴滴”并不能直接使用编曼，還需要解碼（在發(fā)送前需要編碼）后才能用，電報機中的編碼和解碼就相當于網(wǎng)絡(luò)傳輸協(xié)議中的HTTP協(xié)議剩辟。
HTTP協(xié)議中的報文結(jié)構(gòu)非常重要掐场。HTTP報文中分為請求報文（request message）和響應(yīng)報文（response message）兩種類型，這兩種類型都包括三部分：首行贩猎、頭部和主體熊户。請求報文的首行是請求行，包括方法（請求類型）吭服、URL和HTTP版本三項內(nèi)容嚷堡，響應(yīng)請求的首行是狀態(tài)行，包括HTTP版本、狀態(tài)碼和簡短原因三項內(nèi)容蝌戒，其中原因可有可無串塑。（就想起了controller里面那些操作 還有什么“HTTP接口”）
請求報文中的方法指GET、HEAD北苟、POST桩匪、PUT、DELETE等類型友鼻，響應(yīng)報文中的狀態(tài)碼就是Response中的status傻昙，一共可以分為5類：
1XX:信息性狀態(tài)碼
2XX:成功狀態(tài)碼，如200表示成功
3XX:重定向狀態(tài)碼彩扔，如301表示重定向
4XX:客戶端錯誤狀態(tài)碼妆档，如404表示沒找到請求的資源（有興趣的453了解一哈）
5XX:服務(wù)端錯誤狀態(tài)碼，如500表示內(nèi)部錯誤
- Servlet
Servlet是J2EE的標準之一（標準比協(xié)議多了強制性的意義）通過前面的TCP/IP協(xié)議虫碉、HTTP協(xié)議已經(jīng)可以得到數(shù)據(jù)了贾惦，Servlet的作用是對接收到的數(shù)據(jù)進行處理并生成要返回給客戶端的的結(jié)果，這就像電報中接收到電報并翻譯成明文后還需要有人來決策并作出回復(fù)內(nèi)容一樣敦捧。
Servlet制定了Java中處理web請求的標準纤虽，我們只需要按照標準規(guī)定的去做就可以了。當然绞惦，規(guī)范和標準都不能干活，需要相應(yīng)的Servlet容器洋措，比如tomcat济蝉。
DNS的設(shè)置
- qq能上網(wǎng) 瀏覽器不行
這個問題經(jīng)常遇到 其實就是因為有些程序（如qq）是直接使用IP連接的，而瀏覽器需要DNS服務(wù)菠发，這種就是DNS服務(wù)出了問題王滤。
java中socket的用法
- Java中的Socket
分為普通Socket和NioSocket - 普通Socket的用法
Socket分為ServerSocket和Socket兩大類，ServerSocket用于服務(wù)端滓鸠，可以通過accept方法監(jiān)聽請求雁乡，監(jiān)聽到請求后返回Socket，Socket用于完整的數(shù)據(jù)傳輸糜俗，客戶端直接使用Socket發(fā)起請求并傳輸數(shù)據(jù)踱稍。（后續(xù)可以單獨開個坑 寫一下這個的實現(xiàn)） - NioSocket的用法
主要是了解三個概念 Buffer Channel Selector
Buffer中的四個重要屬性 capacity limit position mark（兩兩對應(yīng)）
自己動手實現(xiàn)HTTP協(xié)議
這章后面單獨開個坑
詳解Servlet
http://www.reibang.com/p/90e460893e53
tomcat分析
俯視Spring MVC
Spring MVC初體驗
創(chuàng)建Spring MVC之器
Spring MVC之用
Spring MVC組件分析
總結(jié)與補充
r
