图3.2.1 筛选查询中的性能瓶颈风险
3.3 查询缓存和预筛选谈到查询场景，必然会有缓存的一席之地，与一般设计思路不同，U-Push直接放弃了针对实时筛选能力的查询缓存，因为在这样的设备量级下随时的设备更新是必然。U-Push的实时筛选库是一个高频写低频读的场景，但是对单次读的要求比较苛刻，首先对未开启实时功能的离线客户，因为设备库是快照形式，一天内的多次读拿到的结果必然相同这时候设置缓存就很有意义，比如新闻、气象、工具类客户的习惯，一天内发送多次广播，就不必每次再去重新生成筛选集文件。
图3.3.1 查询缓存逻辑流程图
预筛选功能的开发是个小插曲，前面讲到U-Push放弃了对实时的查询缓存，导致客户的每次消息发送都要重新去生成文件，在保证数据实时性的角度考虑无可非议，但是遇到“较真”的客户就很有压力。比如新闻类客户极度关注消息下发的时效性，通过开发者控制台可以查看每个任务的筛选时间，有时候同类消息2s的差异也会引发客户在DING群的"客诉"。客户的诉求可以理解但是这也耗费了团队大量的精力。通过和个别客户沟通U-Push开发了预筛选功能，在客户习惯性发送消息的前一段时间预先调度执行筛选逻辑生成设备ID集合，通过损失少量的数据时效性来压缩消息下发时间，争取消息发送速度。
图3.3.1 友盟+U-Push消息轨迹
3.4 Alias筛选的优化 筛选请求可以归类为两种场景：Alias功能依赖的ID Mapping场景，NvN的设备ID和Alias映射。
tag组播和iOS广播功能的select场景，条件查询，基于ADS实现。
Alias功能简介：Alias允许开发者为设备绑定别名，别名由alias_type，alias两个属性组成，譬如开发者可以标识设备A，为他增加alias_type=telephone_number, alias=13900000000以此来给设备A增加手机号的属性。在发送消息时候可以绕开device_token，直接通过服务端指定alias实现触达，alias是一个典型的NVN ID Mapping场景，一个设备在同一个alias_type下面同时只能拥有一个alias。这也是符合一般业务场景的，比如上例一般一个设备只有一个手机号，设置新手机号后会覆盖原alias。如果需要满足双卡双待的功能，需要设置两个alias_type，即alias_type=telephone_number_main，alias_type=telephone_number_secondary。alias的一般使用场景是开发者通过自定义文件播上传一批文件，文件内容为某个alias_type下若干设备alias的集合（百万千万级）。筛选服务扫描文件后依次找出alias值mapping的device_token。
3.4.1 Alias的早期设计说到Mapping，轮询，高吞吐查询，首当其冲选Redis，早期的U-Push也是如此。