性能优化之网络带宽限制websocket推送优化
一.背景
在现有服务系统中存在大量的websocket长链接，对用户一些数据进行及时推送。问题产生于，当我们的服务系统随着业务的迭代对用户推送内容的不断增多，某一个业务的推送消息达到了 64k/条。这个时候由于推送端口没有限流导致兵法推送消息量过多，推送量过多导致网络带宽在某一个瞬时超过了签约限制峰值。
网络带宽限制：
签约时候限制的是 500M/s，经过我们的排查发现每秒的带宽消耗绝对没有这么高，而且我们自己也是有监控系统的，通过监控并没有发现有超过阈值的情况发生。经过一系列的分析及沟通运营商一起排查发现，他们居然是按照ms级别限流的。对此我们也没有办法，只能根据对方的限流策略去进行业务改造。
二.设计思路
1.消息内容压缩
通过将内容压缩，达到降低消息体大小，从而降低通信占用带宽。
优点：可以降低带宽使用及费用
缺点：改动过多，耗时过长，目前需要尽快解决带宽限流问题。
2.发送限流
使用令牌桶，每秒定量一定令牌数，如果超出令牌数量则进入等待队列，当前线程将不断轮询队列持续发送，直到等待队列发送完成。
当达到下一秒时在重新创建一个令牌桶和等待队列，与之前的线程并行执行
缺点：
1.当单个批次发送量过多时，经历多个时间窗口，会导致并发消息量增多，还是会出现上述问题
2.发送的队列数量受到服务器内核限制，当你的配置队列数量超过内核数量时，会导致产生lag
（线上服务器如 k8s 在流量波动较大时可能会产生动态迁移，从8核服务器转移到6核服务器这种情况产生）
3.定时分片发送
对每一个时间窗口消息安数量切片，每隔一段时间将一个分片的消息发布出去，从而降低带宽单位时间内消耗过高。
优点：改动小，可以尽快上线
缺点：当单个时间窗口内的消息量达到某一个量级还是会导致带宽超过阈值
三.最终结果
我们本次采用了第三个处理方案，并且在之后会考虑将内容压缩提上日程。
由于一些保密性原因，不会写一些具体的涉及到业务处理内容了，以后大概会更多的分享一些性能优化的解决措施和思路。具体代码还是要结合各自的业务及现象去编写。
如果有其他的解决思路可以留言给我，谢谢大家