1. JMeter單機產生的壓力不足，你會采用哪些具體的方法來解決這個問題？並且說明采用這個方法和工具的原因是什么？
答案一：https://blog.csdn.net/dboyII/article/details/80517830
JMeter集群測試架構
JMeter支持以集群的方式進行壓力測試。一台機器資源有限，如果可以在多台機器上同時發出測試請求，則壓測並發量可以增加很多，不用局限於一台機器的限制。JMeter采用控制機(Controller，或Master)-代理機（Agent，或Slave）的模式組成集群測試架構。控制機與代理機是一對多的關系，控制機上配置代理機的地址列表，以JMeter客戶端的方式運行，將腳本遠程發送給代理機執行，代理機上JMeter以Server的方式運行，代替控制機執行腳本，發送壓測請求給測試機。如果壓測腳本上ThreadGroup的並發用戶數是10，那么在有三個JMeter代理機的集群中，最后壓到測試機上的並發用戶數將是30，以此類推，如果壓測腳本中規定並發量是100qps，那么最終壓到測試機上的並發請求將是300qps。代理機上執行測試請求之后，會將統計信息回傳給控制機，由控制機在界面或者終端統一顯示當前的測試匯總。
答案二：
分布式壓測我理解的就是有一台主控機和幾台壓力機。主控機通過遠程控制壓力機啟動測試，來實現系統不同級別訪問量情況下的性能驗證。
1、分布式測試中，選擇一台作為管理機（Contorller），其他的機器作為測試執行的代理機（Agent）；
2、執行測試時，由Contorller通過命令行將測試腳本發給Agent，然后Agent執行測試（不需要啟動GUI），同時將測試結果發送給Contorller；
3、測試完成，可以在Contorller上的監聽器里面看到Agent發來的測試結果，結果為多個Agent測試結果匯總而成
為什么要使用分布式壓測：
按照一般的壓力機配置，jmeter的GUI模式下（Windows），最多支持500左右的模擬請求線程，再大的話，容易造成卡頓、無響應等情況，這是限於jmeter其本身的機制和硬件配置。
有時候為了盡量模擬業務場景，需要模擬大量的並發請求，這個時候單台壓力機就顯得有心無力。針對這個情況，jmeter的解決方案是支持分布式壓測，即將大量的模擬並發分配給多台壓力機，來滿足這種大流量的並發請求場景
2. 基於線上正在運行的產品進行壓力測試，會遇到什么具體問題，怎么解決？最好能舉例子
https://www.sohu.com/a/275662999_371153
1、線上壓測時間選擇
線上壓測有一個核心原則，就是不能影響真實用戶的使用。因此時間都是選擇每天業務最低峰，一般都是在0:00-6:00之間，這樣對系統的影響最小，發出通告，進行壓力測試。
2、線上壓測數據准備
線上壓測不能使用真實的用戶數據，一般都是提前准備一批線上壓測專用賬號。這些賬號往往都比較特殊，比如用戶id都以xx開始，或者用戶id的長度都是多少位等。根據業務不同，其他可能還需要一些業務數據。
如果涉及到一些金錢的操作，比如發短信，提前把開關關閉。否則后果很嚴重（別問我怎么知道的）
3、線上壓測報備和預案
a> 壓測前一定下報備，通知相關的責任人，如運維、DBA、研發、運營、測試團隊等
b> 各團隊必須有指定人員現場支持，出現緊急情況便於及時處理
c> 對業務系統壓測前，要和開發和運維團隊做好預案，比如系統宕機后，怎么恢復
d> 如果壓測涉及到寫庫操作的，一定提前做好數據清理方案
4、線上壓測執行策略
a> 起始並發一定要小一些，防止系統性能不好，直接崩潰
b> 壓測時間不宜過長，除特殊場景外，一般3-5分鍾即可
c> 壓測時系統要做系統全鏈路監控，一旦出現異常情況，如機器負載高、報錯率上升等，應立即停止壓測，排查問題。
5、 數據清理
壓測結束后，要根據提前制定的數據清理方案，將壓測產生的垃圾數據清理掉，比如執行SQL。
6、會遇到的問題，
1、有安全機制，無法饒過，需要加一些白名單請求
2、沒有大量的真是用戶數據去模擬
3.服務器以及系統響應慢怎么定位
一般從三個方面定位問題，服務器，代碼，數據庫
1、我們公司產品使用阿里雲服務器和香港代理服務器，首先排查阿里雲服務器，阿里服務器有自己的監控面版。
第一步：登錄后台服務器/監控平台，查看系統資源是否達到上限，例如：CPU、內存、磁盤、I/O、網絡帶寬等，
如果是這些問題，先將這些問題逐一解決：
如果是CPU的問題，則需要查看一下CPU占比比較高的進程，然后使用jstack命令生成進程的堆棧信息，看是否發生頻繁Full GC，如果是的話，還需要看一下內存快照，分析一下內存情況（可以使用java自帶的或第三方工具）；如果是磁盤空間滿了，及時清理磁盤；如果是帶寬問題，聯系網絡工程師解決。如果以上這些問題都沒有，則進行第二步。
第二步：檢查應用服務器（Jboss/Tomcat）的線程池配置是否合理，看一下請求的排隊現象是否嚴重，如果嚴重則需要重新設置合理的線程池。同樣，檢查一下數據庫的連接池設置是否合理，增大連接池設置，同時檢查一下是否有慢sql，如果有慢sql，則進行優化（優化方案是查看執行計划，設置合理的索引等）。
第三步：查看訪問慢的服務的調用鏈，查看一下調用鏈中的每一步響應時間是否合理，如果不合理，則聯系相關系統的負責人進行排查和解決。
第四步：檢查web服務器的請求日志，看一下是否存在Doss攻擊，如果有Doss攻擊，則將攻擊者的IP添加到防火牆的黑名單里。