美團點評智能支付核心交易系統的可用性實踐：https://tech.meituan.com/Trade-High-Availability-in-Action.html

今天看了一篇支付相關的博客，回頭看了下我們的清結算系統，引發了一些思考。

1、消除依賴、控制依賴、弱化依賴

???? 消除依賴：交易系統將訂單數據推送給MQ，而清結算系統從MQ上拉取訂單數據，這樣的優點是交易與清結算消除了依賴，實現了交易與清結算的解耦。

???? 控制依賴：MQ接收消息依賴交易系統，清結算系統拉取消息依賴MQ

???? 弱化依賴：對于以上依賴關系，當MQ發生故障時，交易系統與清結算系統將無法通信，這樣的話我們可以直接采用RPC調用通信，實現弱化依賴的效果，達到容災處理。

2、事務中不包含外部調用

?? 這里的外部調用，可直接理解為調用外部服務接口。當調用外部服務接口時，可能出現一些不穩定因素：比如有可能遇到外部服務掛掉引起調用接口失敗，或者網絡不穩定引起的調用接口超時，當遇到這種情況的時候我們一般采用重試機制，一般默認重試3次，當最后一次調用失敗則報警，人工干預。

? 而事務中如果包含外部調用，必然會造成大事務，大事務會造成其他對數據庫的連接請求獲取不到，導致和這個數據庫相關的所有服務處于等待狀態，造成連接池被打滿，多個服務直接宕掉。

解決方案：

排查各個系統的代碼，檢查是否存在RPC調用，HTTP調用，消息隊列操作，緩存，循環查詢等耗時操作，將這些操作移到事務外，理想情況事務中只處理數據庫操作。

建議不要使用xml文件配置事務，而使用注解的方式。原因是XML配置事務，第一可讀性不強，第二切面通常配置的比較泛濫，容易造成事務過大，第三對于嵌套情況的規則不好處理。

對大事務添加監控報警。

3、合理設置超時時間和重試次數

清結算系統的響應時間=內部處理時間+外部依賴超時時間*重試次數

清結算系統存在一些外部服務調用、消息隊列操作等，而當這些依賴方發生故障時，如果超時時間過長、重試次數過多，或者系統長時間不返回，可能導致連接池被打滿，系統宕掉；如果超時時間設置過短，則錯誤會增多，系統可用性就比較差。

解決方案：

超時時間=響應時間*1.5；

調用方的超時時間依賴被調用方的響應時間；

可默認重試次數為3；

4、處理慢查詢

讀寫分離。讀走分庫，寫走主庫

優化索引。索引過多影響數據庫寫性能，索引不夠查詢會慢；調研所有查詢sql，優化索引，頁面查詢，可設置默認值，走組合索引，DBA建議索引個數不要超過5個，組合索引字段不要超過5個

將查詢分為實時查詢、近實時查詢、離線查詢。實時查詢可直接查詢數據庫，其他可通過ES實現一個查詢中心，處理近實時查詢和離線查詢

不要出現大表。當一張表的數據量達到千萬級別，效率將急劇下降，則可考慮分庫分表

5、熔斷

當依賴的服務不可用時，服務調用方應采用一些技術手段，向上提供有損服務，保證業務柔性可用。

解決方案：

自動熔斷，

手動熔斷，

6、限流

系統可能收到一些有意或無意的請求，如DDoS攻擊、用戶失敗重刷。

流量控制中常用的算法：令牌桶、漏桶、計數器。可以使用Guava的RateLimiter來實現，其中SmoothBurstry是基于令牌桶算法的，SmoothWarmingUp是基于漏桶算法的。

?

轉載于:https://www.cnblogs.com/tilamisu007/p/9037078.html

總結

以上是生活随笔為你收集整理的清结算系统的一些思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。