一般网站上都会消息提醒通知,如一个用户给另一个用户发了一条站内信,那么就会在网站顶部的导航栏上就会有一个消息提醒的数字来提示您有新消息。
上面只是一个简单例子,在实际项目中可能就会有多种类型的提醒,如某个用户给你留言了,就显示提醒“新留言x条”或者“新回复y条”等等吧。
我打算设计成把所有类型的消息提醒统一的放到一张表(notice)里,并标记用户是否已处理了这条消息提醒,在网站的前台就可以只统计这一张表就行了,比如用户A给用户B发送了一条私信,就在notice表里插入一条新的未读消息提醒,用来提醒用户,当用户B查看完成私信后,再回到这张notice表标记为已处理或者直接删除。
但是大数据量或高并发的时候就会存在一个问题,当用户已经查看完了新收到的私信后,去notice表做标记处理时,可能由于种种原因其对应的“未读消息提醒”还没有写进去,这时候就出问题了,当用户去请求是否有“未读消息提醒”时,刚好又写进去了,然后就提示用户有“新消息”,但是实际上用户早已处理掉了,只不过就是“未读消息提醒”延时了。
如果说统计新消息提醒,去各个业务(如私信,留言)中单独统计,然后合并,再通知给用户,这样做的话,怎么称得上是“消息通知系统”呢?总觉得这样是不合理的
对于消息通知系统,我的notice表是否有存在的意义呢,大家是怎么设计的?
回复内容:
一般网站上都会消息提醒通知,如一个用户给另一个用户发了一条站内信,那么就会在网站顶部的导航栏上就会有一个消息提醒的数字来提示您有新消息。
上面只是一个简单例子,在实际项目中可能就会有多种类型的提醒,如某个用户给你留言了,就显示提醒“新留言x条”或者“新回复y条”等等吧。
我打算设计成把所有类型的消息提醒统一的放到一张表(notice)里,并标记用户是否已处理了这条消息提醒,在网站的前台就可以只统计这一张表就行了,比如用户A给用户B发送了一条私信,就在notice表里插入一条新的未读消息提醒,用来提醒用户,当用户B查看完成私信后,再回到这张notice表标记为已处理或者直接删除。
但是大数据量或高并发的时候就会存在一个问题,当用户已经查看完了新收到的私信后,去notice表做标记处理时,可能由于种种原因其对应的“未读消息提醒”还没有写进去,这时候就出问题了,当用户去请求是否有“未读消息提醒”时,刚好又写进去了,然后就提示用户有“新消息”,但是实际上用户早已处理掉了,只不过就是“未读消息提醒”延时了。
如果说统计新消息提醒,去各个业务(如私信,留言)中单独统计,然后合并,再通知给用户,这样做的话,怎么称得上是“消息通知系统”呢?总觉得这样是不合理的
对于消息通知系统,我的notice表是否有存在的意义呢,大家是怎么设计的?
关于消息系统的设计,肯定是需要一个数据表记录通知的,比如Notice表,至于这个通知可能有很多类型,就像你说的 私信和留言,这些在设计中都可以通过字段表示,这里分享下 Worktile 中 Notice的数据结构设计。
{ nid: { type: String, unique: true }, published: { type: Number, default: Date.now }, verb: { type: String }, template: { type: String }, is_read: { type: Number, index: true, default: 0 }, is_pending: { type: Number, index: true, default: 0 }, filter: { ftype: { type: String } }, sender: { type: Actor }, receiver : { type: String , index: true}, data: { entity: { type: Entity }, source: { type: Entity }, target: { type: Entity } } }
具体细节设计可以参考 activity 的一个标准
至于你说的消息高并发的问题其实是没有问题的,你标记完未读消息为已读后在切换页面,这是再读取未读消息前面的标记为已读应该早就处理完了。除非你系统高并发的程度已经达到系统瘫痪了,在没有遇到瓶颈的时候不需要过度优化,即使到达瓶颈也有解决方案的,你可以把所有未读的消息放到内存或者redis中来提高性能。
上面说的是数据结构方面的东西,一般web的消息都是实时更新的,意思就是:你没有刷新页面,此时来消息了,应该立即显示未读消息多少条。关于实时消息系统的做法要取决于你服务端用的什么语言。Node.js+socket.io
就很容易做到,我们的产品Worktile是采用erlang语言实现的
感觉就是系统有了瓶颈,需要一层消息缓存了,直接数据库读写消息效率偏低了,因为数据库在写的时候可读导致数据不一致,消息存在内存中楼上的redis或者memcache中,如果还是会出现写,读不一致的情况,应该横向拓展了吧!
相关文章:

使用數據庫存儲會話的主要優勢包括持久性、可擴展性和安全性。 1.持久性:即使服務器重啟,會話數據也能保持不變。 2.可擴展性:適用於分佈式系統,確保會話數據在多服務器間同步。 3.安全性:數據庫提供加密存儲,保護敏感信息。

在PHP中實現自定義會話處理可以通過實現SessionHandlerInterface接口來完成。具體步驟包括:1)創建實現SessionHandlerInterface的類,如CustomSessionHandler;2)重寫接口中的方法(如open,close,read,write,destroy,gc)來定義會話數據的生命週期和存儲方式;3)在PHP腳本中註冊自定義會話處理器並啟動會話。這樣可以將數據存儲在MySQL、Redis等介質中,提升性能、安全性和可擴展性。

SessionID是網絡應用程序中用來跟踪用戶會話狀態的機制。 1.它是一個隨機生成的字符串,用於在用戶與服務器之間的多次交互中保持用戶的身份信息。 2.服務器生成並通過cookie或URL參數發送給客戶端,幫助在用戶的多次請求中識別和關聯這些請求。 3.生成通常使用隨機算法保證唯一性和不可預測性。 4.在實際開發中,可以使用內存數據庫如Redis來存儲session數據,提升性能和安全性。

在無狀態環境如API中管理會話可以通過使用JWT或cookies來實現。 1.JWT適合無狀態和可擴展性,但大數據時體積大。 2.Cookies更傳統且易實現,但需謹慎配置以確保安全性。

要保護應用免受與會話相關的XSS攻擊,需採取以下措施:1.設置HttpOnly和Secure標誌保護會話cookie。 2.對所有用戶輸入進行輸出編碼。 3.實施內容安全策略(CSP)限制腳本來源。通過這些策略,可以有效防護會話相關的XSS攻擊,確保用戶數據安全。

优化PHP会话性能的方法包括:1.延迟会话启动,2.使用数据库存储会话,3.压缩会话数据,4.管理会话生命周期,5.实现会话共享。这些策略能显著提升应用在高并发环境下的效率。

theSession.gc_maxlifetimesettinginphpdeterminesthelifespanofsessiondata,setInSeconds.1)它'sconfiguredinphp.iniorviaini_set().2)abalanceisesneededeededeedeedeededto toavoidperformance andunununununexpectedLogOgouts.3)

在PHP中,可以使用session_name()函數配置會話名稱。具體步驟如下:1.使用session_name()函數設置會話名稱,例如session_name("my_session")。 2.在設置會話名稱後,調用session_start()啟動會話。配置會話名稱可以避免多應用間的會話數據衝突,並增強安全性,但需注意會話名稱的唯一性、安全性、長度和設置時機。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

SublimeText3 英文版
推薦:為Win版本,支援程式碼提示!

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

mPDF
mPDF是一個PHP庫,可以從UTF-8編碼的HTML產生PDF檔案。原作者Ian Back編寫mPDF以從他的網站上「即時」輸出PDF文件,並處理不同的語言。與原始腳本如HTML2FPDF相比,它的速度較慢,並且在使用Unicode字體時產生的檔案較大,但支援CSS樣式等,並進行了大量增強。支援幾乎所有語言,包括RTL(阿拉伯語和希伯來語)和CJK(中日韓)。支援嵌套的區塊級元素(如P、DIV),

禪工作室 13.0.1
強大的PHP整合開發環境