網上有很多關于pos機98發卡方超時,攜程10個有效降低客戶端超時的方法的知識，也有很多人為大家解答關于pos機98發卡方超時的問題，今天pos機之家(www.shbwcl.net)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
pos機98發卡方超時
一、背景在現今的信息時代，微服務技術已成為一種重要的解決方案，微服務技術可以使系統的規模和功能變的更加靈活，從而獲得更高的可擴展性和可用性。然而，微服務調用中出現的超時問題，卻也成為系統可用性的一大隱患。超時會導致客戶端的性能下降，甚至可能無法正常工作。本文針對超時問題，提出相關的優化手段，降低微服務調用超時的風險。
1.1 誤區
當我們遇到超時或執行慢的問題時，我們往往會認為是依賴方出現了問題。
例如：訪問 Redis、DB、 RPC 接口變慢、超時，第一時間找依賴方排查問題，對方反饋的結論是，我這邊（服務端）沒有問題，請檢查一下你那邊（客戶端）是否有問題。
實際上，性能下降是一個非常復雜的問題，它可能涉及多個方面，包括服務端和客戶端。例如：代碼質量、硬件資源、網絡狀況等問題都會導致性能下降，從而引發響應慢、超時等問題。因此，我們需要全面地分析問題，找出影響性能的各種因素。
1.2 分享的目的
本文將詳細介紹我們在生產環境中遇到的慢執行和超時等問題，并提出相關的優化手段，通過優化長尾性能，降低變慢或超時的風險，提升系統的穩定性。
二、超時的分類常見的超時一般有兩類：
a. 連接超時（ConnectTimeout）：指建立網絡連接所需要的時間超出了設定的等待時間。
b. Socket 超時（SocketTimeout）：指在數據傳輸過程中，客戶端等待服務端響應的時間超出了設定的等待時間。
如下圖，①就是連接超時關注的時間，②就是 Socket 超時關注的時間，本文講解的超時為 Socket 超時。
圖1 客戶端請求過程
三、超時問題分析與優化3.1 設置合理的超時時間
根據實際情況設置合理的超時時間，避免因為超時時間設置不合理導致的接口超時。
1）分析
看下客戶端設置的超時時間是否合理。比如調用服務端 P99.9 是100ms ，客戶端設置的超時時間是 100ms ，就會有 0.1% 的請求會超時。
2）優化方案
我們在設置超時時間需要綜合考慮網絡延遲、服務響應時間、GC 等情況。
以門票活動查詢引擎為例：
核心接口：最小值（ P99.9*3 ，用戶可接受的等待時間），核心會影響到訂單，在用戶可接受范圍內盡可能出結果。非核心接口：最小值（ P99.9*1.5，用戶可接受的等待時間），非核心不影響訂單，不展示也沒關系。3.2 限流
當系統遇到突發流量時，通過限流的方式，控制流量的訪問速度，避免系統崩潰或超時。
1）分析
看下超時時間點的請求量是否有突增，比如有某些突然的活動，這個時候應用沒有提前擴容，面對突增流量會導致應用負載比較高，從而導致超時問題。
2）優化方案
評估當前應用最大可承載的流量，配置限流，維度可以是單機+集群。
單機限流：在面對突增流量時避免單機崩潰。
集群限流：在有限的資源下提供最大化的服務能力，保證系統穩定性，不會出現崩潰或故障。
3.3 提升緩存命中率
提升緩存命中率，可以提高接口的響應速度，降低接口的響應時間，從而減少超時的發生。
1）分析
分析調用鏈路，找到慢的地方對其進行優化，提升服務端的響應速度。
如下圖所示，很明顯可以看到服務端執行時間超過了客戶端配置的超時時間 200ms 導致超時。
圖2 客戶端調用服務端超時鏈路
繼續分析服務端執行鏈路，發現是因為緩存沒有命中導致的。
圖3 緩存未命中鏈路
2）優化方案
對于高并發系統來說，常見的是使用緩存來提升性能。
如下圖是之前的緩存架構，這種緩存架構有兩個風險。
a. 緩存是固定過期的，會導致某個時間大量 key 失效直接擊穿到數據庫。
b. 主動刷新機制是刪除緩存，監聽數據庫 binlog 消息刪除緩存，如果大批量刷數據會導致大量 key 失效。
圖4 固定過期+懶加載模式
針對上面的風險我們優化了緩存架構，固定過期改為主動續期緩存，主動監聽消息刷新緩存的方案，如下圖所示。
圖5 緩存前后架構對比
3）效果
緩存命中率提升到 98% 以上，接口性能（RT）提升 50% 以上。
圖6 處理性能提升50%
這個緩存優化方案在我們團隊之前寫的一篇文章《1分鐘售票8萬張！門票搶票背后的技術思考》中有詳細的介紹，具體細節這個地方不再展開，有興趣的同學可以自行閱讀。
3.4 優化線程池
減少不合理的線程，降低線程切換帶來的超時。
1）分析
a. HTTP 線程數
先看下服務端 HTTP 線程數是否有明顯增加，且流量沒有增長，要確認 HTTP 線程數增加不是因為流量增長導致的。如下面兩張圖，流量正常的情況下 HTTP 線程數增加，說明是服務端響應變慢導致，可以確認超時是服務端原因。
圖7 服務流量平穩
圖8 HTTP線程數突增
b. 總線程數
再看下總線程數是否有增加（排除 HTTP 線程數），如果有，說明有使用多線程導致線程數量增加。這個時候需要 Dump 下線程，看下哪些線程使用的比較多。
2）解決方案
a. 統一管理線程池：動態配置參數+監控能力
通過工具類封裝統一的線程池，提供動態配置參數和線程池監控能力。
效果線程池具備監控能力，如下圖是最小值（核心線程數）、最大值（最大線程數）和當前線程池中線程數量的監控，可以參考這個來調整線程池參數。
圖9 線程池水位線監控
b. 異步改同步：小于10ms 的不使用多線程
高并發的場景下線程太多，線程調度時間得不到保障，一次任務需要多個 CPU 時間片，下一次調度的時間無法得到保障。
如下圖是一個線程池執行耗時埋點，通過埋點發現 A 在線程池中執行的比較快，平均線和 P95 都在 10ms 以下，沒有必要使用線程池，改成同步執行。
圖10 優化前執行耗時
效果接口性能提升明顯，平均線從 2.7ms 降低到 1.6ms，P99.9 從 23.7ms 降低到 1.7ms。
之前使用多線程，請求量有波動的時候線程增加比較多，導致線程調度時間得不到保障，體現到 P99.9 就很高。
圖11 優化前后耗時對比
另外可以明顯看到總線程數也相應減少了很多。
圖12 異步改同步后總線程數減少
3.5 優化 GC
優化 GC，減少 GC 的停頓時間，提高接口的性能。
1 ）分析
首先看超時時間點是否有 Full GC，沒有再看下 Yong GC 是否有明顯的毛刺，如下圖可以看到 3 個明顯的毛刺。
圖13 Yong GC時間
如果超時的時間點（如下圖）可以對應上 GC 毛刺時間點，那可以確認問題是由于Yong GC 導致。
圖14 客戶端調用服務端超時次數
2）解決方案
a. 通用性 JVM 參數調優
檢查 -Xmx -Xms 這兩個值設置的是否一樣，如果不一樣 JVM 在運行時會根據實際情況來動態調整堆大小，這個調整頻繁會有性能開銷，并且初始化堆較小的話，GC 次數會比較頻繁。
效果-Xmx3296m -Xms1977m 改成 -Xmx3296m -Xms3296m 后效果如下圖所示，頻率和時間都有明顯的下降。
圖15 通用性JVM參數調優后效果
b. G1 垃圾回收器參數調優
背景：如果沒有設置新生代最大值和最小值或者只設置了最大值和最小值中的一個，那么 G1 將根據參數 G1MaxNewSizePercent（默認值為60）和 G1NewSizePercent（默認值為5）占整個堆空間的比例來計算最大值和最小值，會動態平衡來分配新生代空間。
JVM剛啟動默認分配新生代空間是總堆的 5%，隨著流量的增加，新生代很容易就滿了，從而發生 Yong GC，下一次重新分配更多新生代空間，直到從默認的 5% 動態擴容和合適的初始值。這種配置在發布接入流量或者大流量涌入時容易發生頻繁的 Yong GC。
針對這類問題，優化方案是調大 G1NewSizePercent，調大初始值，讓 GC 更加平穩。這個值需要根據業務場景參考GC日志中Eden初始大小分布來設置，太大可能會導致 Full GC 問題。
以查詢引擎為例，根據 GC 日志分析，新生代大小占堆比例在 35% 后相對平穩，設置的參數為：-XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=35
效果優化后效果如下圖，可以看到優化之后 GC 次數從 27次/min 降低到 11次/min，GC 時間從 560ms 降低到 250ms。
圖16 G1參數調優后效果
3.6 線程異步改成 NIO 異步編程
NIO（非阻塞 IO）可以減少線程數量，提高線程的利用率，從而降低線程切換帶來的超時。
1）分析：CPU 指標
分析 CPU 相關指標，如果出現 CPU 利用率正常，CPU Load 高需要重點關注（如果是CPU 利用率高的情況，說明 CPU 本身就很繁忙，那 CPU Load 高也比較正常）。
在分析之前，先介紹幾個概念：
a. CPU時間片
CPU 將時間分成若干個時間片，每個時間片分配給一個線程使用。當一個時間片用完后，CPU 會停止當前線程的執行，進行上下文切換到下一個任務，以此類推。
這樣可以讓多個任務在同一時間內并發執行，提高系統的效率和響應速度。
下圖模擬了單核 CPU 執行的過程，需要注意的進行上下文切換是需要開銷的，但實際一次上下文切換需要的時間很短（一般是微秒級別）。
圖17 CPU執行線程流程
b. CPU利用率
按時間片維度來理解，假設每次時間片都正好被使用完。
c. CPU Load
從上面概念分析，如果出現 CPU 利用率正常，但是 CPU Load 高，那說明 CPU 空閑時間片、等待線程數很多，正在使用的時間片很少，這種情況要減少 CPU Load 需要減少等待線程數。
2）分析：實際案例
我們之前生產遇到過多次 CPU Load 高 CPU 利用率正常的情況。問題出現前后代碼沒有變動，比較明顯的變化是流量有上漲。排查代碼發現有使用線程池并發調用接口的地方，調用方式如下圖。
圖18 線程池執行模型
這種方式在流量較低的情況下看不出什么問題，流量變高會導致需要的線程數量成倍增加。
例如：一次請求 A 需要調用 BCD 3個接口，那100個并發需要的線程數就是100 + 3*100=400（第一個100是A對應的主線程，后面的3*100是 BCD 需要的100個線程）。
3）解決方案
線程池并發調用改成 NIO 異步調用，如下圖所示。
和之前對比，100 個并發，需要的線程數也是 100（這個地方不考慮 NIO 本身的線程，這個是全局的，并且是相對固定很少的線程數）。
圖19 NIO異步調用執行模型
4）效果
超時問題沒再出現，CPU Load 平均下降50%，之前 Load 經常超過2（CPU 核數為2），改造之后 Load 降到 0.5 左右。
圖20 CPU Load優化后效果
3.7 啟動階段預熱
啟動階段預熱可以提前建立鏈接，減少流量接入時的鏈接建立，從而降低超時的發生。
1）分析
應用拉入后出現大量超時，并且 CPU Load 高 CPU 利用率正常，說明有很多等待線程，這種是拉入后有大量請求在等待被處理。
之前我們生產遇到過是在等待 Redis 建立鏈接，建鏈的過程是同步的，應用剛拉入請求量瞬間涌入就會導致大量請求在等待 Redis 建鏈完成。
2）解決方案
啟動階段預熱提前建立鏈接，或者是配置 Redis 的最小空閑連接數。其他資源準備也可以通過啟動階段預熱完成，比如 DB 鏈接、本地緩存加載等。
3.8 優化 JIT
JIT（Just-In-Time）編譯可以提高程序的運行效率，灰度接入流量將字節碼編譯成本地機器碼，避免對接口性能的影響。
1）JIT 介紹
JIT 是 Just-In-Time 的縮寫，意為即時編譯。JIT 是一種在程序運行時將字節碼編譯為本地機器碼的技術，可以提高程序的執行效率。
在 Java 中，程序首先被編譯為字節碼，然后由 JVM 解釋執行。但是，解釋執行的效率較低，因為每次執行都需要解釋一遍字節碼。為了提高程序的執行效率，JIT 技術被引入到 Java 中。JIT 會在程序運行時，將頻繁執行的代碼塊編譯為本地機器碼，然后再執行機器碼，這樣可以大大提高程序的執行效率。
2）分析
JIT 技術可以根據程序的實際運行情況，動態地優化代碼，使得程序的性能更好。但是JIT 編譯過程需要一定的時間，因此在程序剛開始運行時，可能會出現一些性能瓶頸。
如下圖應用拉入后 JIT 時間很久，那可以確認是 JIT 導致超時。
圖21 JIT執行時間
3）解決方案
優化 JIT 一個比較好的方案是開啟服務預熱（預熱功能攜程 RPC 框架是支持的）。
原理是讓應用拉入后不是立馬接入100% 流量，而是隨著時間移動來逐漸增加流量，最終接入100% 流量，這種會讓小部分流量將熱點代碼提前編譯好。
4）效果
開啟服務預熱后，如下圖所示，應用流量是逐漸增加的，可以看到響應時間隨著時間越來越低，這就達到了預熱的效果。
圖22 服務拉入后請求量和響應時間
3.9 換宿主機
當宿主機負載過高時，可以考慮更換宿主機，避免宿主機負載過高影響容器負載。
1）分析
a. CPU Throttled 指標
看下應用 CPU 節流指標，CPU 節流會導致 CPU 休眠引起服務停頓。如果 CPU 利用率正常還是出現了 CPU 節流，這種大多數都是宿主機問題導致。
圖23 CPU節流情況
b. 宿主機指標
排查宿主機 CPU 利用率、CPU Load、磁盤、IO 等指標是否正常，如下圖 CPU Load在某個時刻后大于1說明宿主機負載較大。
圖24 宿主機CPU Load監控
2）解決方案
重啟機器換宿主機。
3.10 優化網絡
排查不穩定的網絡線路，保證網絡的穩定性。
1）分析
網絡的重點看下 TCPLostRetransmit（丟失的重傳包）指標。比如下圖，某個點指標異常，而這個點其他指標都正常，那可以初步懷疑是網絡問題導致，最終確認需要找網絡相關團隊確認。
圖25 TCPLostRetransmit指標
2）解決方案
找網絡相關團隊排查優化。
四、總結回顧全文，主要講解遇到超時問題怎么分析、怎么定位、怎么優化，從簡單到復雜總結了 10 種常見的優化方法。這些方法不一定能解決其他不同業務場景的超時問題，具體需要結合自己的實際業務場景來驗證。
本文總結的方法都是我們在生產中遇到的真實情況，通過不斷實踐總結出來的，希望這些內容能夠給閱讀本文的同學帶來一定的收獲。
4.1 優化注意事項
超時時間設置和 GC 調優需要結合自己業務場景來優化。NIO 異步編程改造成本、復雜度較高，我們也在探索更簡單的方式，例如 JDK19 引入的虛擬線程（類似 Go 協程），可以用同步編程方式來實現異步的效果。【作者簡介】Wen，攜程資深后端開發工程師，專注系統性能、穩定性、交易系統等領域。
以上就是關于pos機98發卡方超時,攜程10個有效降低客戶端超時的方法的知識，后面我們會繼續為大家整理關于pos機98發卡方超時的知識，希望能夠幫助到大家！
