MySQL-php定时推送订阅消息到android、iphone端效率问题
如图，物件记录表house_rel每天大概有四千到五千的新纪录生成，用户订阅规则表house_push_rule存放用户希望看到的物件匹配条件(记录总量100万以上)，现要实现每天12:00、18：00由服务器定时推送用户订阅的消息。
我目前的思路是这样的：步骤1、服务器端(php+mysql+nginx)按用户提交的规则进行数据筛选匹配；步骤2、将筛选出的数据写入mysql临时表并和规则表house_push_rule主键进行绑定；步骤3、按临时表规则进行推送。
目前的问题是：采用什么方式才能实现步骤1的效率最大化？（剩下步骤已有好的解决方案）
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常推送系统, 用mysql的比较少. 使用列存储, 文档型的nosql比较多,你也许可以换换思路.
如果非要用mysql的话,我只能猜测. 如果前提是一个用户可以有多个规则(或者可以分解为多个最小粒度规则),一个物品上线之后,要及时推送到符合订阅规则的用户. 那么你至少有两个表. A表记录一个用户id与他自己设置的多个规则的关系表. B表是每个规则与符合该规则的用户id的关系表.
新物品推送, 使用B表找到对应的多个用户ID. 而A表只是做简单的信息存储.
性能瓶颈主要出在写操作上. 你需要同时考虑两个表. 尤其是修改规则, 你需要去掉原有的规则映射关系. 添加新的. 而且基本上都是磁盘随即写. 不过鉴于你的业务实际情况,我觉得还好吧...
如果这样设计, 你主要一个现实问题 一个未来问题. 现实问题就是如何设置规则粒度(一般是全部维度组合),表的大小呢,基本上就是用户数X规则数, 好消息就是无论A表还是B表,都很容易拆表.未来问题就是你可以适当做些热点规则缓存.