C1.大規模Web服務的開發定位
一.小規模服務和大規模服務的區別:
1.保證可擴展性，負載均衡的必要性:
1). 對於大規模訪問量: 用橫向擴展（增加服務器數量，廉價）
2).用戶請求如何分配：負載均衡
3).數據同步
4).網絡延遲
2.保證冗餘性
二.應對大規模數據量:數據處理流程
1)磁盤--->內存--->CPU緩存(指令)--->CPU
2)數據量小時，內存就能完成所有的處理
C2.大規模數據處理入門
一.大規模數據處理的感覺:
記錄數以千萬爲單位，數據大小爲幾GB到幾百個GB。數據規模到了這種程度，漫不經心的查詢根本無法返回結果。(select)
二.大規模數據處理的難點:內存和磁盤
1.難點爲無法在內存中計算
1) 大數據無法存儲在內存中計算，必須搜索磁盤的數據
2) 磁盤十分緩慢，I/O十分耗時。(a.磁盤搜索是物理過程，內存是電子產品。b.數據可能散落在磁盤各處. c.內存到CPU總線的速度7.5GB/S,磁盤58MB/S。傳輸時間長)
2.操作系統層加速原理:
操作系統將連續的數據放在同一處。然後在讀取數據時並不是逐個字節讀取，而是一次讀取4KB左右
3.只有一臺服務器性能被發揮到了極致，多態服務器負載均衡纔有意義
三.可擴展性要點: CPU負載/IO負載
1.Web應用程序的三層結構:
代理服務器 --- (負載均衡) --- 應用服務器(CPU負載,負責計算，可橫向擴展，做同樣的事情) ----- 數據庫(I/O負載，緩存，橫向擴展有難度，數據同步)
四.處理大規模數據的基礎知識:
1.處理大規模數據的重點
1) 能在內存中完成多少(減少尋道次數/實現分佈式)
2) 能應對數據量增加的算法和數據結構(查找算法..)
3) 數據壓縮，信息搜索技術
C3.操作系統的緩存和分佈式(減少IO負載)
一. 頁面緩存:
1. 虛擬內存: 內存不夠，將硬盤等作爲虛擬內存，有自己的連續的邏輯地址，對應着真正的可能不連續的物理地址。這樣時進程不需要考慮需要的內存位於什麼地方，只知道是連續的
2.操作系統以頁面(4kb)爲單位分配分配物理內存並管理，這樣一次不是一個字節一個字節讀，而是一個頁面一個頁面讀了
3. Linux的頁面緩存:
1) 過程: 操作系統從硬盤中讀出4kb(一頁)的塊 -----> 將內容放到內存中 ----> 操作系統將該內存的地址(邏輯地址)告訴進程 ---> 進程訪問該內存進行操作 ---> 操作完成後該內存不會被釋放而是保留下來(頁面緩存) ---> 下次訪問同一塊硬盤時直接讀內存(所以第二次比第一次更快)
2) 虛擬文件系統(VFS): 硬件 --- 設備驅動程序 --- 文件系統 --- 虛擬文件系統(管理文件系統上的函數,頁面緩存) --- 操作系統
3) Linux 以頁面爲單位緩存磁盤: 頁面是虛擬內存的最小單位。更新策略是放棄最老的保留最近的
4) Linux 只要有空閒內存就會緩存，沒有空閒內存供緩存使用時，才用心緩存替換舊緩存
5) 先讀取一次磁盤纔會有頁面緩存，所以服務器重啓後無緩存 ，要先讀一遍再放到生產環境中
4.降低I/O負載的策略:
1)以緩存爲前提降低I/O負載的策略
a. 如果內存大於數據規模(包括將磁盤文件壓縮) ----> 全部緩存
b. 考慮經濟成本的平衡性
2) 當數據規模大於內存無法全部緩存
a.首先考慮擴展到多臺服務器，對應用服務器(CPU負載,負責計算，可橫向擴展，做同樣的事情) 有效，數據庫(I/O負載，橫向擴展有難度，數據同步)無效
二.利用局部性的分佈式: 根據訪問模式進行分散，增加緩存容量
1. 例：熱門鏈接與用戶自定義書籤表，分配到兩個不同的數據庫服務器上,互不干擾。從系統整體上看，放入內存的數據量就增加了。
2. 分區方式:在局部性的基礎實現分散，將一個數據庫分割到多臺服務器上
1) 以表爲單位進行分割: 經常同時被訪問的表放在同一臺server上
2) 從數據中間分割: 根據數據的特點將一張表分割成多個小表。 a-d,e-m....
3) 根據用途將系統分成島: 將容易緩存的請求和不容易緩存的請求放在不同的島上處理，前者讓緩存內容更穩定，後者會打亂前者的緩存
用戶請求/ API/ 爬蟲 ---- 用User-Agent(Http) 和URL進行分割
C4. 數據庫的橫向擴展策略
一. 分佈式 MySQL應用的三大要點
1. 操作系統緩存：準備容納大量數據的表,要設計的緊湊一些，讓記錄儘可能的小
2. 索引
1) B樹: 向B樹中插入數據需要遵循一定的規則，藉助此規則，搜索時只需沿着一部分節點前進，就能自然的找到要搜索的數據。搜索時，對子節點的搜索次數最多隻相當於樹的高度
a.B樹與二叉樹的區別: B樹可以使各節點的大小，二叉樹只能有一個節點； B樹使節點爲4kb，每個節點保存在一個塊內，將尋道次數降低到與節點訪問次數相等。操作系統會一次性將同一節點內的數據全部讀入內存，無需尋道就可以搜索.
b. B+樹爲了在數據庫中保存數據而進一步優化數據結構: 各個節點中只有指向子節點的指針，實際數據保存在最後的葉節點中 O(n) ---> O(logn)
c. MySQL建立索引的數據結構就是B+樹
d. 規模越大，有無索引的差別就越大。 數據有1000條左右時，利用樹搜索的額外開銷反而越大
3. 以橫向擴展爲前提的設計
1) n臺AP(服務器) ---> 負載均衡器 ---> n臺MySQL slave ---> 一臺MySQL master.
2) slave會根據master更新，查詢發給slave，更新發給master
3) 查詢好擴展，增加slave服務器就可以
4) master不好擴展，可以通過表分割或者更換實現方法來解決
5) 表分割:
a. MySql不支持位於不同服務器表的join查詢，所以join查詢基本上只有保證了對象表以後不會分割在不同服務器上的前提才能使用
b. 避免使用join, 用where .... in ...
6) 冗餘化: 至少有四臺: 三臺 slave, 一臺壞掉，一臺運行，一臺給另一臺備份，並且如果master壞了，一個slave轉換成master
C5. 大規模數據處理"實踐入門"
一. 根據特殊用途創建索引: 超出RDBMS能力時
1.架構:
1) 數據庫--定期取-->索引服務器<----->應用服務器
2) 不在應用服務器cache索引因爲應用服務器內存不夠，不適合使用大規模索引
C6. 壓縮編程
一. 壓縮
1.壓縮基礎: 經常出現的符號分配短編碼，很少出現的分配長編碼
2.哈夫曼編碼:從頭開始分析各個文字符號的出現頻率，求出概率分佈之後，再據此生成最佳符號
C7. 算法實用化
一.複雜度
O(logn)比O(n)快很多
二.關鍵字鏈接: 寫博客時部分關鍵字自動加上鍊接
1.編譯正則表達式的處理：
1)預先創立，緩存在磁盤中
2.用正則表達式進行模式匹配：
1) Trie樹:
以前綴搜索，一個字母一個字母匹配，這樣不會走重複的路
a --- b ---c
--- e
----c ----d
2) 數據量小時採用簡單方法反而效果更好:
三.機器學習和大規模數據:
1. 文檔分類: 某篇文檔D, 該文檔所屬概率最高的分類C
貝葉斯算法: P(C|D) = P(D|C)P(C)|P(D), 因爲只需要求出概率的最大者，所以不需要計算出來。所以只需要關心P(D|C) 與P(C)
P(C) 是某個分類出現的概率，只需事先保存學習數據被保存到各個分類中的次數，即可計算
P(D|C) 可以近似看成其中的單詞 P(W1|C)P(W2|C)P(W3|C)P(W4|C)P(W5|C);這樣將文檔D分割成單詞，求出每個單詞被分類到各類別的次數
提示正確: http://andynjux.blogbus.com/logs/48219445.html
C9. 挑戰全文搜索技術
一. 挑戰全文搜索技術：contians
1. 之前是用關係型數據庫: 新文章先提出所有的關鍵詞與文章的關係在數據庫存起來，但是當數據多的時候就有問題
2. 根據實際用途建立搜索
二.搜索系統的架構
1.所需步驟:
1). 爬行: 存儲搜索的目標文檔
2).存儲:將文檔保存(分佈式數據庫)
3).建立索引
4).搜索:
5).評分:
6).結果顯示
2.種類:
1) grep類型:
將搜索對象文檔全部讀出，然後找匹配，可保證實時性，無遺漏，但數據量太大
2)後綴類型
用可搜索的形式將文檔全部存儲到內存中(Trie)
3) 逆向索引類型
搜索之前要預先創建逆向索引，實時性不好
3.逆向索引內部結構：dictionary + postings
a.建立索引:
I.找單詞: 英文有空格隔開，中日文靠詞典或者靠語素分析推測
搜索遺漏: 詞性變化
* 可用n-gram切分的結果作爲term,用同樣的規則切分查詢.但過濾要花很多時間
評判標準: 查全率和查準率
b. 根據詞直接查: 單詞1 --> 文檔編號1 文檔編號2...
單詞2 ---> 文檔編號1 文檔編號4...
C11.保證冗餘性和系統的穩定化
一.應該在極限的70%左右運行
二.提高效率，硬件利用率:虛擬化
1.CPU空閒---->WEB服務器
2.I/O資源空閒--->數據庫服務器
3.內存資源空閒--->緩存服務器
