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