建站
咨詢
售后
建站咨詢
新聞中心
系統(tǒng)架構(gòu)師思考
創(chuàng)新互聯(lián)建站主營常山網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP軟件開發(fā),常山h5成都小程序開發(fā)搭建,常山網(wǎng)站營銷推廣歡迎常山等地區(qū)企業(yè)咨詢
秒殺活動是指網(wǎng)絡(luò)商家為促銷等目的組織會網(wǎng)上限時搶購活動，這種活動具有瞬時并發(fā)量大、庫存量少和業(yè)務(wù)邏輯簡單等特點。
設(shè)計一個秒殺系統(tǒng)需要考慮的因素很多，比如對現(xiàn)有業(yè)務(wù)的影響、網(wǎng)絡(luò)帶寬消耗以及超賣等因素。本文會討論秒殺系統(tǒng)的各個環(huán)節(jié)可能存在的問題以及解決方案。
四大核心課題思考
一、JVM調(diào)優(yōu)（調(diào)優(yōu)原理，上線調(diào)優(yōu)細節(jié)，掌握基本調(diào)優(yōu)參數(shù)設(shè)置，調(diào)優(yōu)一些經(jīng)驗），GC日志分析，進一步調(diào)優(yōu)。
二、數(shù)據(jù)庫調(diào)優(yōu)（連接池調(diào)優(yōu)，數(shù)據(jù)庫常見設(shè)計調(diào)優(yōu)，緩存）。
三、多級緩存優(yōu)化（堆內(nèi)緩存，分布式緩存，openresty內(nèi)存字典， lua+redis實現(xiàn)接入層緩存）。
四、秒殺下單（高并發(fā)模式下實現(xiàn)下單操作—滿足業(yè)務(wù)需求）-- Lock鎖，AOP鎖優(yōu)化，分布式鎖優(yōu)化。
高性能架構(gòu)
以用戶為中心，提供快速的網(wǎng)頁訪問體驗。主要參數(shù)有較短的響應(yīng)時間、較大的并發(fā)處理能力、較高的吞吐量與穩(wěn)定的性能參數(shù)。
可分為前端優(yōu)化、應(yīng)用層優(yōu)化、代碼層優(yōu)化與存儲層優(yōu)化。
- 前端優(yōu)化：網(wǎng)站業(yè)務(wù)邏輯之前的部分；--- vue ,react +nodejs – 工程化。
- 瀏覽器優(yōu)化：減少HTTP請求數(shù)，使用瀏覽器緩存，啟用壓縮，CSS JS位置，JS異步，減少Cookie傳輸；CDN加速，反向代理。
- 應(yīng)用層優(yōu)化：處理網(wǎng)站業(yè)務(wù)的服務(wù)器。使用緩存，異步，集群，架構(gòu)優(yōu)化。
- 代碼優(yōu)化：多線程，資源復(fù)用（對象池，線程池等），良好的數(shù)據(jù)結(jié)構(gòu)，JVM調(diào)優(yōu)，單例，Cache等。
- 存儲優(yōu)化：緩存、固態(tài)硬盤、光纖傳輸、優(yōu)化讀寫、磁盤冗余、分布式存儲（HDFS）、NoSQL等。
總結(jié)：
①服務(wù)盡量進行拆分（微服務(wù)）---- 提高項目吞吐能力。
②盡量將請求攔截在上游服務(wù)（多級緩存）--- 90% ----> 數(shù)據(jù)庫壓力非常小，閑庭信步，數(shù)據(jù)庫架構(gòu)（主從架構(gòu)）。
③代理層：做限速，限流。
④服務(wù)層：按照業(yè)務(wù)請求做隊列的流量控制（流量削峰）。
可伸縮架構(gòu)
伸縮性是指在不改變原有架構(gòu)設(shè)計的基礎(chǔ)上，通過添加/減少硬件（服務(wù)器）的方式，提高/降低系統(tǒng)的處理能力。
- 應(yīng)用層：對應(yīng)用進行垂直或水平切分。然后針對單一功能進行負載均衡（DNS、HTTP[反向代理]、IP、鏈路層）。
- 服務(wù)層：與應(yīng)用層類似。
- 數(shù)據(jù)層：分庫、分表、NoSQL等；常用算法Hash，一致性Hash。
云原生：項目運行云端，可以隨時動態(tài)擴容—K8S。
8C+16G : 2000QPS +-。
(此數(shù)字是估算結(jié)果，真實結(jié)果受到代碼編寫數(shù)據(jù)結(jié)構(gòu)，業(yè)務(wù)邏輯，架構(gòu)、rt,以現(xiàn)實測試結(jié)果)。
可擴展架構(gòu)
SOA --- 微服務(wù) --- 業(yè)務(wù)拆分模塊 --- 新業(yè)務(wù)需求 --- 根據(jù)新業(yè)務(wù)需求創(chuàng)建新模塊服務(wù)。
可以方便地進行功能模塊的新增/移除，提供代碼/模塊級別良好的可擴展性。
- 模塊化、組件化：高內(nèi)聚，低耦合，提高復(fù)用性，擴展性。
- 穩(wěn)定接口：定義穩(wěn)定的接口，在接口不變的情況下，內(nèi)部結(jié)構(gòu)可以“隨意”變化。
- 設(shè)計模式：應(yīng)用面向?qū)ο笏枷耄瓌t，使用設(shè)計模式，進行代碼層面的設(shè)計。
- 消息隊列：模塊化的系統(tǒng)，通過消息隊列進行交互，使模塊之間的依賴解耦。
- 分布式服務(wù)：公用模塊服務(wù)化，提供其他系統(tǒng)使用，提高可重用性，擴展性。
安全架構(gòu)
對已知問題有有效的解決方案，對未知/潛在問題建立發(fā)現(xiàn)和防御機制。對于安全問題，首先要提高安全意識，建立一個安全的有效機制，從政策層面，組織層面進行保障，比如服務(wù)器密碼不能泄露，密碼每月更新，每周安全掃描等。
以制度化的方式，加強安全體系的建設(shè)。同時，需要注意與安全有關(guān)的各個環(huán)節(jié)。安全問題不容忽視，包括基礎(chǔ)設(shè)施安全，應(yīng)用系統(tǒng)安全，數(shù)據(jù)保密安全等。
基礎(chǔ)設(shè)施安全：
硬件采購，操作系統(tǒng)，網(wǎng)絡(luò)環(huán)境方面的安全。一般采用正規(guī)渠道購買高質(zhì)量的產(chǎn)品，選擇安全的操作系統(tǒng)，及時修補漏洞，安裝殺毒軟件防火墻。防范病毒，后門。設(shè)置防火墻策略，建立DDOS防御系統(tǒng)，使用攻擊檢測系統(tǒng)，進行子網(wǎng)隔離等手段。
應(yīng)用系統(tǒng)安全：
在程序開發(fā)時，對已知常用問題，使用正確的方式，在代碼層面解決掉。防止跨站腳本攻擊（XSS），注入攻擊，跨站請求偽造（CSRF），錯誤信息，HTML注釋，文件上傳，路徑遍歷等。還可以使用Web應(yīng)用防火墻（比如：ModSecurity），進行安全漏洞掃描等措施，加強應(yīng)用級別的安全。
數(shù)據(jù)保密安全：
存儲安全（存儲在可靠的設(shè)備，實時，定時備份），保存安全（重要的信息加密保存，選擇合適的人員復(fù)雜保存和檢測等），傳輸安全（防止數(shù)據(jù)竊取和數(shù)據(jù)篡改）。
常用的加解密算法（單項散列加密[MD5、SHA]，對稱加密[DES、3DES、RC]），非對稱加密[RSA]等。
一、互聯(lián)網(wǎng)架構(gòu)演進思考
1、架構(gòu)演進
單體架構(gòu)（all in one） à水平拆分/SOA架構(gòu)à微服務(wù)架構(gòu) àkubernetes云原生架構(gòu)（微服務(wù)遷移到云原生）à ServiceMesh （服務(wù)網(wǎng)格架構(gòu)，下一代微服務(wù)架構(gòu)，云原生架構(gòu)：istio） à serverless 架構(gòu) （無服務(wù)架構(gòu)）。
企業(yè)架構(gòu)轉(zhuǎn)型：數(shù)字化轉(zhuǎn)型。
傳統(tǒng)架構(gòu)過渡到云原生架構(gòu)（容器云）。
2、 單體架構(gòu)
（1）單體架構(gòu)——所有業(yè)務(wù)都在同一個應(yīng)用中，沒有進行任何拆分。
注意：集中式架構(gòu)模式，所有的請求都集中在同一個服務(wù)上面，對服務(wù)壓力較大；因此這樣的架構(gòu)適合并發(fā)較小的架構(gòu)；同時 同一個服務(wù)器中，數(shù)據(jù)庫，項目都會搶占服務(wù)內(nèi)存，cpu資源，造成服務(wù)性能問題。
（2）單體架構(gòu)優(yōu)化。
- 應(yīng)用程序 MYSQL分離部署。
- 服務(wù)集群– 提升性能。
- 動態(tài)分離（靜態(tài)資源存儲CDN,nginx服務(wù)器）。
- 隔離術(shù)（線程池隔離，進程隔離）。
- 隊列術(shù) （blockingQueue,disruptor隊列，RocketMQ）。
- 接入層限流（openresty）, 接口限流。
- MySQL優(yōu)化（索引，緩存，表結(jié)構(gòu)，分表分庫，數(shù)據(jù)歸檔，冷熱，SQL語句優(yōu)化）。
- 引入lvs （linux virtual server）。
- DNS 解決上層流量瓶頸問題。
- 多級緩存。
（3）單體架構(gòu)流量預(yù)估（單體架構(gòu)真的不能承受億級流量？？）單體架構(gòu)：中小型企業(yè)，創(chuàng)業(yè)公司。
①傳統(tǒng)項目（并發(fā)量小，業(yè)務(wù)簡單，需求固定），項目體量比較小
②小程序
③追求極致性能的項目（業(yè)務(wù)量少）
④互聯(lián)網(wǎng)項目（中小型企業(yè)，創(chuàng)業(yè)公司）
需求：
某網(wǎng)站平均一天下單量100w單，根據(jù)100w 評估一下系統(tǒng)的流量！
用戶行為：
①產(chǎn)生的時間段：11:00 – 2:00 5:00 – 12:00 ，訂單產(chǎn)生時間段：12h。
②每下一單會發(fā)生多少個請求：50QPS x 3 = 150 QPS。
計算流量：
100w / day * 150 QPS = 1.5 億 ----- 億級流量。
計算平均每一秒QPS：
1.5億/12 h = 1250 QPS / 60min = 20W / 60s = 3400 QPS。
（4）單點架構(gòu)優(yōu)缺點。
單體架構(gòu)優(yōu)點：
①部署簡單
②開發(fā)簡單
③測試簡單
④集群簡單
⑤RT響應(yīng)時間非常快速 —— 適合一些特點的項目（極端苛刻響應(yīng)時間）。
單體架構(gòu)問題：
①流量比較集中，所有的請求都集中一個服務(wù)中，單體無法應(yīng)對
②無法實現(xiàn)敏捷開發(fā)，業(yè)務(wù)增大，代碼結(jié)構(gòu)越來越臃腫，維護變得非常困難單體架構(gòu)：war > 1G --- IBM unix 高性能服務(wù)器 64cpus, 128GB --- 1GB
③單體架構(gòu)牽一發(fā)而動全身
④擴展性差
⑤穩(wěn)定性差
3、架構(gòu)拆分
隨著業(yè)務(wù)流量增大，需求的增多，必須對架構(gòu)進行改進，就需要對項目進行業(yè)務(wù)拆分；（水平拆分，垂直拆分）。
數(shù)據(jù)庫水平拆分，垂直拆分模式：
（1）水平拆分模式。
（2）垂直拆分：SOA架構(gòu)。
4、微服務(wù)架構(gòu)
注意：微服務(wù)架構(gòu)就是水平拆分和垂直拆分的架構(gòu)結(jié)合，就是微服務(wù)架構(gòu)。
5、ServiceMesh架構(gòu)
ServiceMesh服務(wù)網(wǎng)格架構(gòu)，CNCF把ServiceMesh定義為云原生架構(gòu)，ServiceMesh落地級實現(xiàn)的成熟框架：Istio框架。
問題：為什么要是有ServiceMesh架構(gòu)？
Spring Cloud alibaba微服務(wù)架構(gòu)存在問題？
--ServiceMesh出現(xiàn)就是為了解決微服務(wù)架構(gòu)中存在一些問題？
①服務(wù)性能監(jiān)控(Zabbix,promutheus)2、服務(wù)限流(sentinel)
②服務(wù)降級(sentinel)
③服務(wù)熔斷(sentinel)
④鏈路追蹤(skywalking)
⑥日志監(jiān)控(elk)
⑦服務(wù)告警
⑧負載均衡
以上一系列的問題，作為架構(gòu)師，開發(fā)人員都需要全盤的考慮；開發(fā)微服務(wù)架構(gòu)在服務(wù)治理，服務(wù)監(jiān)控非常困難。
以上的工作和業(yè)務(wù)沒有太多的關(guān)系，但是架構(gòu)人員必須考慮，架構(gòu)，設(shè)計，因此這些配套工作都會大大降低我們的開發(fā)效率，提升開發(fā)難度，增加開發(fā)成本。
6、Serverless
Serverless架構(gòu)體系：無服務(wù)架構(gòu)，面向未來的架構(gòu)體系，從開發(fā)人員來說，不需要關(guān)心底層哪些和業(yè)務(wù)沒有關(guān)系的代碼，只需要開發(fā)業(yè)務(wù)即可。
例如：向CDN上傳圖片，視頻文件。
①不需要上傳到哪一個服務(wù)器
②不需要關(guān)心服務(wù)器是如何擴容的
這樣的概念，思想就叫做Serverless。
總結(jié)：架構(gòu)選型的時候，必須選擇企業(yè)合適的架構(gòu)，而不是采用最新架構(gòu)。
二、性能調(diào)優(yōu)思考-JVM
1、JVM的調(diào)優(yōu)思考
思考題1
項目上線后，是什么原因促使必須進行jvm調(diào)優(yōu)？
答案：調(diào)優(yōu)的目的就是提升服務(wù)性能。
（1）jvm 堆內(nèi)存空間對象太多（Java線程，垃圾對象），導(dǎo)致內(nèi)存被占滿，程序跑不動—性能嚴重下降。
調(diào)優(yōu)：及時釋放內(nèi)存
（2）垃圾回收線程太多，頻繁回收垃圾（垃圾回收線程也會占用內(nèi)存資源，搶占cpu資源），必然會導(dǎo)致程序性能下降。
調(diào)優(yōu)：防止頻繁gc。
（3）垃圾回收導(dǎo)致stw(stop the world)。
調(diào)優(yōu)：盡可能的減少gc次數(shù)。
思考題2
jvm調(diào)優(yōu)本質(zhì)是什么？
答案：jvm調(diào)優(yōu)的本質(zhì)就是（對內(nèi)存的調(diào)優(yōu)） 及時回收垃圾對象，釋放內(nèi)存空間；讓程序性能得以提升，讓其他業(yè)務(wù)線程可以獲得更多內(nèi)存空間；
思考題3
是否可以把JVM內(nèi)存空設(shè)置的足夠大（無限大），是不是就不需要垃圾回收呢？
前提條件：內(nèi)存空間被裝滿了以后，才會觸發(fā)垃圾回收器來回收垃圾。
答案：理論上是的，現(xiàn)實情況不行的！
尋址能力：
（是否有這么大的空間）。
32位操作系統(tǒng) === 4GB 內(nèi)存。
64位操作系統(tǒng) === 16384 PB 內(nèi)存空間。
Jvm堆內(nèi)存空間大小的設(shè)置：必須設(shè)置一個合適的內(nèi)存空間，不能太大，也不能太小。
問題1：考慮到尋址速度的問題，尋址一個對象消耗的時間比較長的。
問題2：一旦觸發(fā)垃圾回收，將會是一個災(zāi)難；（只能重啟服務(wù)器）。
2、JVM的調(diào)優(yōu)原則
（1） gc的時間足夠小（堆內(nèi)存設(shè)置足夠?。?/p>
垃圾回收時間足夠小，以為著jvm堆內(nèi)存空間設(shè)置小一些，這樣的話 垃圾對象尋址的時候消耗的時間就非常短，然后整個垃圾回收非常快速。
（2） gc的次數(shù)足夠少 （jvm堆內(nèi)存設(shè)置的足夠大）。
Gc次數(shù)足夠少，jvm堆內(nèi)存空間必須設(shè)置的足夠大；這樣垃圾回收觸發(fā)次數(shù)就會相應(yīng)減少。
注意：原子1 ，原則2 相互沖突的，原則1&&原則2 。需要進行balance,內(nèi)存空間既不能設(shè)置太大，也不能設(shè)置太小。
（3） 發(fā)生fullgc 周期足夠長 （最好不發(fā)生full gc）。
metaspace 永久代空間設(shè)置大小合理，metaspace一旦擴容，就會發(fā)生fullgc。
老年代空間設(shè)置一個合理的大小，防止full gc。
盡量讓垃圾對象在年輕代被回收（90%）。
盡量防止大對象的產(chǎn)生，一旦大對象多了以后，就可能發(fā)生full gc ,甚至oom。
3、JVM的調(diào)優(yōu)原理
什么是垃圾?
JVM調(diào)優(yōu)的本質(zhì)：回收垃圾，及時釋放內(nèi)存空間。
但是什么是垃圾？
在內(nèi)存中間中，哪些沒有被引用的對象就是垃圾（高并發(fā)模式下，大量的請求在內(nèi)存空間中創(chuàng)建了大量的對象，這些對象并不會主動消失，因此必須進行垃圾回收，當然Java垃圾回收必須我們自己編寫垃圾回收代碼，Java提供各種垃圾回收器幫助回收垃圾，JVM垃圾回收是自動進行的）。
一個對象的引用消失了，這個對象就是垃圾，因此此對象就必須被垃圾回收器進行回收，及時釋放內(nèi)存空間。
怎么找垃圾?
Jvm提供了2種方式找到這個垃圾對象：
（1）引用計數(shù)算法 找垃圾。
（2）根可達算法 找垃圾 hotspot 垃圾回收器都是使用這個算法。
（1）引用計數(shù)算法
引用計數(shù)算法：對每一個對象的引用數(shù)量進行一個計數(shù)，當引用數(shù)為0時，那么此對象就變成了一個垃圾對象。
存在問題：不能解決循環(huán)引用的問題，如果存在循環(huán)引用的話，無法發(fā)現(xiàn)垃圾。
這三個對象處于循環(huán)引用的狀態(tài)，引用計數(shù)都不為0，因此無法判斷這個3個對象是垃圾。
（2）根可達算法
根據(jù)根對象向下進行遍歷，如果遍歷不到的對象就是垃圾。
如何清除垃圾?
JVM提供了3種方式清除垃圾，分別是：
①mark-sweep 標記清楚算法。
②copying 拷貝算法。
③mark-compact 標記整理（壓縮）算法。
①第一種算法：mark-sweep 標記清楚算法。
①使用根可達算法找到垃圾對象，對垃圾對象進標記 （做一個標記）。
②對標記對象進行刪除（清除）。
優(yōu)點：簡單，高效。
缺點：清除的對象都不是一個連續(xù)的空間，清除垃圾后，產(chǎn)生很多內(nèi)存碎片；不利于后期對象內(nèi)存分配，及尋址。
②第二種算法：copying拷貝算法。
一開始就把內(nèi)存控制一份為2，分為2個大小相同的的內(nèi)存空間，另一半空間展示空閑：
①選擇（尋址）存活對象。
②把存活對象拷貝到另一半空閑空間中，且是連續(xù)的內(nèi)存空間。
③把存儲對象拷貝結(jié)束后，另一半空間中全是垃圾，直接清除另一半空間即可。
優(yōu)點：簡單，內(nèi)存空間是連續(xù)的，不存在內(nèi)存空間碎片。
缺點：內(nèi)存空間浪費。
③第三種算法：mark-compact標記整理（壓縮）算法。
①選擇（尋址）存活對象。
②把存活對象拷貝到另一半空閑空間中，且是連續(xù)的內(nèi)存空間。
③把存儲對象拷貝結(jié)束后，另一半空間中全是垃圾，直接清除另一半空間即可。
垃圾回收器
Java提供很多的垃圾回收器：10種垃圾回收器。
特點：
1、Serial Serial Old , parNew CMS , Parallel Scavenge Parallel Old 都屬于物理分代垃圾回收器；年輕代，老年代分別使用不同的垃圾回收器。
2、G1 在邏輯上進行分代的，進行在使用上非常方便，關(guān)于年輕代，老年代只需要使用一個垃圾回收器即可。
3、ZGC ZGC是一款JDK 11中新加入的具有實驗性質(zhì)的低延遲垃圾收集器。
4、Shenandoah OpenJDK 垃圾回收器。
5、Epsilon 是Debug使用的，調(diào)試環(huán)境下：驗證jvm內(nèi)存參數(shù)設(shè)置的可行性。
6、Serial Serial Old：串行化的垃圾回收器。
7、parNew CMS ：并行，并發(fā)的垃圾回收器。
8、Parallel Scavenge Parallel Old ：并行的垃圾回收器。
常用的垃圾回收器組合：
1、Serial + Serial Old: 串行化的垃圾回收器，適合單核心的cpu的服務(wù)情況。
2、parNew + CMS：響應(yīng)時間優(yōu)先組合。
3、Parallel Scavenge + Parallel Old ：吞吐量優(yōu)先組合。
4、g1 ：邏輯上分代的垃圾回收器組合。
4、垃圾回收器原理
Serial+Serial Old
Serial : 年輕代的垃圾回收器，單線程的垃圾回收器；Serial Old是老年代的垃圾回收器，也是一個單線程的垃圾回收器，合適單核心cpu。
注意特點：
1、stw : 當進行g(shù)c的時候，整個業(yè)務(wù)線程都會被停止，如果stw時間過長，或者stw發(fā)生次數(shù)過多，都會影響程序的性能。
2、垃圾回收器線程：多線程，單線程，并發(fā)，并行。
Parallel Scavenge + Parallel Old
Parallel Scavenge + Parallel Old :
并行的垃圾回收器；吞吐量優(yōu)先的垃圾回收器組合，是JDK8默認的垃圾回收器；問題 : 什么是并發(fā)，并行？
并發(fā)：
并行：
PS + PO 回收垃圾的時候，采用的多線程模式回收垃圾。
注意特點：
1、stw : 當進行g(shù)c的時候，整個業(yè)務(wù)線程都會被停止，如果stw時間過長，或者stw發(fā)生次數(shù)過多，都會影響程序的性能。
2、垃圾回收器線程：多線程，單線程，并發(fā)，并行。
parNew+CMS
parNew : 并行垃圾回收器，年輕代的垃圾回收器。
CMS : 并發(fā)垃圾回收器，回收老年代的垃圾。
年輕代垃圾回收器：parNew。
老年代垃圾回收器：CMS。
注意：任何的垃圾回收器都無法避免 STW ，因此jvm調(diào)優(yōu)實際上就是調(diào)整stw的時間。
G1
使用G1收集器時，它將整個Java堆劃分成約2048個大小相同的獨立Region塊，每個Region塊大小根據(jù)堆空間的實際大小。
而定，整體被控制 在1MB到32MB之間，且為2的N次冪，即1MB，2MB，4MB，8MB，16MB，32MB?？梢酝ㄟ^-XX:G1HeapRegionsize設(shè)定。
所有的Region大小相同，且在JVM生命周期內(nèi)不會被改變。
5、 內(nèi)存分代模型
通過內(nèi)存分代模型結(jié)構(gòu)：大多數(shù)對象都會在年輕代被回收掉（90%+），很多對象都在15次的垃圾回收中被回收掉了，只有超過15次還沒被回收掉的才會進入到老年代區(qū)域。
垃圾回收觸發(fā)時機：
1、ps+po : 當堆內(nèi)存被裝滿了，才會觸發(fā)垃圾回收（eden區(qū)域滿了，觸發(fā)了垃圾回收，old區(qū)域滿了，觸發(fā)垃圾回收）。
2、cms 垃圾回收器。
①JDK1.5：68% ，當eden區(qū)域裝對象達到68%時候，就會觸發(fā)垃圾回收。
②JDK1.6+ : 92%才會觸發(fā)垃圾回收器。
一個新對象被創(chuàng)建了，但是這個對象是一個大對象（查詢?nèi)恚琫den區(qū)域已經(jīng)放不下了，此時會發(fā)生什么？
6、JVM的實戰(zhàn)調(diào)優(yōu)
明確：jvm調(diào)優(yōu)本質(zhì)
1、JVM調(diào)優(yōu)本質(zhì)就是 gc , 垃圾回收，及時釋放內(nèi)存空間。
2、gc次數(shù)要少，gc時間少，防止fulllgc --- 內(nèi)存參數(shù)設(shè)置。
典型參數(shù)設(shè)置
服務(wù)器硬件配置：4cpu，8GB內(nèi)存 --- jvm調(diào)優(yōu)內(nèi)存，考慮內(nèi)存。
1、-Xmx4000m 設(shè)置JVM最大堆內(nèi)存（經(jīng)驗值：3500m – 4000m,內(nèi)存設(shè)置大小，沒有一個固定的值，根據(jù)業(yè)務(wù)實際情況來進行設(shè)置的，根據(jù)壓力測試，根據(jù)性能反饋情況，去做參數(shù)調(diào)試）。
2、-Xms4000m 設(shè)置JVM堆內(nèi)存初始化的值，一般情況下，初始化的值和最大堆內(nèi)存值必須一致，防止內(nèi)存抖動。
3、-Xmn2g 設(shè)置年輕代內(nèi)存對象（eden,s1,s2）。
4、-Xss256k 設(shè)置線程棧大小，JDK1.5+版本線程棧默認是1MB, 相同的內(nèi)存情況下，線程堆棧越小，操作系統(tǒng)創(chuàng)建的線程越多。
nohup java -Xmx4000m -Xms4000m -Xmn2g -Xss256k -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
壓力測試：查看在此內(nèi)存設(shè)置模式下性能情況：
根據(jù)壓力測試結(jié)果，發(fā)現(xiàn)JVM參數(shù)設(shè)置，和之前沒有設(shè)置吞吐能力沒有太大的變化，因為測試樣本不足以造成 gc,fullgc時間上差異。
問題：根據(jù)什么標準判斷參數(shù)設(shè)置是否合理呢？？根據(jù)什么指標進行調(diào)優(yōu)呢？1、發(fā)生幾次gc, 是否頻繁的發(fā)送gc?2、是否發(fā)生fullgc ,full gc發(fā)生是否合理3、gc的時間是否合理4、oom。
7、GC的日志輸出
輸出日志啟動指令如下所示：
nohup java -Xmx4000m -Xms4000m -Xmn2g -Xss256k -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
輸出日志指令：
-XX:+PrintGCDetails 打印GC詳細信息
-XX:+PrintGCTimeStamps 打印GC時間信息
-XX:+PrintGCDateStamps 打印GC日期的信息
-XX:+PrintHeapAtGC 打印GC堆內(nèi)存信息
-Xloggc:gc.log 把gc信息輸出gc.log文件中
執(zhí)行啟動指令后，在本地產(chǎn)生gc.log文件：
GC日志分析： 使用https://gceasy.io/導(dǎo)入gc.log 進行在線分析即可。
Gc日志分析報告：
總結(jié)：可以發(fā)現(xiàn) 業(yè)務(wù)線程執(zhí)行時間占比達到99%+，說明gc時間在整個業(yè)務(wù)執(zhí)行期間所占用的時間非常少，幾乎不會影響程序性能；導(dǎo)致業(yè)務(wù)線程執(zhí)行時間占比高的原因是：
1、程序樣本數(shù)不夠。
2、程序運行的時間不夠。
3、業(yè)務(wù)場景不符合要求（查詢沒有太多的對象數(shù)據(jù)）。
存在問題：發(fā)生full gc。
GC詳細數(shù)據(jù)分析：
fullgc頻繁發(fā)生：
查詢gc內(nèi)存模型：jstat -gcutil PID 查詢此進程的內(nèi)存模型。
Metaspace永久代空間：默認為20m（初始化大?。?；當metaspace被占滿后，就會發(fā)生擴容，一旦metaspace發(fā)生一次擴容，就會同時發(fā)送一次fullgc 。
Sun公司推薦設(shè)置：年輕代占整個堆內(nèi)存 3/8。
發(fā)現(xiàn)full gc 已經(jīng)沒有發(fā)生了。
Yong &old比例
Sun公司推薦設(shè)置：整個堆的大小=年輕代 + 老年代 + 永久代（256m）年輕代占整個堆內(nèi)存3/8 , -Xmx4000m ， 因此整個堆內(nèi)存設(shè)置大小為4000m，也就是說年輕代大小應(yīng)該設(shè)置為1.5G：
①定義年輕代：-Xmn1500m，剩下的空間就是老年代的空間。
②參數(shù)：-XX:NewRatio = 4 表示年輕代（eden ,s0,s1） 和老年代區(qū)域所占比值 1:4。
年輕代大小，老年代大小比值根據(jù)業(yè)務(wù)實際情況設(shè)置比例，（通過設(shè)置相應(yīng)的比例：減少相應(yīng)yonggc ,fullgc）。
JVM調(diào)優(yōu)的原則中：要求盡量防止fullgc的發(fā)生；因此可以把fullgc設(shè)置的稍微大一些；以為old區(qū)域裝載對象很長時間才能裝滿（或者永遠都裝不滿），發(fā)生fullgc概率就非常小。
Eden&s0&s1
官方給定設(shè)置：可以設(shè)置eden,s區(qū)域大小：8:1:1 à -XX:SurvivorRatio = 8。
此調(diào)優(yōu)的原理：盡量讓對象在年輕代被回收；調(diào)大了eden區(qū)域的空間，讓更多對象進入到eden區(qū)域，觸發(fā)gc時候，更多的對象被回收。
nohup java -Xmx4000m -Xms4000m -Xmn1500m -Xss256k -XX:MetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
可以發(fā)現(xiàn)業(yè)務(wù)占比時間發(fā)送提升，說明gc時間更少了。
總結(jié)：JVM調(diào)優(yōu)（調(diào)整內(nèi)存大小、比例） 降低 gc次數(shù)，減少gc時間，從而提升服務(wù)性能。
調(diào)優(yōu)標準：項目上線后，遇到問題，調(diào)優(yōu)。
1、gc消耗時間 –業(yè)務(wù)時間占比。
2、頻繁發(fā)生fullgc – 調(diào)優(yōu) – stw—程序暫停時間比較長，阻塞，導(dǎo)致整個程序崩潰。
3、oom --- 調(diào)優(yōu)。
8、GC組合
吞吐量優(yōu)先
并行的垃圾回收器：parallel scavenge(年輕代) + parallel old（老年代） ---- 是JDK默認的垃圾回收器。
nohup java -Xmx4000m -Xms4000m -Xmn1500m -Xss256k -XX:MetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
顯式的配置PS+PO垃圾回收器：-XX:+UseParallelGC -XX:+UseParallelOldGC。
響應(yīng)時間優(yōu)先
并行垃圾回收器（年輕代），并發(fā)垃圾回收器(老年代) ：ParNew + CMS (響應(yīng)時間優(yōu)先垃圾回收器)。
nohup java -Xmx4000m -Xms4000m -Xmn1500m -Xss256k -XX:MetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
顯式配置：parNew+CMS垃圾回收器組合：-XX:+UseParNewGC。
-XX:+UseConcMarkSweepGC。
說明：CMS只有再發(fā)生fullgc的時候才起到作用，CMS一般情況下不會發(fā)生；因此在jvm調(diào)優(yōu)原則中表示盡量防止發(fā)生fullgc; 因此CMS在JDK14被已經(jīng)被廢棄。
G1垃圾回收器是邏輯上分代模型，使用配置簡單。
nohup java -Xmx4000m -Xms4000m -Xmn1500m -Xss256k -XX:MetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.config.addition-location=application.yaml > jshop.log 2>&1 &
經(jīng)過測試，發(fā)現(xiàn)g1 gc次數(shù)減少，由原來的28次減少為21次，但是gc總時長增加很多；時間增加，以為著服務(wù)性能就沒有提升上去。
三、數(shù)據(jù)庫連接池調(diào)優(yōu)思考
1、數(shù)據(jù)庫調(diào)優(yōu)動機何在
（1）避免網(wǎng)頁出現(xiàn)錯誤。
- Timeout 5xx 錯誤。
- 慢查詢導(dǎo)致頁面無法加載。
- 阻塞導(dǎo)致數(shù)據(jù)無法提交。
（2）增加數(shù)據(jù)庫穩(wěn)定性。
- 很多的數(shù)據(jù)庫問題，都是由于低效的SQL語句造成的（寫SQL語句）。
（3）優(yōu)化用戶體驗。
- 流暢的業(yè)務(wù)訪問體驗。
- 良好的網(wǎng)站功能體驗。
2、 影響數(shù)據(jù)庫性能的因素
1、低效的SQL語句。
2、并發(fā)cpu問題（SQL語句不支持多核心的cpu并發(fā)計算，也就是說一個SQL只能在一個cpu執(zhí)行結(jié)束）3、連接數(shù)：max_connections。
4、超高cpu使用率。
5、磁盤io性能問題6、大表（字段多，數(shù)據(jù)多）。
7、大事務(wù)。
數(shù)據(jù)庫數(shù)據(jù)處理（困難）：數(shù)據(jù)庫擴容非常困難—想要通過擴容提升數(shù)據(jù)庫性能Web服務(wù)器擴容是非常簡單的。
web服務(wù)器是無狀態(tài)服務(wù)，可以隨時進行擴容；但是數(shù)據(jù)庫不能隨意進行擴容，一旦擴容就會影響數(shù)據(jù)完整性，數(shù)據(jù)一致性；項目架構(gòu)中提升性能：
1、對項目架構(gòu)、業(yè)務(wù)，緩存各方面進行優(yōu)化，真正數(shù)據(jù)庫請求比較少—減少數(shù)據(jù)庫壓力。
2、數(shù)據(jù)庫設(shè)計，架構(gòu)，優(yōu)化。
大多數(shù)企業(yè)：數(shù)據(jù)庫采用主從架構(gòu)解決問題；數(shù)據(jù)分表，分庫，數(shù)據(jù)歸檔數(shù)據(jù)，能熱分離。
3、連接池對性能樣例分析（詳細IP隱藏）
datasource:
#url: jdbc:mysql://127.0.0.1:3306/shop?useUnicode=true&characterEncoding=utf8&autoReconnect=true&allowMultiQueries=true
url: jdbc:mysql://XX.XX.XX.XX:3306/shop?useUnicode=true&characterEncoding=utf8&autoReconnect=true&allowMultiQueries=true&connectionTimeout=3000&socketTimeout=1200
網(wǎng)頁標題：基于互聯(lián)網(wǎng)架構(gòu)演進，構(gòu)建秒殺系統(tǒng)
當前URL：http://m.5511xx.com/article/djecsjg.html
