面試官：你好。
候選人：你好。
（面試官在你的簡歷上面看到了，呦，有個亮點，你在專案裡用過mq，比如說你用過activemq）
面試官：你在系統裡用過訊息佇列嗎？（面試官在隨和的語氣中展開了面試）
候選人：用過的（此時感覺沒啥）
面試官：那你說一下你們在專案裡是怎麼用訊息佇列的？
候選人：巴拉巴拉，「我們啥啥系統傳送個啥啥訊息到佇列，別的系統來消費啥啥的。比如我們有個訂單系統，訂單系統每次下乙個新的訂單的時候，就會傳送一條訊息到activemq裡面去，後台有個庫存系統負責獲取訊息然後更新庫存。」
（部分同學在這裡會進入乙個誤區，就是你僅僅就是知道以及回答你們是怎麼用這個訊息佇列的，用這個訊息佇列來幹了個什麼事情？）
面試官：那你們為什麼使用訊息佇列啊？你的訂單系統不傳送訊息到mq，直接訂單系統呼叫庫存系統乙個介面，咔嚓一下，直接就呼叫成功，庫存不也就更新了。
候選人：額。。。（楞了一下，為什麼？我沒怎麼仔細想過啊，老大讓用就用了），硬著頭皮胡言亂語了幾句。
（面試官此時聽你楞了一下，然後聽你胡言亂語了幾句，開始心裡覺得有點兒那什麼了，懷疑你之前就壓根兒沒思考過這問題）
面試官：那你說說用訊息佇列都有什麼優點和缺點？
（面試官此時心裡想的是，你的mq在專案裡為啥要用，你沒怎麼考慮過，那我稍微簡單點兒，我問問你訊息佇列你之前有沒有考慮過如果用的話，優點和缺點分別是啥？）
候選人：這個。。。（確實平時沒怎麼考慮過這個問題啊。。。胡言亂語了）
（面試官此時心裡已經更覺得你這哥兒們不行，平時都沒什麼思考）
面試官：kafka、activemq、rabbitmq、rocketmq都有什麼區別？
（面試官問你這個問題，就是說，繞過比較虛的話題，直接看看你對各種mq中介軟體是否了解，是否做過功課，是否做過調研）
候選人：我們就用過activemq，所以別的沒用過。。。區別，也不太清楚。。。
（面試官此時更是覺得你這哥兒們平時就是瞎用，根本就沒什麼思考，覺得不行）
面試官：那你們是如何保證訊息佇列的高可用啊？
候選人：這個。。。我平時就是簡單走 api 呼叫一下，不太清楚訊息佇列怎麼部署的。。。
面試官：如何保證訊息不被重複消費啊？如何保證消費的時候是冪等的啊？
候選人：啥？（mq不就是寫入&消費就可以了，哪來這麼多問題）
面試官：如何保證訊息的可靠性傳輸啊？要是訊息丟失了怎麼辦啊？
候選人：我們沒怎麼丟過訊息啊。。。
面試官：那如何保證訊息的順序性？
候選人：順序性？什麼意思？我為什麼要保證訊息的順序性？它不是本來就有順序嗎？
面試官：如何解決訊息佇列的延時以及過期失效問題？訊息佇列滿了以後該怎麼處理？有幾百萬訊息持續積壓幾小時，說說怎麼解決？
候選人：不是，我這平時沒遇到過這些問題啊，就是簡單用用，知道mq的一些功能。
面試官：如果讓你寫乙個訊息佇列，該如何進行架構設計啊？說一下你的思路。
候選人：。。。。。我還是走吧。。。。
這其實是面試官的一種面試風格，就是說面試官的問題不是發散的，而是從乙個小點慢慢鋪開。比如說面試官可能會跟你聊聊高併發話題，就這個話題裡面跟你聊聊快取、mq等等東西，由淺入深，一步步深挖。
其實上面是乙個非常典型的關於訊息佇列的技術考察過程，好的面試官一定是從你做過的某乙個點切入，然後層層展開深入考察，乙個接乙個問，直到把這個技術點刨根問底，問到最底層。
訊息佇列面試場景
面試官 你好。候選人 你好。面試官在你的簡歷上面看到了，呦，有個亮點，你在專案裡用過mq，比如說你用過activemq 面試官 你在系統裡用過訊息佇列嗎？面試官在隨和的語氣中展開了面試 候選人 用過的 此時感覺沒啥 面試官 那你說一下你們在專案裡是怎麼用訊息佇列的？候選人 巴拉巴拉，我們啥啥系統傳送...
計畫測試場景
目標 1 測試終端使用者響應時間 多長時間完成業務處理 2 定義最優硬體配置 哪種硬體配製提供最優的效能 3 檢查穩定性 系統可以執行多長時間不會發生出錯或失敗 4 檢查硬體或軟體公升級 公升級如何影響效能和穩定性 5 評價新產品 選擇哪種伺服器硬體或軟體 6 測量系統能力 在不降低效能下系統能夠處...
效能測試場景
執行緒數 需要設定的併發使用者數 併發使用者數 受cpu的主頻 分配的記憶體大小 作業系統 允許開啟檔案數量 開放的埠數量 的影響，一台電腦，大概能支援 1500併發使用者數以內 http協議 ramp up時間 在多長時間內啟動所有的執行緒。注意 只是說明，在第n秒結束時，會產生m個併發使用者數，...