生成唯一ID-雪花算法：https://github.com/godruoyi/php-snowflake](https://github.com/godruoyi/php-snowflake)
一、高并發(fā)的問題，我們該關(guān)心什么
1戒职、QPS :每秒鐘請求或查詢的數(shù)量（QPS 不等于并發(fā)連接數(shù) 并發(fā)連接數(shù)是系統(tǒng)同時處理請求的數(shù)量）
2、吞吐量：單位時間內(nèi)處理的請求數(shù)量（通常由QPS和并發(fā)數(shù)決定）
3森篷、響應(yīng)時間
4统舀、PV：綜合瀏覽量（Page View），即頁面瀏覽量或者點(diǎn)擊量胶背，一個訪客24小時內(nèi)訪問的頁面數(shù)量骡苞，
同一個人瀏覽網(wǎng)站的同個頁面多次刷新垂蜗，只記做一個PV
5、UV：獨(dú)立訪客（Unique Visitor）,即一定時間范圍內(nèi)相同的訪客多次訪問網(wǎng)站解幽，只計算為1個UV
6贴见、帶寬：日網(wǎng)站帶寬 = PV/統(tǒng)計時間（換算成秒）* 平均頁面大小（單位KB）* 8
7躲株、峰值的QPS ：= （總PV數(shù) * 80%）/（6小時秒數(shù) * 20%）
8片部、壓力測試：ab、wrk徘溢、http_load吞琐、Apache JMeter
二、 不同QPS下的優(yōu)化
1然爆、QPS達(dá)到100站粟，數(shù)據(jù)庫緩存、數(shù)據(jù)庫負(fù)載均衡
2曾雕、QPS達(dá)到800奴烙，如果網(wǎng)站帶寬為100M，那么帶寬就會吃完剖张。CDN加速切诀、負(fù)載均衡
3、QPS達(dá)到1000搔弄， 如果使用Memcache緩存幅虑，Memcache的悲觀鎖并發(fā)2W左右，那么內(nèi)網(wǎng)的帶寬可能以及吃完顾犹。靜態(tài)HTML緩存
4倒庵、QPS達(dá)到2000褒墨，文件系統(tǒng)訪問鎖成為了災(zāi)難，做業(yè)務(wù)分離擎宝、分布式存儲
三郁妈、優(yōu)化方案
1、流量優(yōu)化绍申。防盜鏈
2噩咪、前端優(yōu)化。減少http請求极阅、添加異步請求胃碾、開啟瀏覽器緩存和文件壓縮、CND加速涂屁、建立獨(dú)立圖片服務(wù)器书在、
3、服務(wù)端優(yōu)化拆又。頁面靜態(tài)化、并發(fā)處理（隊列栏账、異步）
4帖族、數(shù)據(jù)庫優(yōu)化。數(shù)據(jù)庫緩存挡爵、分庫分表分區(qū)竖般、讀寫分離、負(fù)載均衡
5茶鹃、web服務(wù)器優(yōu)化涣雕。負(fù)載均衡、
四闭翩、具體的優(yōu)化方案
1挣郭、防盜鏈：使用Referer請求地址判斷或者簽名
Referer nginx配置
location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$
{
valid_referers none blocked test.com *.test.com;
if($invalid_referer){
#return 403;
rewrite ^/ http://www.test.com/403.jpg;
}
}
加密簽名：使用第三方模塊HttpAccessKeyModule實(shí)現(xiàn)Nginx防盜鏈
location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$
{
accesskey on;
accesskey_hashmethod md5; #加密算法，和php的加密算法保持一直
accesskey_arg "sign"; #url請求簽名的參數(shù)名
accesskey_signatrue "mypass$remote_addr"; #加密規(guī)則 md5( 'mypass'+客服端的ip地址）疗韵；
}
2兑障、數(shù)據(jù)庫優(yōu)化
- 數(shù)據(jù)庫類型的正確選擇
- 數(shù)據(jù)表引擎的不同
InnoDB：默認(rèn)事務(wù)型引擎，性能優(yōu)秀蕉汪。
數(shù)據(jù)存儲共享表空間（索引等）,可通過配置分開
主鍵查詢性能高于其他類型的引擎
通過一些機(jī)制和工具支持真正的熱備份
支持崩潰后 的安全恢復(fù)
支持行級鎖
支持外鍵
MyISAM
支持全文索引
不支持事務(wù)和行級鎖流译，表鎖
不支持崩潰后 的安全恢復(fù)
表存儲在2個文件，MYD和MYI
查詢效果比較高
統(tǒng)計效率比較高（count）
- MySQL索引者疤，主鍵福澡、唯一索引、聯(lián)合索引 的區(qū)別驹马，以及對數(shù)據(jù)庫性能的影響
1革砸、索引對性能的影響
大大減少服務(wù)器需要掃描的數(shù)據(jù)量‘
幫助服務(wù)器避免排序和臨時表
將隨機(jī)I/O 變成順序的I/O
大大提高查詢速度
缺點(diǎn)：降低寫的速度眯搭，占用磁盤
2、索引的使用場景
對于小的表业岁，全表掃描效率更高
中大型的表鳞仙，索引非常有效
特大型的表，建立索引和使用索引代價也會提高笔时，可使用分區(qū)技術(shù)解決
3棍好、主鍵索引和唯一索引的區(qū)別
一個表只能有一個主鍵，可以有多個唯一索引
主鍵索引一定是唯一索引允耿，唯一索引不是主鍵索引
主鍵可以和外鍵構(gòu)成參照完整性約束借笙，防止數(shù)據(jù)不一致
4、索引的創(chuàng)建原則
where中的列较锡，或者連接子句中的列
索引列基數(shù)越大业稼，索引效果越好
對字符串進(jìn)行索引，應(yīng)該制定一個前綴長度蚂蕴，可以節(jié)省大量空間
根據(jù)情況創(chuàng)建復(fù)合索引低散，復(fù)合索引可以提高查詢效率
避免創(chuàng)建過多的索引，索引或占用磁盤空間骡楼，降低寫的效率
主鍵盡可能使用較短的類型熔号，比比如整型
5、索引生效
. 復(fù)合聯(lián)合索引的原則（前綴原則 ） key(a,b,c)
. 索引生效：where a=1 and b =2 and c=3
where a=1 and b=2
where a=1 其他都不生效
. ike 查詢鸟整，%不能在前引镊，可以使用全文索引
. is not null 和 is null 不走索引
. order by 加上索引
. != 索引失效
. 如果MySQL估計使用索引比全表掃描慢，會放棄使用索引
. or 前面會使用索引篮条，后面不會弟头，可以使用UNION ALL來代替
select * from temp where age=20 or age=30;不走索引，可以使用下面的代替
select * from temp where age=20
UNION ALL
select * from temp where age=30
. 列類型是字符串涉茧，查詢時一定要給值加引號赴恨，否則索引失效
.
6、SQL優(yōu)化
. 不要select *
. 謹(jǐn)慎使用模糊查詢降瞳。只有 s% （%在后面）才走索引
. 對order by 加索引
. 少用IS NULL和IS NOT NULL 不走索引 可以使用>或者<代替
. 少用!=運(yùn)算符 可以使用>和< 代替
. 少用OR嘱支； OR前面會使用索引，后面不會挣饥，可以使用UNION ALL來代替
select * from temp where age=20 or age=30;不走索引除师，可以使用下面的代替
select * from temp where age=20
UNION ALL
select * from temp where age=30
. 少用 IN 和NOT IN
select * from user where age in(20,30); 可以使用下面的代替
select * from user where age= 20
UNION ALL
select * from user where age=20
. 避免條件語句中的數(shù)據(jù)類型轉(zhuǎn)換
如果數(shù)據(jù)類型是整型，不要加引號
. 在表達(dá)式左側(cè)使用運(yùn)算符和函數(shù)會是索引失效
