它們都是衡量軟體好壞的標準
1 1.qps：Queries Per Second，每秒查詢率，一臺伺服器每秒能夠響應的查詢次數，每秒的響應請求數 2 -如何估算自己專案的QPS？--取決於：併發量和平均響應時間 3 0.1s * 10 =1s 4 -併發量：同一時刻，能併發幾個，假設併發量是1 5 -平均響應時間是0.1 6 -qps是10 7 8 9 2. TPS：Transactions Per Second，是每秒處理的事務數，包括一條訊息入和一條訊息出，加上一次使用者資料庫訪問 10 TPS 的過程包括：客戶端請求服務端、服務端內部處理、服務端返回客戶端。 11 例如，訪問一個 Index 頁面會請求伺服器 3 次，包括一次 html，一次 css，一次 js，那麼訪問這一個頁面就會產生一個T，產生三個Q（代表3次請求） 12 13 14 15 3.併發量 16 系統同時處理的請求或事務數，可以直接理解為：系統同時處理的請求數量 17 QPS = 併發量 / 平均響應時間 18 併發量 = QPS * 平均響應時間 19 例如當前系統QPS為1w，每個請求的響應時間都是2s，那麼併發量就是2w 20 21 22 4.PV 23 PV（Page View）：頁面訪問量，即頁面瀏覽量或點選量，使用者每次重新整理即被計算一次。可以統計服務一天的訪問日誌得到---> 24 比如咱麼路飛專案--》記錄課程訪問量 25 查詢課程詳情介面中---》加入 redis自增（course_view） 26 27 28 5.UV 29 UV（Unique Visitor）：獨立訪客，統計1天內訪問某站點的使用者數。可以統計服務一天的訪問日誌並根據使用者的唯一標識去重得到 30 31 32 33 6. DAU(日活) 34 DAU(Daily Active User)，日活躍使用者數量。常用於反映網站、app、網遊的運營情況。 35 DAU通常統計一日（統計日）之內，登入或使用了某個產品的使用者數（去除重複登入的使用者），與UV概念相似 36 37 38 39 7.MAU(月活) 40 MAU(Month Active User)：月活躍使用者數量，指網站、app等去重後的月活躍使用者數量
什麼是介面冪等性問題，如何解決？
1 # 冪等：冪等（idempotent、idempotence）是一個數學與計算機學概念 2 -一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同 3 -介面冪等性：無論呼叫多少次，產生的效果是一樣的 4 -get 獲取資料天然冪等 5 -put 修改資料天然冪等 6 -修改庫存（數字加減）：不冪等 7 -delete 刪除 天然冪等 8 -post 新增資料，會出現不冪等的情況，要把它做成冪等性的 9 10 # 解決方案： 11 # token機制 12 1、下單介面的前一個介面，只要一訪問，後端生成一個隨機字串，存到redis中，把隨機字串返回給前端 13 2、然後呼叫業務介面請求時，把隨機字串攜帶過去，一般放在請求頭部 14 3、伺服器判斷隨機字串是否存在redis中，存在表示第一次請求，然後redis刪除隨機字串,繼續執行業務。 15 4、如果判斷隨機字串不存在redis中，就表示是重複操作，直接返回重複標記給client，這樣就保證了業務程式碼，不被重複執行 16 17 18 # 樂觀鎖機制---》更新的場景中 19 update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1 20 -扣減id為2的商品庫存---》進入到扣減頁面---》資料庫中查一下這個資料的version號[假設是10] 21 -訪問扣減庫存介面---》帶著之前的version來了 22 -後端的sql如下： 23 update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 10 24 -第一次可以順利扣減 25 -第二次：帶的版本號還是10---》sql執行失敗了--->扣減不了了 26 27 28 # 唯一主鍵 29 這個機制是利用了資料庫的主鍵唯一約束的特性，解決了在insert場景時冪等問題。但主鍵的要求不是自增的主鍵，這樣就需要業務生成全域性唯一的主鍵 30 31 # 唯一ID(unique) 32 呼叫介面時，生成一個唯一id，redis將資料儲存到集合中（去重），存在即處理過 33 前端來到下單頁面，前端生成唯一id，只要下單，帶著這個唯一id到後端---》後端取出來--》存到reids中--》繼續後續操作---》帶著同樣的id過來，redis中有了，這個就不繼續執行了 34 35 # 防重表 36 使用訂單號orderNo做為去重表的唯一索引，把唯一索引插入去重表，再進行業務操作，且他們在同一個事務中。這個保證了重複請求時，因為去重表有唯一約束，導致請求失敗，避免了冪等問題。 37 這裡要注意的是，去重表和業務表應該在同一庫中，這樣就保證了在同一個事務，即使業務操作失敗了，也會把去重表的資料回滾。這個很好的保證了資料一致性。 38 39 # 前端： 40 按鈕只能點選一次 41 42 43 --------------------------------------------------------------------------------- 44 補充：悲觀鎖樂觀鎖 45 46 悲觀鎖和樂觀鎖是多執行緒併發程式設計中的兩種思想，主要用於解決在併發環境下對共享資源的訪問和修改問題。以下是關於這兩種鎖的詳細解釋： 47 48 悲觀鎖 49 定義： 50 51 悲觀鎖假定在修改資料的時候，其他執行緒很可能也會同時修改該資料，導致資料的不一致。因此，它採取一種保守的策略，即在修改資料之前先對資料進行加鎖，阻止其他執行緒對該資料進行訪問或修改。 52 實現原理： 53 54 悲觀鎖最典型的實現方式是使用資料庫的排他鎖（Exclusive Lock）或資料庫的行級鎖。 55 當一個執行緒嘗試修改資料時，它會先嚐試為該資料加上排他鎖。如果加鎖成功，則可以進行修改；如果加鎖失敗（表示該資料正在被其他執行緒修改），則當前執行緒需要等待或丟擲異常。 56 在整個修改過程中，資料都會被鎖定，直到事務完成並提交後才會釋放鎖。 57 特點： 58 59 以更多時間的代價來保證資料的完整性。 60 效率低，但安全性高。 61 樂觀鎖 62 定義： 63 64 樂觀鎖則假定在修改資料時，其他執行緒一般不會同時修改該資料，因此它不會立即對資料進行加鎖。而是在資料提交更新時，才會正式對資料的衝突與否進行檢測。 65 實現原理： 66 67 樂觀鎖的實現主要基於版本號（Version）或時間戳（Timestamp）機制。 68 在每次更新資料時，都會先獲取當前資料的版本號或時間戳，並在更新時檢查該版本號或時間戳是否與資料庫中的版本號或時間戳一致。 69 如果一致，則表示資料沒有被其他執行緒修改過，可以執行更新操作，並將版本號或時間戳進行自增；如果不一致，則表示資料已被其他執行緒修改，更新操作會失敗。 70 特點： 71 72 效率高，但安全性相對較低。 73 適用於多讀少寫的場景。 74 總結 75 悲觀鎖和樂觀鎖各有優缺點，適用於不同的場景。悲觀鎖適用於寫操作頻繁的場景，可以確保資料的一致性和安全性；而樂觀鎖則適用於讀操作遠多於寫操作的場景，可以提高系統的併發效能和吞吐量。在選擇使用哪種鎖時，需要根據具體的應用場景和需求進行權衡。