sdk 服务降级与流控

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 内存扛不住就会溢出的。