part I 工作弹
记于8/24日中午12点13分
原本打算每周五晚上写工作弹，昨天太颓了，打了一晚上游戏，没有写，抱怨了一晚上。以后要学会调整好自己的心态，正能量的人才可爱。
这一周开发的任务较上周相对轻松，完善了一下资讯的系统相关，主要是做了两个报表，技术含量不大。周二周三独立做了一些事儿，关于云晴和小码上的一些优化，都是比较基础简单的工作，添个搜索框，做个图片预览，做了个列数不固定的excel表格下载。
主要的坎儿就在昨天分配的任务，本来难度系数不大，先把逻辑过一遍，回想一下昨天都干了啥，首先，要做的事啥呢，不要多次请求redis，一次拿下来本地做比较，这个其实很好理解，卡就卡在了自己对代码以及想要做的事儿不了解要干什么，整体回顾一下，首先，你SDKRequest这个请求里包含了一个deviceId，它由于手机操作系统的不同，可能存于不同的属性值当中，如果是ios那这个号就是idfa，其实手机本来都有一个IMEI号，被各大app获取该IMei号下的用户活动信息，但是苹果出于保护个人隐私的情况，禁止了各大app读取IMEI号而长期跟踪用户，使用户避免成为透明人，但是广告商想看自己的广告是否投放成功了，又需要跟踪设备，于是苹果整了个折中的方法，给他们一个手机的idfa，这个idfa是可变的，用户也是可以修改的，这样，用户可以一段时间修改一次，以免自己受到长期的监控，这个东西吧，有利有弊，不好评价。这里有一篇比较不错的解释https://www.zhihu.com/question/38856446
那么拿到了这个deviceId，就可以去远程redis下，去找一下它对应的包名，其实就是一个大的平台，里面存了这个用户手机里的所有的appList。拿到这个之后，要做个过滤，过滤什么，这个appList里存的是id集合，我们本地的数据库中也存了一个这样的集合，不过我们存的是包名id和app_id的映射关系，只有这个appList里的id在我们的映射关系大map下存在，那才有对应发广告的意义。判断，有一个存在的，那么我们就可以发广告了。但是我们还有个自己的发广告计划，也不是它所有的appList下的我们都发，这个时候去查一下另一个redis，这里面有我们计划之中要发广告的那些appList，key值不一样，这个是用了MD5加密了deviceId，不过原理类似，取值嘛，有啥难的。然后要把我们要投放的计划与这个拿出来的redis中的投放计划相匹配过滤一下。
想一想原来的策略是什么，原来是每一个计划adplan对应的id都要拿到远端redis去过滤看看我们deviceId对应的set集合中有没有这个id，也就是过滤每一个的时候都要请求远端redis，现在，把redis中的都拿出来，然后放到set中，比较一下就可以了。
之所以只把matchSet的去先拿出来，是因为它是走的dmpRedis走的外网redis，而sspRedis是走的内网redis，请求延时没那么大，所以拿不拿出意义不大

part II 充电弹
这周基本没怎么充电，大致看了看kafka，二亮讲的也不深，粗略提了提简单使用。
骆驼祥子里和祥子产生了强烈的共鸣，不过多少祥子拉了三年黄包车，买了辆自己的车子，生活虽苦，但祥子还是在坚持。

八月倒数第二弹了，时光匆匆，白驹过隙，加油，把握现在