百万级用户量的站内信设计

1. 方案描述
该方案用于系统站内信功能模块在百万级用户量情况下的效率问题,只是后台管理员给前台用户发送站内信,用户与用户之间的发送不在讨论内。
2. 方案详情
假设系统的用户量达到了200W,活跃用户为10W,系统后台管理员要给全体用户发送一条感谢信,如果按照之前的存储方式,消息队列需要插入200W条数据,可是除了活跃的10W用户,其他用户都忘了自己有该网站的账号,他都有可能不再登陆该网站了,数据库保存的消息队列无意义了。

现表结构如下:

消息表
编号    ID    NUMBER
标题    TITLE    VARCHAR2(50)    50      
正文    CONTENTS    VARCHAR2(1000) 
发送状态    STATUS    NUMBER   
发送日期    SEND_DATE    DATE     
发送方式    SEND_TYPE    NUMBER    
最新创建人    FCU    VARCHAR2(50)    50     
更新人    LCU    VARCHAR2(50)    50 
创建时间    FCD    DATE          
最新更新时间    LCD    DATE           
删除标记    DELETE_TAG    CHAR(1)    1  


消息容器


编号    ID    NUMBER     
站内信ID    MESSAGE_ID    NUMBER  
收件人ID    MEMBER_ID    NUMBER   
是否已读    READ_STATUS    NUMBER   


会员表

主键    id    NUMBER        
会员编号    u_number    NUMBER   
电子邮箱    u_email    VARCHAR2(200)    200    
密码    u_passwd    VARCHAR2(50)    50     
企业认证    company_admit    NUMBER(1)    1      
帐号禁用    帐号禁用    NUMBER(1)    1      
创建人    FCU    NUMBER  
最后更新人    LCU    NUMBER   
首次创建时间    FCD    DATE      
最后更新时间    LCD    DATE       
删除标记    DETELE_TAG    char(1)    1 


在尽量不改变表结构的前提下,改变一下程序写数据库的方式:
后台管理员发送一条站内信,接收对象为全体会员,系统往站内信表插入一条站内信,其中发送方式区分接收的对象(0为全体发送,1为只发送给注册会员,2为只发送给企业会员,3为指定会员发送),这样,发送给全体会员的一条站内信暂时只生成了一条数据。

前台会员登陆的时候,根据会员自身的会员类型(普通会员,企业会员)查询站内信表中属于自己的最新消息(根据自己所持消息的最新时间与消息表的发送时间做比对),往消息容器中插入自身与所持消息的关联数据,默认未未读,在前台会员点击某一条未读站内信的时候,将容器中的对应站内信状态改为已读。

如果后台管理员只指定发送站内信给某几个会员,则往站内信表插入一条站内信后,将这几个会员与该站内信的关联直接往消息容器中写关联,不需要前台会员取。
另:因为改变了发送接收方式,后台管理员只指定发送站内信给某几个会员,但是站内信状态未未发送,只是保存草稿,需要往站内信主表增加一个字段,保存指定会员的id串,用于关联此草稿与指定会员的关联,此处就要求发送给指定会员的数量不能太多,需要限制。
这样,百万级用户量的系统,活跃度为10%的用户登陆系统,只生成了10W的数据,用户活跃度越低,此方案效率越明显,如果是100%活跃度的话,此方案和现有方法无区别。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
内信功能可以采用 Redis + Elasticsearch 的方案进行设计,具体的设计思路如下: 1. Redis 存储用户的内信列表,采用有序集合(ZSET)存储,以用户 ID 为 key,内信 ID 为 member,内信的发送时间戳为 score。用户收到新的内信时,将内信 ID 和发送时间戳作为 member 和 score 存储到有序集合中,同时更新用户的未读内信数量。 2. Elasticsearch 存储内信的详细内容,包括发送者、接收者、主题、内容、发送时间等信息。可以将内信的发送时间作为索引的时间字段,以便进行时间范围内的搜索。 3. 当用户需要查看内信列表时,先从 Redis 中获取用户的内信列表,然后通过内信 ID 到 Elasticsearch 中查询每封内信的详细内容,最后将内信列表和详细内容合并返回给用户。 4. 当用户发送一封新的内信时,先将内信的详细内容存储到 Elasticsearch 中,然后将内信 ID 和发送时间戳作为 member 和 score 存储到 Redis 中对应的用户有序集合中,同时更新接收者的未读内信数量。 5. 当用户读取一封内信时,将该内信的 ID 从用户的未读内信有序集合中移除,并更新未读内信数量。如果用户将该内信标记为已读,可以将该内信的状态存储到 Elasticsearch 中,以便进行已读/未读内信的筛选和搜索。 综上所述,采用 Redis + Elasticsearch 的方案进行内信功能的设计,可以实现高效的内信查询和搜索,并且支持内信的实时推送和消息提醒。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值