php高併發

<?php
/**
* Created by PhpStorm.
* User: weisheng
* Date: 2018/3/26
* Time: 20:14
*/

/*
* 高併發和大流量解決方案考點
* 1.高併發架構相關概念
* 2.高併發解決方案
*/

/*
* 高併發相關概念
* 1.併發：在操做系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一時刻點上只有一個程序在處理機上運行。
* 上面的定義明顯不是咱們一般所言的併發，在互聯網時代，所講的併發、高併發，一般是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。
* 2.高併發：一般若是一個系統的日PV在千萬以上，有多是一個高併發的系統。
*
* 高併發具體該關心啥？
* 1.QPS：每秒鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數（指HTTP請求）不等於併發鏈接數 併發鏈接數是系統同時處理的請求數量
* 2.吞吐量：單位時間內處理的請求數量（一般由QPS與併發數覺定）
* 3.響應時間：從請求發出到收到響應所花費的時間。例如系統處理一個HTTP請求須要100ms,這個100ms就是系統的響應時間
* 4.PV：綜合瀏覽量（Page View),即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問頁面的數量，同一我的瀏覽同一頁面記一次PV
* 5.UV：獨立訪客，即必定時間範圍內相同訪客屢次訪問網站，只計算爲一個獨立訪客。
* 6.帶寬：計算帶寬大小需關注兩個指標，峯值流量和頁面的平均大小
* 7.日網站帶寬=PV/統計時間（換算到秒）*平均頁面大小（單位KB）* 8
* (總PV數*80%）/（6小時秒數*20%）=峯值每秒請求數（QPS) //80%的訪問量集中在20%的時間
*
* 壓力測試：利用性能測試工具 如ab 測試目標是基於URL
*
* 流量優化：防盜鏈處理，將惡意請求排除在外
* 前端優化：減小HTTP請求，添加異步請求，啓用瀏覽器緩存和壓縮，CDN加速，創建獨立的圖片服務器
* 服務端優化：頁面靜態化，併發處理，隊列處理
* 數據庫優化：數據庫緩存，分庫分表、分區操做，讀寫分離
* web服務器優化：負載均衡
*/

/*
* web資源防盜鏈
*
* 盜鏈：指在本身的頁面上展現一些並不在本身服務器上的內容，得到他人服務器上的資源地址，繞過別人的資源展現頁面，直接在本身的頁面上向最終用戶提供此內容
*
* 防盜鏈：防止別人經過一些技術手段繞過本站的資源展現頁面，盜用本站的資源，讓繞開本站資源展現頁面的資源連接失效
* 工做原理：經過Referer（請求來源）或者簽名，網站能夠檢測到目標網頁訪問的來源網頁，若是是資源文件，則能夠追蹤到顯示它的網頁地址。一旦檢測到來源不是本站即進行阻止或者返回指定頁面
*
* 防盜鏈的實現：
* Referer：Nginx模塊 ngx_http_referer_module用於阻擋來源非法的域名請求
* Nginx指令valid_referers,全局變量$invalid_referer
* valid_referers none|blocked|server_name|string...;
* none:"Referer"來源頭部爲空的狀況（合法）
* blocked:"Referer"來源頭部不爲空，可是裏面的只被代理或者防火牆刪除了，這些值都不以http://或者https://開頭
* server_name:來源referer包含server_name(容許源）
* 使用加密簽名：使用點三方模塊HttpAccessKeyModule實現Nginx防盜鏈
* accesskey on|off模塊開關
* accesskey_hashmethod md5|sha_1簽名加密方式
* accesskey_arg GET參數名稱
* accesskey_signature 加密規則
*
*/

/*
* 減小HTTP請求
* HTTP鏈接產生的開銷 解析花費時間
* 合併圖片（圖片地圖，css精靈），js,css
* 圖片使用Base64編碼減小頁面請求數:採用用Base64編碼方式將圖片直接嵌入到網頁中，而不是從外部導入
*/

/*
* 瀏覽器緩存和數據壓縮
*
* 緩存分類：
* HTTP緩存模型中，若是請求成功會有三種狀況
* 200 from cache:直接從本地緩存中獲取響應，最快速，最省流量，由於根本沒有向服務器發送請求
* 304 Not Modified:協商緩存，瀏覽器在本地沒有命中的狀況下請求頭中發送必定的檢驗數據到服務器端，若是服務器端數據沒有改變，瀏覽器從本地緩存響應，返回304 快速，發送的數據不多，只返回一些基本的響應頭信息，數據很小，不發送實際響應體
* 200 OK：以上兩種緩存都失敗，服務器返回完整響應。沒有用到緩存，相對最慢
*
* 本地緩存：若是瀏覽器認爲本地緩存能夠用，就不須要去請求服務器
* 相關Header：
* Pragma:HTTP1.0時代的遺留產物，該字段被設置爲no-cache時，會告知瀏覽器禁用本地緩存，即每次都向服務器發送請求
* Expires：HTTP1.0時代用來啓用本地緩存的字段，expires值對應一個形如Thu,31 Dec 2037 23:55:55 GMT 的格林威治時間，告訴瀏覽器緩存實現的時刻，若是還沒到該時刻，標明緩存有效，無需發送請求。瀏覽器與服務器的時間沒法保持一致，時間相差太大會影響緩存
* Cache-Control:HTTP1.1針對Expires時間不一致的解決方案，運用Cache-Control告知瀏覽器緩存過時的時間而不是時刻，及時具體時間不一致，也不影響緩存的管理
* no-store:禁止瀏覽器緩存響應
* no-cache:不容許直接使用本地緩存，先發起請求和服務器協商
* max-age=data-seconds:告知瀏覽器該響應本地緩存有效地最長期限，以秒爲單位
*
* 優先級：Pragma>Cache-Control>Expires
*
* Last-Modified:通知瀏覽器資源的最後修改時間
* If-Modified-Since:獲得資源的最後修改時間後，會將這個信息經過If-Modified-Since提交到服務器作檢查，若是沒有修改，返回304狀態碼
* ETag:HTTP1.1推出，文件的指紋標識符，若是文件內容修改，指紋會改變
* If-None-Match:本地緩存失效，會攜帶此值去請求服務器，服務端判斷該資源是否改變，若是沒有改變，直接使用本地緩存，返回304
*
*
*
* 緩存策略的選擇：
* 不變的圖像，如logo，圖標等 js、css靜態文件 可下載內容，媒體文件
* 建議使用協商緩存：HTML文件，常常修改的圖片、js、css文件
* 不建議緩存的內容：用戶的隱私內容以及常常修改的api數據接口
*
* 本地緩存配置：add_header指令：添加狀態碼爲2XX和3XX的響應頭信息
* add_header name value [always];
* 能夠設置Pragma/Expires/Cache-Control,能夠繼承
* expires指令：通知瀏覽器過時時長
* expires time 爲負值時 表示no cache max時爲10年
*
* 協商緩存： Etag指令
*
* 前端代碼和資源的壓縮：圖片壓縮、js、css等壓縮
*
*/
//$since=$_SERVER['HTTP_IF_MODIFIED_SINCE'];
//$lifetime=10;
//if(strtotime($since)+$lifetime>time()){
//
// header('HTTP/1.1 304 Not Modified');
// exit;
//}
//header('Last-Modified: ' . gmdate('D, d M Y H:i:s', time()). ' GMT');
//
//echo time();

/*
* CDN加速
* 什麼是CDN：CDN的全稱是Content Delivery Network,即內容分發網絡
* 在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡
* CDN系統可以實時地根據網絡流量和各節點的鏈接，負載情況以及到各用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務器節點上
*
* 使用CDN的優點：本地Cache加速，提升了企業站點（尤爲含有大量圖片和靜態頁面站點）的訪問速度
* 跨運營商的網絡加速，保證不一樣網絡的用戶都獲得良好的訪問質量
* 遠程訪問用戶根據DNS負載均衡技術智能自動選擇Cache服務器
* 自動生成服務器的遠程Mirror(鏡像)cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減小遠程訪問的帶寬，分擔網絡流量，減輕原站點WEB服務器負載等功能
* 普遍分佈的CDN節點加上節點之間的智能冗餘機制，能夠有效地預防黑客入侵
*
*
* CDN的工做原理：
* 傳統訪問：用戶在瀏覽器輸入域名發起請求-->解析域名獲取服務器IP地址-->根據IP地址找到對應的服務器-->服務器響應並返回數據
* 使用CDN訪問：用戶發起請求-->智能DNS的解析(根據IP判斷地理位置、接入網絡型、選擇路由最短和服務器最輕的服務器)-->取得緩存服務器IP-->把內容返回給用戶(若是緩存中有)-->向源站發起請求-->將結果返回給用戶-->將結果存入緩存服務器
*
* 應用場景：站點或者應用中有大量的靜態資源
* 大文件下載
* 直播網站
*
* 實現：BAT等都有提供CDN服務
* 可用LVS作4層負載均衡
* 可使用apache noginx
* 使用squid反向代理，或者Nginx等的反向代理
*
*/

/*
* 獨立圖片服務器的部署
*
* 獨立的必要性：分擔Web副武器的I/O負載-將耗資源的圖片服務分離出來，提升服務期的性能和穩定性
* 可以專門對服務器進行優化-爲圖片服務設置有針對性的緩存方案，減小帶寬成本，提升訪問速度
* 提升網站的可擴展性-經過增長圖片服務器，增長圖片的吞吐
*
* 採用獨立域名：同一瀏覽器下併發鏈接數有限制，突破瀏覽器鏈接數的限制
* 因爲cookie，對緩存不利，大部分Web cache都只緩存不帶cookie的請求，致使每次圖片請求都不能命中cache
*
* 獨立後的問題：
* 如何進行圖片上傳和圖片同步：
* NFS共享方式
* 利用FTP同步
*/

/*
* 動態語言靜態化
*
* 什麼是動態語言靜態化：將現有PHP等動態語言的邏輯代碼生成爲靜態HTML文件，用戶訪問動態腳本重定向到靜態HTML文件的過程 不高的頁面
*
* 爲何要靜態化：
* 緣由：1.動態腳本一般會作邏輯運算和數據查詢，訪問量越大，服務器壓力越大
* 2.訪問量大時可能會形成CPU負載太高，數據庫服務器壓力過大
* 3.靜態化能夠減低邏輯處理壓力，下降數據庫服務器查詢壓力
*
* 靜態化的實現方式：
* 使用模板引擎：可使用Smarty的緩存機制生成靜態的HTML緩存文件
* 利用ob系列的函數：ob
*/

/*
* 動態語言併發處理
*
* 進程：進程是計算機中的程序關於某數據集合上的的一次運行活動，是系統進行資源分配和調度的基本單位，是操做系統結構的基礎 進程是一個「執行中的程序」
* 進程的三態模型：多道程序系統中，進程在處理器上交替運行，狀態不斷地發生變化
* 運行、就緒、阻塞
* 線程：線程是程序中一個單一的順序控制流程。進程內有一個相對獨立的、可調度的執行單元，是系統獨立調度和分派CPU的基本單位指令運行時的程序的調度單位。在單個程序中同時運行多個線程完成不一樣的工做，稱爲多線程。
* 運行、就緒、阻塞
* 協程：協程不是進程或線程，其執行過程更相似於子例程，或者說不帶返回值的函數調用。
一個程序能夠包含多個協程，能夠對比與一個進程包含多個線程，於是下面咱們來比較協程和線程。咱們知道多個線程相對獨立，有本身的上下文，切換受系統控制；而協程也相對獨立，有本身的上下文，可是其切換由本身控制，由當前協程切換到其餘協程由當前協程來控制。

*
*線程與進程之間的區別：
* 1.線程是進程內的一個執行單元，進程內至少有一個線程，它們共享進程的地址空間，而進程有本身獨立的空間地址
* 2.進程是資源分配和擁有的單位，同一個進程內的線程共享進程的資源
* 3.線程是處理器調度的基本單位，但進程不是
* 4.兩者均可以併發執行
* 5.每一個獨立的線程有一個程序的入口，順序執行序列和程序的出口，可是線程不可以獨立執行，必須依存在應用程序中，由應用程序提供多個線程執行控制
*
* 線程與協程的區別：
* 1.一個線程能夠有多個協程，一個進程也能夠單獨有多個協程
* 2.線程是同步機制，而協程則是異步
* 3.協程能保留上一次調用時的狀態，每次過程重入時，就至關於進入上一次的調用狀態
*
* 多進程與多線程
* 多進程：同一個計算機在同一時間容許系統中兩個個或兩個以上的進程處於運行狀態，這就是多進程
* 多線程：線程就是把一個進程分爲多個片斷，每一個進程佔據一個獨立的片斷
*
*
* php併發編程實踐：
* Swoole：Swoole 使用純 C 語言編寫，提供了 PHP 語言的異步多線程服務器，異步 TCP/UDP 網絡客戶端，異步 MySQL，異步 Redis，數據庫鏈接池，AsyncTask，消息隊列，毫秒定時器，異步文件讀寫，異步DNS查詢。 Swoole內置了Http/WebSocket服務器端/客戶端、Http2.0服務器端。
除了異步 IO 的支持以外，Swoole 爲 PHP 多進程的模式設計了多個併發數據結構和IPC通訊機制，能夠大大簡化多進程併發編程的工做。其中包括了併發原子計數器，併發 HashTable，Channel，Lock，進程間通訊IPC等豐富的功能特性。
Swoole2.0 支持了相似 Go 語言的協程，可使用徹底同步的代碼實現異步程序。PHP 代碼無需額外增長任何關鍵詞，底層自動進行協程調度，實現異步。

*/

/* * 數據庫緩存 * * 什麼是數據庫緩存：MySQL等一些常見的關係數據庫的數據存儲在磁盤中，在高併發場景下，業務應用對MySQL產生的增、刪、改、查的操做形成巨大的I/O開銷和查詢壓力，這無疑對數據庫和服務器都是一種巨大的壓力，爲了解決此類問題，緩存數據庫應運而生 * 爲何要使用緩存：緩存數據是爲了減小客戶端訪問數據庫服務器進行數據查詢 * * MySQL查詢緩存：query_cache_type * * 使用Memcache緩存查詢數據： * memcache:分佈式的高速緩存系統 * 工做原理： * 工做流程： * * 使用Redis緩存： * Redis: * 工做原理： * 工做流程： * * Redis與Memcache * 性能相差不大 * Redis在2.0版本後增長了本身的VM特性，突破物理內存限制，Memcache能夠修改最大可用內存，採用LRU算法 * Redis，依賴客戶端來實現分佈式讀寫 * Memcache自己沒有數據冗餘機制 * Redis支持（快照、AOF），依賴快照進行持久化，aof加強了可靠性的同時，對性能有所影響 * */