大家好:在大型网站中如何更好的实现用户消息机制,我想到的方法有以下两个:
1、用户的新消息计数保存在一个表中,而消息本身保存在另外的表中,这样的话,获取用户新消息数很快,获取消息列表也比较快,但是,在没有采用事务的前提下,可能存在数据不一致性,就是新消息数和消息记录对不上的情况,不用事务有响应速度的考虑。
2、新消息和历史消息分开保存,新消息数要每次count,消息总数和消息列表要关联新旧消息两个表,不过,这样保证了数据一致性,也不存在过期数据清理的问题。
针对这需求我觉得应该分为两种方案: 如有更好的欢迎大家指教
第一:
SQL+存储过程+触发器+DLL调用的方法来实现数据实时
第二:
后台弄一个线程做定时查询(例如1秒钟2次查询),但这里就涉及到性能的问题,对于庞大的数据量我觉得有个方案
做个临时表
比如A表是原来的数据库表 那么把一个小时(时间自定)内的数据放到临时B表里,每隔1小时清空B表里的数据,要数据就索引B表里的数据,然后再做相应的处理
数据库更新成功之后, 用JMS来通知. 不管这个应用层是否在同一个JVM里, 扩展性不错.
从数据源入手,使用代理模式封装数据源,在其中解析sql命令,如果是涉及指定表的变更操作(如insert、delete、update)等,调用相关应用程序。
如果集群或者异构系统,那么用MemCache+JMS可能会比较合适一些。
两种方法
1:临时表然后一个守护进程不停扫表,然后进行任务分发处理
2:所有对关系改变的数据操作前加一个中间层,就是在数据操作的时候写消息然后用jms异步进行处理。用jms来保存和分发任务可以用开源的activemq