大家好，
第一次发帖，不要拍砖啊，哈哈。
目前正在设计消息系统这块，已经有了2种方案，都是比较不错的，但是现在纠结在消息持久化这块。
第一种比较传统：收到消息后直接存入数据库，标记未读，当用户刷新页面，或者跳转的时候，会拉取下未读消息，并显示在导航栏那里。
第二种比较前卫：用nodejs+socket.io+redis(sub/pub)做的，优点是不用刷新页面用户就可以直接收到提醒，而且引入scoket.io以后还能做很多事情，个人打算采用第二种。
但是现在纠结在消息的持久化方面，如果在web层做消息入库，那么我发现socket.io除了在用户不刷新页面的时候“弹一下”，真没什么用了。反正消息已经存进去了。
要么就是web只管往redis里面publish一个消息，由node这里统一入库，并通知。我第一次用nodejs,对性能没什么信心，主要是nodejs对mysql的操作方面。
想听听大家的意见和看法，谢谢！！
补充：刚才被一位qq好友一顿批评：
这你还用问吗？如果你采用第二种方案，当然是在nodejs做持久化了，你引入redis的pub/sub干什么用的啊！？不就是为了分布式吗？能从不同的地方发消息吗？难道我发一条消息还要先在你的数据库保存一下，再做redis的publish吗？如果是那样，你的nodejs可以扔了。。。。
还是想听听大家的意见。。。。。谢谢。。。。。
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
7
707
收藏
第一种明显更具有挑战性 高性能 高可用等特点了 何不尝试?
comet + redis
redis的数据落地
性能高，速度快
使用第一种，客户端轮询的方式进行接收下发的消息；
使用redis做计数器和消息队列，mc用来存储消息内容；
@土豆2015 你目前采用的是轮询还是？我目前也在做类似你这种需求， 不过我的需求是 客户端app ，另外咨询下你， 你设置的那个消息， 如果用户读消息之后怎么办？ （因为消息要持久化）
@土豆2015
其实不太同意以下的看法，不分布式也是需要持久化的
nodejs 的持久化就是依赖 redis 或者 mongodb 引入就是为了，如果只是单纯存在nodejs中的话，node进程停了消息丢了，去哪找回来
socket.io 其实就是每秒访问一次服务器,看有没有消息,效率不是很高