第一招：釜底抽薪

简介：通过去除无效devicetoken，本地减少发送数，来提高整个任务的发送速度。

有效性：视app决定，有的app卸载用户少，作用不明显，有的app卸载用户90%以上，效果杠杠的。

什么样的devicetoken是无效的，如何识别？简单来说apns返回发送失败时，reason内容为BadDeviceToken和Unregistered的可以判定成无效devicetoken。关于BadDeviceToken很好理解，而Unregistered又是个什么鬼？有如下测试:

1. 关闭推送，1小时内发送消息，apns返回success，但是app没有收到消息
2. 打开推送，在关闭期间发送的消息收不到，打开后的消息正常收到。devicetoken没有变化
3. 关闭推送，第二天发送消息，apns返回success，但是app没有收到消息
4. 第二天打开推送，在关闭期间发送的消息收不到，打开后的消息正常收到。devicetoken没有变化
5. 卸载后，立马发送消息，apns返回Unregistered
6. 重装后，生成新的deivcetoken，对老的deivcetoken发送消息，apns返回success，但是app没有收到消息；对新的deivcetoken发送消息，apns返回success，app收到消息

以上测试基于ios9，ios10还没测试。不过根据历史发送结果来看，Unregistered十有八九就是被卸载了。

第二招：调虎离山

简介：使用netty的发送程序，可以尽量将耗时的代码从EventLoopGroup中移出，或用线程来处理。

有效性：视代码时间开销而定。

最近在弄美国服务器进行发送速度的测试，测试结果后面说。过程中发现，读取/写入国内的redis速度慢的令人发指，导致发送速度不到10条/秒。于是将可以异步处理的写入redis放到线程中去处理了（读取直接删除，反正是测试）。结果发现速度突突突突突突的快。于是国内也将写入redis做了相同的处理，虽然速度提升不是太明显，但总体的感觉还是快了一些。之前想着读写redis肯定非常快，不会造成多少时间开销，但从结果来看还是不能想当然。

第三招：无中生有

其实和无中生有半毛钱关系都没有，只是三十六计里面找不到合适的随便选了个。

简介：提高发送的并行度。

1. 单服务器模式下增加channel的个数。
2. 大型任务则分发到多个服务器上去执行。至于如何实现调度、如何统计结果、如何处理子任务失败、如何处理长尾问题、如何处理XX问题就不在这里讨论了。

反正自从我实现完多机器并行处理一个任务后，再也没有开发者反馈我们发送速度慢了[大哭]。比如以前慢的时候40分钟、快的时候7分钟发送完的任务，现在变成快的时候90s、慢的时候10分钟。好想给我自己一个赞。

终级大招：走为上计

去美国搞台服务器，性能不用多牛逼，内存够用、cpu还行，虚拟机也可以，速度就是一个突突突突的快啊，同样的程序，速度是国内的10倍以上。还考虑什么分布式调度、考虑什么子任务单点失败、考虑什么长尾、考虑什么结果汇总，麦什么破、锐什么丢死，直接突突突突的单线程都比国内快，就是这么暴力。

最后

速度调优什么的最讨厌了，懒得弄？很简单，来用友盟push，分分钟带你突突突突。

怎么感觉变广告贴了，摔！