摘自於某位大神ppt
一、技術架構的演變及使用場景
tip: 中數字是指併發量
二、架構優化之路
三、現主要針對負載均衡問題進行討論：
負載均衡問題：
使用者的請求由誰來**到具體的應用伺服器
有什麼**的演算法
應用伺服器如何返回使用者的請求
使用者如果每次訪問到的伺服器不一樣，那麼如何維護sesion的一致性
負載均衡解決方案：
針對第乙個問題：使用者請求由誰來**到具體的應用伺服器
http重定向
dns網域名稱解析
反向**技術
ip層負載均衡
資料鏈路層負載均衡
**演算法
rr（輪詢）
wrr（加權輪詢）
sh（源位址雜湊）
dh（目標位址雜湊）
lc（最少鏈結）
wlc（加權最少鏈結）
sed（最短期望延遲）
nq（永不排隊）
lblc（基於區域性性的最少連線）
lblcr（帶賦值的基於區域性性的最少連線）
集群模式相關問題(以下三種模式，具體了解可根據這個鏈結 額 研究的話我就算了，我只負責記錄)
nat（網路位址轉換）
drtun
針對之上提到的**演算法和集群模式，我們只需要了解即可，因為已有現有伺服器本身就支援，所以我們可根據自己的需要，選擇適合自己的就好。
如何保證session共享
四、a) 架構優化之路-帶負載均衡的架構
b) 架構優化之路-用搜尋引擎緩解讀庫的壓力
c) 架構優化之路-用快取緩解讀庫的壓力
d) 架構優化之路-資料庫水平拆分與垂直拆分
例子如下（從網上盜用）：
摘：資料庫水平拆分和垂直拆分區別（以mysql為例）
案例：簡單購物系統暫設涉及如下表：
1.產品表（資料量10w，穩定）
2.訂單表（資料量200w，且有增長趨勢）
3.使用者表 （資料量100w，且有增長趨勢）
以mysql為例講述下水平拆分和垂直拆分，mysql能容忍的數量級在百萬靜態資料可以到千萬
垂直拆分：
解決問題：
表與表之間的io競爭
不解決問題：
單錶中資料量增長出現的壓力
方案：把產品表和使用者表放到乙個server上
訂單表單獨放到乙個server上
水平拆分：
解決問題：
單錶中資料量增長出現的壓力
不解決問題：
表與表之間的io爭奪
方案：使用者表通過性別拆分為男使用者表和女使用者表
訂單表通過已完成和完成中拆分為已完成訂單和未完成訂單
產品表 未完成訂單放乙個server上
已完成訂單表盒男使用者表放乙個server上
女使用者表放乙個server上(女的愛購物 哈哈)
e) 架構優化之路-應用拆分
f) 架構優化之路-引入訊息中介軟體
五、開發框架介紹：
常用開發框架說明：
ssm springmvc spring mybatis
ssh struts2+spring+hibernate
SQL Azure 伺服器端架構
sql azure伺服器端架構 sql azure 的訂閱模型決定了各個訂閱之間的資料是隔離的。實際上，sql azure 平台將使用者的資料儲存在多個 sql azure 物理伺服器上，並且使用 sql server 的複製功能 replicas 實現了高可用性的要求。如圖6 2 所示，在 sql...
socket伺服器端
伺服器 include winsock2.h include string.h include stdio.h include time.h include stdarg.h include stdlib.h pragma comment lib,ws2 32 void errexit const ...
kerberos伺服器端
1.安裝tcl wget tar zvxf tcl8.5.12 src.tar.gz cd tcl8.5.12 cd unix configure make make install 3.解壓 tar xvf krb5 1.10.3 signed.tar tar zvxf krb5 1.10.3.t...