問題1：使用jmeter性能壓測，定位瓶頸代碼
步驟流程：線程組--->Http請求--->查看結果樹--->聚合報告
tips：host的文件--->優(yōu)先調用映射，減少DNS的時間
默認內嵌Tomcat配置---->參數調優(yōu)
server.tomcat.accept-count：等待隊列長度，默認100
server.tomcat.max-connections：最大可被連接數，默認10000
server.tomcat.max-threads：最大工作線程數，默認200
server.tomcat.min-spare-threads：最小工作線程數，默認10
默認配置下，連接超過10000后出現拒絕連接情況
默認配置下，觸發(fā)的請求超過200+100后拒絕處理
定制化內嵌Tomcat開發(fā)--->keepalive
keepAliveTimeOut：多少毫秒后不響應的斷開keepalive
maxKeepAliveRequests：多少次請求后keepalive斷開失效
使用WebServerFactoryCustomizer定制化內嵌tomcat配置
MySQL數據庫QPS容量問題
◆主鍵查詢：千萬級別數據=1-10毫秒
◆唯一索引查詢：千萬級別數據=10-100毫秒
◆非唯一索引查詢：千萬級別數據=100-1000毫秒
◆無索引：百萬條數據=1000毫秒+
問題2：分布式擴展
1.單機容量問題，水平擴展
- mysql數據庫開放遠端連接
- 服務端水平對稱部署
- 驗證訪問
2.使用OpenResty
使用Nginx做為靜態(tài)資源服務器+nginx反向代理負載均衡
Nginx的高性能原因：
- epoll多路復用
- master-worker模型
- 協(xié)程機制 依附于線程的內存模型，切換開銷小 遇阻塞及歸還執(zhí)行權 代碼同步無需加鎖
3.分布式會話管理
傳統(tǒng)的會話管理
基于cookie傳輸sessionid：JAVA tomcat容器session實現
基于token傳輸類似sessionid：java代碼session實現
使用redis實現分布式會話存儲
基于cookie傳輸sessionid：java tomcat容器session實現遷移到redis
基于token傳輸類似sessionid：java代碼session實現遷移到redis
問題3：查詢優(yōu)化技術
1.掌握多級緩存的定義
緩存設計
用快速存取設備
用內存將緩存推到離用戶最近的地方
臟緩存清理
2.多級緩存
1.redis緩存：單機、哨兵、集群----（注意序列化問題）
2.熱點內存本地緩存--Guava cache
- 可控制的大小和超時時間
- 可配置的lru策略
- 線程安全
3.nginx proxy cache緩存--實際效果還不如本地緩存 ，可以用shared dic （2000）
- 依靠文件系統(tǒng)存索引級的文件
- 依靠內存緩存文件地址
4.nginx lua緩存
- nginx lua掛載點---將簡單的邏輯放到Nginx中處理，避免調用java代碼 init-by_lua：系統(tǒng)啟動時調用 init-worker-by_lua：worker進程啟動時調用 setby_lua：nginx變量用復雜lua return rewrite-by_lua：重寫url規(guī)則 access_by_lua：權限驗證階段 content-by_lua：內容輸出節(jié)點
- OpenResty OpenResty由Nginx核心加很多第三方模塊組成，默認集成了Lua開發(fā)環(huán)境，使得Nginx可以作為一個Web Server使用。 借助于Nginx的事件驅動模型和非阻塞IO，可以實現高性能的Web應用程序。 OpenResty提供了大量組件如Mysql，Redis，Memcached等等使在Nginx上開發(fā)Web應用更方便更簡單。
shared dic：共享內存字典，所有worker進程可見，Iru淘汰 ---更新操作不強 （3500）
使用openresty對redis支持，可以連接到從機，只讀不寫。（3500）
問題4：靜態(tài)資源的優(yōu)化
1.靜態(tài)請求CDN
1.DNS用CNAME解析到源站
2.回源緩存設置
? cache control響應頭
- private：客戶端可以緩存
- public：客戶端和代理服務器都可以緩存
- max-age=xxx：緩存的內容將在xxx秒后失效
- no-cache：強制向服務端再驗證一次
- no-store：不緩存請求的任何返回內容
有效性驗證
- ETag：資源唯一標識
- If-None-Match：客戶端發(fā)送的匹配Etag標識符
- Last-modified：資源最后被修改的時間
- If-Modified-Since：客戶端發(fā)送的匹配資源最后修改時間的標識符
三種刷新方式
- 回車刷新或a鏈接：看cache-control對應的max-age是否仍然有效，有效則直接from cache，若cache-control中為no-cache，則進入緩存協(xié)商邏輯
- F5刷新或command+ R刷新：去掉cache-control中的max-age或直接設置max-age為0，然后進入緩存協(xié)商邏輯
- ctrl+F5或commond+shift+R刷新：去掉cache-control和協(xié)商頭，強制刷新
? CDN自定義緩存策略
- 可自定義目錄過期時間
- 可自定義后綴名過期時間
- 可自定義對應權重
- 可通過界面或api強制cdn對應目錄刷新（非保成功）
2.靜態(tài)資源部署策略
css，js，img等元素使用帶版本號部署，例如a.js？v=1.0不便利且維護困難
css，js，img等元素使用帶摘要部署，例如a.js？v=45edw存在先部署html還是先部署資源的覆蓋問題（先后問題）
css.js，img等元素使用摘要做文件名部署，例如45edw.js，新老版本并存且可回滾，資源部署完后再部署html（==好==）
對應靜態(tài)資源保持生命周期內不會變，max-age可設置的很長，無視失效更新周期
html文件設置no-cache或較短max age，以便于更新
html文件仍然設置較長的max age，依靠動態(tài)的獲取版本號請求發(fā)送到后端，異步下載最新的版本號的html后展示渲染在前端
動態(tài)請求也可以靜態(tài)化成json資源推送到cdn上 依靠異步請求獲取后端節(jié)點對應資源狀態(tài)做緊急下架處理
可通過跑批緊急推送cdn內容以使其下架等操作
3.全頁面靜態(tài)化
定義：在服務端完成html，css，甚至js的load渲染成純html文件后直接以靜態(tài)資源的方式部署到cdn上
phantomjs應用---類似于爬蟲的原理
修改需要全頁面靜態(tài)化的實現，采用initView和hasInit方式防止多次初始化
編寫對應輪訊生成內容方式
將全靜態(tài)化頁面生成后推送到cdn
問題5：交易優(yōu)化技術之緩存庫存
扣減庫存緩存化
（1）活動發(fā)布同步庫存進緩存
（2）下單交易減緩存庫存
異步同步數據庫------異步消息隊列rocketmq
分布式事務
庫存數據庫最終一致性保證
方案：
（1）引入庫存操作流水
（2）引入事務性消息機制
問題6：流量削峰技術
秒殺令牌的原理和使用方式
- 秒殺接口需要依靠令牌才能進入
- 秒殺的令牌由秒殺活動模塊負責生成
- 秒殺活動模塊對秒殺令牌生成全權處理，邏輯收口
- 秒殺下單前需要先獲得秒殺令牌
秒殺大閘的原理和使用方式
- 依靠秒殺令牌的授權原理定制化發(fā)牌邏輯，做到大閘功能
- 根據秒殺商品初始庫存頒發(fā)對應數量令牌，控制大閘流量
- 用戶風控策略前置到秒殺令牌發(fā)放中
- 庫存售馨判斷前置到秒殺令牌發(fā)放中
隊列泄洪的原理和使用方式
- 排隊有些時候比并發(fā)更高效
- 依靠排隊去限制并發(fā)流量
- 依靠排隊和下游擁塞窗口程度調整隊列釋放流量大小
本地OR分布式？
- 本地：將隊列維護在本地內存中--負載不均衡
- 分布式：將隊列設置到外部redis內
可以使用外部的分布式，如果出現了性能問題，可以使用降級策略，切換到本地。
問題7：防刷限流
為什么要進行限流？
- 流量遠比你想的要多
- 系統(tǒng)活著比掛了要好
- 寧愿只讓少數人能用，也不要讓所有人不能用
限流方案
- 限并發(fā)
- 令牌桶算法（互聯網公司常用）
- 漏桶算法
限流力度
- 接口維度
- 總維度---比接口的低20%左右
限流范圍
- 集群限流：依賴redis或其他的中間件技術做統(tǒng)一計數器，往往會產生性能瓶頸
- 單機限流：負載均衡的前提下單機平均限流效果更好
傳統(tǒng)防刷
- 限制一個會話（session_id，token）同一秒鐘/分鐘接口調用多少次：多會話接入繞開無效
- 限制一個ip同一秒鐘/分鐘接口調用多少次：數量不好控制，容易誤傷
黃牛為什么難防
- 模擬器作弊：模擬硬件設備，可修改設備信息
- 設備牧場作弊：工作室里一批移動設備
- 人工作弊：靠傭金吸引兼職人員刷單
防刷策略
1.驗證碼
2.排隊，限流，令牌均只能控制總流量，無法控制黃牛流量
3.不同端進行隔離，使用代碼混淆，HTTPs等技術
4.設備指紋
◆采集終端設備各項參數，啟動應用時生成唯一設備指紋
◆根據對應設備指紋的參數猜測出模擬器等可疑設備概率
5.憑證系統(tǒng)
◆根據設備指紋下發(fā)憑證
◆關鍵業(yè)務鏈路上帶上憑證并由業(yè)務系統(tǒng)到憑證服務器上驗證
◆憑證服務器根據對應憑證所等價的設備指紋參數并根據實時行為風控系統(tǒng)判定對應憑證的可疑度分數
◆若分數低于某個數值則由業(yè)務系統(tǒng)返回固定錯誤碼，拉起前端驗證碼驗身，驗身成功后加入憑證服務器對應分數
問題8：單點登錄
問題9：Mysql的性能優(yōu)化
1.mysql應用性能優(yōu)化拓展
通用性能優(yōu)化---緩存+異步+批處理
寫---批量寫
- Sql編譯N次和1次的時間與空間復雜度
- 網絡消耗的時間復雜度
- 磁盤尋址的復雜度
讀---索引
- 主鍵查詢千萬條記錄1-10ms
- 唯一索引千萬條記錄10-100ms
- 非唯一索引千萬條記錄100-1000ms
- 無索引百萬條記錄1000ms+
mysql單機配置性能優(yōu)化拓展
max_connection=1000
innodb _file_per_table=1
innodb_buffer_pool_size=1G
innodb_log_ file_size=256M
innodb_log_buffer_size=16M
innodb_flush_log_at_trx_commit=2（1---事務提交就刷盤）
2.mysql分布式配置性能優(yōu)化拓展
mysql主從
- 開啟bin_log
- 設置主從同步賬號，配置主從同步
3.一致性原理
- 強一致性
- 弱一致性
- 最終一致性
CAP理論
- C:一致性
- A可用性
- P:分片性
base理論
- ◆Basic available:基本可用
- ◆S.:軟狀態(tài)
- ◆E:最終一致性
作者：gsyzh
鏈接：https://juejin.im/post/5ed5adbd6fb9a047d3710da4
