极光推送升级总结

作者: LE1Dx | 来源:发表于2016-03-04 00:42 被阅读1780次

    公司之前用的百度推送,经常出现推送丢失的情况。发现推送经常会收不到,而且经常是推送接口没有返回错误。之前一直不想换,因为觉得成本有点高。后来实在受不了了就决定研究当下有哪些推送比较好。最后比较后,业界当然口碑最好的是极光推送。就觉得换极光了。事实上推送的确比百度好多了。
    要平滑升级极光推送,其实并没有之前想的那么高成本。不过升级过程也遇了问题,现在就来讲升级的过程。

    之前我们系统有一个Push接口,主要是推送的涉及的方法,单点推送,分组推送,类型推送,广播推送等。有一个Push4BaiduYun的类实现了该接口。具体就是把用百度的推送api实现了。在系统中用到推送的地方用spring的配置Push4BaiduYun。

    现在要平滑升级极光推送,要考虑的就是实现和极光推送的对接,和同时兼容之前没有升级用户的推送和新用户的推送,就是根据用户当然的版本采用不同的推送方式。

    推送标示一个用户,都有自己的id,原系统设计的时候用户信息里面存储了mid来标示,同时有一个mt标示用户设备类型。支持ios 4,android 3。在这样的基础上,升级后的前端需要更换极光推送的包,同时在更新mid的时候用极光产生的regid。那怎么最小改动,最好的判断用户用的是什么版本呢,用mt。之前的ios 是 4,android 是3。新版本在生产mt时,ios 用 14,android用13。这样就可以标识出用户当然的设备是什么版本了。同时,只需要修改mt使用时判断,然后选择就好了。

    为了实现这个,新建了两个类实现Push接口,Push4Jiguang,PushManager。其中Push4Jiguang用极光的包实现了基础的推送功能,PushManager,包含了Push4BaiduYun和Push4Jiguang,同时可以通过Spring配置各自的key和secret。在PushManager实现各个Push的推送接口时,都可以根据mt的类型选择不同的推送方式。

    在使用Push的地方,只需要在Spring配置改为PushManager就好了,更本不感知推送方式的升级。

    另外,升级极光推送的时候有一个问题困扰了个多小时,极光推送在执行sendPush方法的时候,好像是抛出final类不能继承的错误,莫名其妙啊。在例程中没有问题,在系统中跑就不行。一直怀疑是系统什么包错误了,没有找到。最后把极光的功能导入,跟踪才发现是gson出问题了,一查发现,系统中有一个gson1.4的包,而极光用的是gson2.4的包,好吧,替换下包就好了。至于为什么gson1.4的包不能,没有仔细去研究。

    还有一个问题,在看极光推送官方文档发现,极光对于免费推送有一些限制。一些限制对我们影响还比较大。我们替换极光推送当然是因为它稳定,推送不丢失。但是极光推送的两个限制可能会影响这个成功率。
    1、全部免费用户共享20W/s的推送通道。
    2、API调用频率最多600次/s。

    这意味这,对于第一条限制,我们除了升级VIP用户,没有其他办法。推送在高峰时期丢失无法避免。对于第二条限制,我实际测试了,如果一直推送,消息不仅会丢失,还会导致极光把我们拉入黑名单一段时间。也就是说如果,要在第二条限制的基础上做到不丢失推送,不能多于600次/s的推送,因为免费用户没有进行分组推送,所以,除广播,我们一条推送只能到一个用户。那一秒钟最多可以推送10条,那推送一条sleep(100)就可以保障不会受限制。为了避免出问题,这里每推送一条都sleep(200)。如果这样做,那我们每天可以推送的消息数是56060*24=43200条。当然最好的还是直接升级VIP,不受这个限制好了。

    可以想象,百度可能也有类似的限制。根据我们的业务特点,推送都是集中一次性一起发送很多条,但是对时间的延迟要求基本没什么要求,就算晚了一个小时,也没有什么影响。所以之前消息丢失可能有很多都是我们一次性调用太多次数,导致消息丢失了。

    相关文章

      网友评论

      • javenfang:感谢您对极光推送的信任!

        作为官方人员,你说的第二个问题,我来说明下。

        你提及到,第二个限制即 『API调用频率最多600次/分钟』,会导致消息丢失。

        这个理解上有偏差。实际情况是:

        1. 极光推送在设计上,保证不会丢失消息。
        2. 你感觉到丢失,实际上是每分钟 API 调用次数超过 600 次时,超过的调用会返回错误,即请求失败,会返回错误码。我理解你做简单的测试,没有留意这个错误码返回,没有进行错误处理。

        相关文档请见:http://docs.jpush.io/server/server_overview/#api-rating

      • MMMille:看起来是验证错误, 但是appkey和appsecrtet都是没问题的. 如果楼主有时间的话,烦请解析一下. 十分感谢
        MMMille:@LE1D 最后我还是用服务器来和苹果的推送服务器来交互了
        LE1Dx:@明銮 你解决了吗?我做的是服务端部分,IOS没玩过。你可以下载极光的IOS的demo看看,应该没问题的。
      • MMMille:Error Domain=com.alamofire.error.serialization.response Code=-1011 "Request failed: unauthorized (401)" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x7ff112d61c30>
      • MMMille:结果提示了错误..
      • MMMille:求助楼主:
        我想用iOS客户端,发一个信息到极光推送服务器, 让它将信息推送给我要发送的目标,
        我用AFNetWorking来POST 消息到https://api.jpush.cn/v3/push
        具体内容如下:
        AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
        NSString *AuthStr = @"3665e83921a0f6743525edf7:72b53d234236c9a1134dbff7";
        NSData *base64Data = [forAuthStr dataUsingEncoding:NSUTF8StringEncoding];
        NSString *base64Str = [base64Data base64EncodedStringWithOptions:0];
        NSString *authStr2 = [NSString stringWithFormat:@"base %@", base64Str];
        NSDictionary *parameter = @{@"Authorization":authStr2,
        @"platform": @"all",
        @"audience": @{@"alias":@"admin"},
        @"notification": @{@"ios":@{@"alert":@"i got a intesting message"}}};
        [manager POST:@"https://api.jpush.cn/v3/push&quot; parameters:parameter success:^(AFHTTPRequestOperation * _Nonnull operation, id _Nonnull responseObject) {
        MyLog(@"%@",responseObject);
        } failure:^(AFHTTPRequestOperation * _Nullable operation, NSError * _Nonnull error) {
        MyLog(@"%@", error);
        }];

      本文标题:极光推送升级总结

      本文链接:https://www.haomeiwen.com/subject/wrrokttx.html