最近研究TP框架，就在網上下載了一個開源的TP框架的商城系統源碼DSmall商城系統，剛好這家的商城源碼又支持集羣部署，這邊就立馬試驗了下，以下是思路。
Thinkphp默認各類緩存都是以文件緩存的，改的話在配置文件裏改
'DATA_CACHE_TYPE' => 'File', // 數據緩存類型,支持:File|Db|Apc|Memcache|Shmop|Sqlite|Xcache|Apachenote|Eaccelerator
S數據緩存與F快速緩存最大的區別是:S能設置緩存有效時間，來刪除自動緩存數據
而F不能設置只能強制刪除
F('data',NULL);S同理一樣強制刪S('data',NULL)除
查詢緩存cache默認是true即開啓了緩存的
注意：當向數據庫發送不同數據庫時，會產生不同的查詢緩存文件，
M('admin')->cache()->where()->select();
M('admin')->cache()->where()->select();若像數據庫發送相同同數據庫時只產生一條查詢緩存文件，
M('admin')->cache()->where()->select();
M('admin')->cache()->where()->find();
處理高併發解決方案：
當我們網站訪問量大了的時候，解決卡頓問題，
方法1：可以從數據庫着手，運用主從式分佈式數據庫分配用戶請求數據庫地址，（上了百萬級同理），
假如在線用戶有10w人平均
每一個人1秒鐘向數據庫發送3條數據庫那麼就有30萬數據發送數據庫，
SQL的量可能會非常巨大，所以有必要設置下緩存的隊列長度，例如，我們希望SQL解析緩存不超過5000條記錄，可以設置：
- 'DB_SQL_BUILD_LENGTH' => 5000, // SQL緩存的隊列長度
- 然後分配到各個數據中從而減輕了服務器的壓力
方法二 從服務器端運用nginx配置服務器，（負載均衡）具體有待完善
方法3假如有100000用戶同時在我們p2p平臺借款(其中可能會出現一小部分用戶卡
頓借款失敗)，爲了解決其中出現的的問題，
我們可以設置兩個線程：
1.主線程正常執行所有用戶的請求
2.把所有用戶全部放到事務隊列處理，副線程只用來—>讀事務隊列的結果集
負載均衡
原理：根據用戶的http請求計算出一個真實的web服務器地址，並將該web服務器地址寫入http重定向響應中返回給瀏覽器，由瀏覽器重新進行訪問。
優點：比較簡單
缺點：瀏覽器需要零次請求服務器才能完成一次訪問，性能較差。
http重定向服務器自身的處理能力可能成爲瓶頸。
使用http302響應重定向，有可能使搜索引擎判斷爲SEO作弊，降低搜索排名。
【協議層】dns域名解析負載均衡
原理：在DNS服務器上配置多個域名對應IP的記錄。例如一個域名www.baidu.com對應一組web服務器IP地址，域名解析時經過DNS服務器的算法將一個域名請求分配到合適的真實服務器上。如圖：
優點：將負載均衡的工作交給了DNS，省卻了網站管理維護負載均衡服務器的麻煩，同事許多DNS還支持基於地理位置的域名解析，將域名解析成距離用戶地理最近的一個服務器地址，加快訪問速度嗎，改善性能。
缺點：目前的DNS解析是多級解析，每一級DNS都可能化緩存記錄A，當摸一服務器下線後，該服務器對應的DNS記錄A可能仍然存在，導致分配到該服務器的用戶訪問失敗。
DNS負載均衡的控制權在域名服務商手裏，網站可能無法做出過多的改善和管理。
不能夠按服務器的處理能力來分配負載。DNS負載均衡採用的是簡單的輪詢算法，不能區分服務器之間的差異，不能反映服務器當前運行狀態，所以其的負載均衡效果並不是太好。
可能會造成額外的網絡問題。爲了使本DNS服務器和其他DNS服務器及時交互，保證DNS數據及時更新，使地址能隨機分配，一般都要將DNS的刷新時間設置的較小，但太小將會使DNS流量大增造成額外的網絡問題。
【協議層】反向代理負載均衡
原理：反向代理處於web服務器這邊，反向代理服務器提供負載均衡的功能，同時管理一組web服務器，它根據負載均衡算法將請求的瀏覽器訪問轉發到不同的web服務器處理，處理結果經過反向服務器返回給瀏覽器。如圖：
例如：瀏覽器訪問請求的地址是反向代理服務器的地址114.100.80.10，反向代理服務器收到請求，經過負載均衡算法後得到一個真實物理地址10.0.03，並將請求結果發給真實無服務，真實服務器處理完後通過反向代理服務器返回給請求用戶。
優點：部署簡單，處於http協議層面。
缺點：使用了反向代理服務器後，web 服務器地址不能直接暴露在外，因此web服務器不需要使用外部IP地址，而反向代理服務作爲溝通橋樑就需要配置雙網卡、外部內部兩套IP地址。
【網絡層】IP負載均衡
原理：在網絡層通過修改目標地址進行負載均衡。
用戶訪問請求到達負載均衡服務器，負載均衡服務器在操作系統內核進程獲取網絡數據包，根據算法得到一臺真實服務器地址，然後將用戶請求的目標地址修改成該真實服務器地址，數據處理完後返回給負載均衡服務器，負載均衡服務器收到響應後將自身的地址修改成原用戶訪問地址後再講數據返回回去。類似於反向服務器負載均衡。
優點：在響應請求時速度較反向服務器負載均衡要快。
缺點：當請求數據較大（大型視頻或文件）時，速度較慢。
【鏈路層】數據鏈路層負載均衡
原理：在數據鏈路層修改Mac地址進行負載均衡。
負載均衡服務器的IP和它所管理的web 服務羣的虛擬IP一致；
負載均衡數據分發過程中不修改訪問地址的IP地址，而是修改Mac地址；
通過這兩點達到不修改數據包的原地址和目標地址就可以進行正常的訪問。
優點：不需要負載均衡服務器進行地址的轉換。
數據響應時不需要經過負載均衡服務器。
缺點：負載均衡服務器的網卡帶寬要求較高。
目前連路程負載均衡是特別常見的一種手段，典型的產品有LVS（Linux Virtual Server）。