APNS(全称:Apple Push Notification Service),主要是用于往苹果设备推送push消息通知!
基本流程:
今天要聊的问题集中在第4个环节,我们自己的服务器往苹果的消息中心推送通知。
现状:
历史原因,push的代码散落在各个应用中,随着新消息通道不断接入,开发、维护成本较高,开始考虑构建push中心,
封装dubbo接口对外提供服务,对外屏蔽各种差异,将所有的push业务逐步收扰到push中心。
过程漫长,开始接入的是个人业务,每天的调用量不大,服务器还表现正常;
8月底,BI的推送管理后台开始对接进来并发布上线,由于BI是针对各种营销活动批量推送的,一次任务少则几万,多则上千万,
此时服务器开始暴露一些问题。
下面开始介绍优化过程:
1)第一次线上问题暴露,现象:短信报警,查看dubbo注册中心无provider服务,登录线上机器,load飙高到了40,ps看了jvm进程在,但dubbo日志里,服务注册失败。
查看gc,一直触发Full gc,old空间却释放不了
解决:重启集群。之前的策略是发送过来的数据会封装到一个线程任务里,由ThreadPoolExecutor慢慢消化,怀疑一次发送的token过多(一次400),生产速度快于消费速度,导致对象积累。联系BI的稀土同学,将一次任务的数量调整为100,并且每次调用接口后休眠100ms。
2)另外查看了jvm的参数,修改启动脚本,将原来的堆大小由1G调整为2G,新生代由原来的300M调整为1G
-Xms2g -Xmx2g -Xmn1g -XX:+UseParallelOldGC
了解BI的机器配置,24核cpu 64G内存,配置很高但只有一台,采用的是dubbo默认的随机路由方式,1对多,担心负载不均衡,
注:线上dubbo注册