很多场景中，服务端需要对用户的请求进行验证，比如QQ登录模块、统计工具的数据收集模块、品牌广告对应id的match等。针对不同的场景，可以有不同的验证方法，本文将介绍工程中常用的几种。
直接使用数据库进行验证
方法1：每次请求时，从数据库中查询出key对应的秘钥，然后和请求的秘钥进行验证。 场景1：适合QPS非常低的场景，比如内网的权限认证系统 方法2：和方法1类，数据库使用内存数据库如redis 场景2：内存数据库的使用成本很高，如果预算允许的话，可以扛住高并发的请求。比如在投放品牌广告时，我们事先计算出目标用户的ID，将其导入内存数据库，针对每次广告请求，从内存数据库中查询，看是否能和目标用户match，如果match的话，就曝光一条品牌广告
缓存查询结果
方法：通过缓存将key对应的秘钥缓存起来。针对每一次请求，如果缓存中没有对应的数据，则从数据库中查询数据进行验证，然后将key对应的秘钥更新到缓存中，以供下次使用。 场景：可以扛住高并发的请求，如果请求的key比较少的话，可以得到精确的结果。如果请求的key的数据量非常巨大，则使用部分数据结构，能计算出在误差允许范围内的统计结果。比如统计日活千万级app的实时新增设备数，app打开时，会上报日活事件，同时附带设备ID。我们可以将app的历史设备ID通过bloom filter缓存下来，如果不在其中认为是一个新增设备，同时将设备ID更新进入bloom filter中
使用二级缓存
方法：保存两个缓存，一个用于判断key是否合法，一个存放key对应的秘钥，判断请求的秘钥是否合法。请求进来时，首先从第一个缓存中查询key是否合法，如果合法，则从第二个缓存中，查询出对应的秘钥并和请求的秘钥进行对比，如果match，则认为请求合法。每次请求缓存时，如果缓存中没有对应的key，都需要查询数据库，并将key更新到缓存中 场景：适合key不是很多，但是请求量非常巨大的场景，第一个缓存可以很好地防止有人利用接口攻击系统。比如现有的app统计工具，因为没有建立长连接，app每次打点时，都要验证是否是合法的SDK上传上来的点，这种系统的QPS非常高，但是app量即key不是很多
总结
因为现实中IO的成本非常高，所以我们要针对不同的业务场景，使用不同的验证方法对数据进行验证。而实时系统中，某些场合对数据的准确性要求不高，这个时候，就可以利用一些数据结构如bloom filter来提升程序的性能
