sdk本身是基於netty 服務，netty 雖然是高性能的異步網絡框架，一個線程將會處理很多channel 讀寫事件。毫無疑問 ，這裏性能瓶頸在於讀寫事件處理。
服務降級
本質上通過降級其他服務，保證核心服務正常運行。
核心點 -> 關掉非關鍵部分服務的業務，保證核心服務的正常運行。
說實話 sdk 服務屬於基礎服務 ， 非關鍵服務，比如我方鑑權，3方風控，這些都是屬於可以降級的服務。直接降級是不會有很大問題的，用戶無感知。如果非sdk的降級屬於輕度降級的話。 那sdk降級應該屬於中度，或者重度了。 大部分會影響前臺展示。
發送私信消息 - 核心業務
1. 未讀消息不入表 sdk 重
2. 未讀消息，歷史消息延時批量入 sdk 中
3. 當tqmq 下游消費消息 遠遠慢於上游時候 ，這時候，是否可以將消息直接走離線推送流程 。如果快速添加下游消費節點，但是由於是長鏈，新添加的節點無法迅速的提供消費能力，沒有辦法的情況下才做此法。 tqmq 重
會話列表
1. 只顯示私信會話列表 （點贊，回覆不顯示在列表）sdk 中
未讀消息
1. 返回數據空 （用戶暫時看不到未讀消息）走歷史消息 sdk 重
歷史消息
1. 3個月多級緩存數據 （3個月之前的不提供服務降級）sdk 中
點贊
1. 不插入會話列表 sdk 重
2. 延時批量入 sdk 中
回覆
1. 不插入會話列表 sdk 重
2. 延時批量入 sdk 中
拒絕策略
當服務降級至sdk 重 ，發送消息rt依然很高 ，沒辦法只能啓動限流，開關了 ，對所有發送消息 啓用限流 ，每s 每個實例固定2000消息請求調用，其餘消息直接返回失敗。
目前 soa 框架 重試時間是15s ，高併發情況下明顯是有問題 ，當下遊服務15s 不能響應的時候 ，每s 數w，數10w個請求 ，很有可能jvm 內存扛不住就會溢出的。