想到使用定时任务每天查询,但是用户量大的话特别耗系统资源,有没有更完美的设计方案
1
puzzle9 2021-04-23 16:52:22 +08:00
有一个牛逼的思路
虽然我没这么写过 可我觉得也能用 在用户填写生日后 添加个延迟队列到那一天 然后根据项目周期 再多来几次 我觉得 10 次就够了 然后 就可以把锅给运维了 手动狗头 |
2
yitingbai 2021-04-23 17:01:11 +08:00
select * from customer where MONTH(birthday) = MONTH(NOW()) and DAY(birthday) = DAY(NOW())
|
3
dqzcwxb 2021-04-23 17:16:39 +08:00
定时任务,延迟队列,时间轮
|
4
dcty 2021-04-23 17:19:34 +08:00
请问这个用户量得大到什么程度才会让你有这样的担忧,要不偷偷加一个字段,B_DAY_INDEX (0~365)
|
5
PiersSoCool 2021-04-23 17:25:49 +08:00 1
就算 14 亿人,14 亿个数据,分分钟也搞定了,不行就搞个 bucket 算法
|
6
xiaoleis 2021-04-23 17:26:36 +08:00
每天凌晨一点把当天生日的用户数据统计好。 抽个时间集体发短信就行。 同问用户量得大到什么程度才会让你有这样的担忧。
|
7
imn1 2021-04-23 17:31:55 +08:00 1
你该不会是认为每个用户给一个任务吧?
是每天一个任务啊,搜当天生日的所有用户就是了 |
8
misaka19000 2021-04-23 17:34:15 +08:00
你的用户量是有多大???全球也就 70 亿人吧???
|
9
Building 2021-04-23 17:37:59 +08:00 via iPhone
App 设定本地通知 schedule,通知触发后给发送请求,后台收到请求发送短信。
|
10
lshero 2021-04-23 17:44:02 +08:00 4
居然担心的是系统资源而不是短信费
|
12
raaaaaar 2021-04-24 18:23:16 +08:00 via Android
我想了下,最简单的就是开个定时任务,每天唤醒次,找到当天生日的人,再推送就好了。其实这就挺快的了,毕竟一天就扫描一次,生日加个索引扫描一遍就行了。
如果要优化的话,首先想到的是空间换时间,直接开 365 个桶,生日装到对应的桶里,每天直接用对应的桶就行了。 延时队列啥的我没用过。。 不过的确短信费才是大头,程序其实消耗不算大。。 |
13
abersheeran 2021-04-25 10:28:05 +08:00
用一个 kv 数据库,每个用户被创建的时候把该用户唯一 id 加进对应的“月-日”下,注销的时候去对应的“月-日”下删掉。完事。
|