项目背景：
针对不同行业机构用户半年内缴费的行为习惯，线性估算用户下次缴费时间，并给用户发送短信或APP提醒（PS：能发送短信的用户肯定可以发APP，能发APP的用户不一定能发送短信）。
小白作为一个有着三年经验的开发，看到这个需求笑的嘴都合不上，大喊一声：手到擒来！不出半个小时，就形成了初步的设计方案。
- 设计预测表
字段：机构、用户编号、半年内首次缴费时间、最近一次缴费时间、半年内缴费次数、半年内缴费总金额、预测每日用费、预测费用清零时间、预测发送时间...- 在配置中心增加配置，设置哪些机构能够使用该预测（这种业务只适合预付费用户）
key：predict_biller, value: [biller1，biller2，biller3...]。- 监听缴费行为
过滤机构，生成缴费用户预测数据落存。- 设置定时任务
每天固定时间根据机构依次捞取预测表中需缴费的用户，查询用户档案表用户发送短信类型，调用短信通知接口。
方案形成，小白乐呵呵地发送给技术经理大南，心想这方案完美。话说大南拿到文档一看，暗叹：好家伙！小伙还需要打磨打磨啊。于是他拉上小白一起来聊一聊。
大南：小白，你看我们这次准备上多少机构，每个机构一共有多少月活呢？
小白：我们准备上5家机构，月活共计大概是300万。
大南：一年下来表里数据小4000万，定时任务还能查的动吗，是不是可以考虑把数据分成2类：一类是待发送表，一类是发送历史表，每天从待发送表里捞取数据进行发送，发送完成的进入历史表存档，这样待发送表的数据量小方便查询，历史表数据也方便定期清表。
小白：妙啊！我这就去改一下进行开发。
大南：等等，这个方案还有优化的空间。
小白：什么，你开什么玩笑！
大南：你看有没有这个可能，咱们需求不了解数据，半年的数据不具有代表性，上线几天后让你改成根据一年数据预测，你这代码需要重新发布？
小白：这个你放心，早就知道产品经理的尿性。我会在配置中心再增加一个配置，key：predict_period, value:6。
大南：哈哈哈，你这配置是加上了还是不够灵活啊。半年是一个时间段，需要灵活配置，配置的话必须要考虑配置的维度。目前你是将时间和机构分开去配置了，有没有可能改造一下原来的key：predict_biller，将value变成json格式的。
小徐一拍桌子：我知道了！这么改：
value = {
biller1: {
start：2022-01-01，
end：2022-06-01
}，
biller2: {
start：2022-01-01，
end：2022-06-01
}
}
大南很是欣慰。
小白突然沉默了，过了一会他说：这下应该没有优化空间了吧。
大南笑了笑：当然有！你把捞取数据和发送短信这个操作已经分开，应该考虑到了业务的可拆解性。想一想发送的动作可以按机构做拆分吗，之前生成的数据我还可以选择日期去重新发送吗？
小白：我明白了，接口里我不应该默认根据机构依次去轮询。应该写成@GetMapping({"/notice/{biller}/{date}", "/notice/{biller}", "/notice" })，当用户传机构编号的时候，我就根据传入的机构编号进行查询，否则查询所有；当用户传入日期的时候，我就根据日期进行查询，否则查询当天的。
大南拍了拍小白的肩膀：不错不错，孺子可教。
小白屁颠屁颠地去开发了，项目顺利上线，发送短信定时任务请求使用的是“/notice”，一个接口搞定。产品经理过了两天过来，说有个大机构需要改成根据9个月数据预测，眼睛滴溜溜的转着，想着怎么让小白赶紧加班改出来。没想到小白瞬间满足了他的需求，产品一下乐开了花。
本以为这个需求就这么结束了，今天产品经理他又来了。小白脑子里莫名想起了歌声：他来了他来了，他带着需求走来了！他说，因为甲方爸爸的原因，用户的缴费预测照旧，但是短信不发送了，今天必须改好！
小白一下傻了眼，咋整咋整，改下代码从测试到发布最起码3个小时，还有2个小时下班，这家伙摆明了想搞我！算了，拗不过他，先跟技术经理申请下加班吧！
大南听了下需求，思考了片刻，坏笑着看着小白：小白，不加班行不行？
小白：臣妾做不到啊，来不及的来不及的。小白的头都快摇出残影了。
大南：你还记得那个定时任务吗？有没有可能先满足客户需求，我们后面再做优化呢？
小白：哦～我明白了，我们目前只上了5家机构，调用定时任务的时候我们使用的是“/notice”，为了满足客户需求，我们把原来统一的定时任务改成"/notice/{biller}"，分别传入需要发送的机构编号就行了。优化的话我下周去配置中心加个predict_send_biller,把真正发送的机构配置上。
大南狠狠敲了一下小白的头：你个der，还是不动脑子！记得我们当初为什么假如历史表吗，是为了提升查询待发送数据的效率呀。假如我们不发送短信了，那么待发送表的数据就不会迁移到历史表，一段时间以后，我们表里的脏数据就越来越多了。
小白无奈地看着大南，双手一摊：产品要求的，我也没有办法啊。
大南：发生这种情况，实际上还是我们的代码不够健壮，没有考虑全面业务的场景。我们可以在配置中心新增一个key:predict_send_biller_exclude,
value= {
biller: expireDay1,
biller: expireDay1
}
小白：我懂了我懂了，这个配置可以帮助我们配置哪些机构不用发送短信。在表里增加一个字段失效时间，跟产品商量，通过定时任务检测，当待发送表的数据进行删除。这个配置一举两得，还得是我南哥！
大南不屑地摆了摆手：别拍我马屁了，有空考虑下代码是怎么优化的吧。
本节完。
网友评论