短信疲劳度控制就是避免之前7天内发送过短信的号码不再发送短信。 目前的方案是将发送过短信的全部存储redis,然后发送的时候一个一个匹配过去,遇到重复的号码就不发送。 这样子速度是没有问题的, 当时空间会存在问题。 当号码量达到3000万的时候,空间4G就上去了,这个还是比较不妥的。
请问一下, 这种问题有什么其他的解决方案吗?望大神不吝赐教
短信疲劳度控制就是避免之前7天内发送过短信的号码不再发送短信。 目前的方案是将发送过短信的全部存储redis,然后发送的时候一个一个匹配过去,遇到重复的号码就不发送。 这样子速度是没有问题的, 当时空间会存在问题。 当号码量达到3000万的时候,空间4G就上去了,这个还是比较不妥的。
请问一下, 这种问题有什么其他的解决方案吗?望大神不吝赐教
这个问题,都是空间换时间的问题。你都说到有高并发的情况,把数据储存到mysql
不是一个理想的方案,3000w的数据,储存手机号码,应该用不了4G内存那么多,即便是用了4G内存,只储存了7天的数据,你预算8G内存也不会夸张,现在一般redis机器,部署的内存都很大。你网站访问量这么大,增加内存也是很有必要。如果实在是没有预算,还是建议上mongodb
吧
1 回答4.1k 阅读✓ 已解决
3 回答1.9k 阅读✓ 已解决
2 回答2.3k 阅读✓ 已解决
2 回答3.2k 阅读
1 回答1.9k 阅读✓ 已解决
2 回答742 阅读✓ 已解决
1 回答1.4k 阅读✓ 已解决
我提供一下自己的想法,没有实践过,不知道是否合适,1G内存差不多能存1000W条左右的号码,全部用redis肯定是不太合适的,既然贵公司有了这方面的需求,是否可以考虑一下传统的
mysql
,首先以月来分表,然后每个表分区成4个区,根据请求的时间来做简单的算法判断,判断去具体哪个表哪个区里面去找,大致就是这样的逻辑...当然,也考虑一下mongodb
,她在处理大批量数据上面要稍微快一些的