企业网站策划案,网站做游戏活动,建筑图纸字母代号大全图解,精选赣州网站建设前言
一款app#xff0c;消息页面有#xff1a;钱包通知、最近访客等各种通知类别#xff0c;每个类别可能有新的通知消息#xff0c;实现已读、未读功能#xff0c;包括多少个未读#xff0c;这个是怎么实现的呢#xff1f;比如用户A访问了用户B的主页#xff0c;难道…前言
一款app消息页面有钱包通知、最近访客等各种通知类别每个类别可能有新的通知消息实现已读、未读功能包括多少个未读这个是怎么实现的呢比如用户A访问了用户B的主页难道用rabitmq给B发通知消息吗量大了成本受得了吗有没有成本低的方案呢 小谈
挺好的一个问题可惜其他的回答要么是大而化之想当然要么是顾左而言他没有一个正经的回答。
这个是很常见的需求在做这类需求的时候首先要做的是设计一个合适的业务模型那么这个模型就是“对话模型”
将问题中的设置“赚钱积分”,最近听众,好友跟新最近来访当做一个“虚拟人”来处理你跟虚拟人组成了一个对话列表(msg_group)
“虚拟人”与正常人的区别就是虚拟人与你的对话是单向的只能他向你发消息你无法回复。
所有判断有没有小红点或者小红点的数字是多少就是简单的获取你与虚拟人的对话的未读的消息的数量。
“最近来访”标签
当有人访问你主页的时候后端会以这个“最近来访”虚拟人的身份给你发一条消息不过消息里还有一个特殊标记标明了来源。我们除了要拉取总量还有不同来源消息的数量。当然一个动作不一定只发一条消息比如图中下方有个金刚键消息它是所有消息的总和所以投递其他消息的时候也要给它投递一次不过它只展示一个未读数字所以这个消息只需要一个msg_id即可不需要消息payload。
前端怎么展示
看具体产品需求。
每个对话可以看作一个msg_group它是一个消息的队列(注意不是我们常说的消息队列),每条msg的msg_id都是有序递增的至于msg_id只是队列内有序还是全局有序就看你选择了,一般数据10亿以内没必要优化发号器全局有序即可。这个队列有基本的信息:参与人(图中的例子只有2个你和“虚拟人”)maximal_msg_id。
你只需要保存一个last_pull_msg_id或last_read_msg_id即可在拉取信息的时候带上这个last_msg_id即可。
当然消息列表的存储读取就比较多样了。可以是MySQLnosqlhbaseredis。一般我们是混合存储特别老的存hbase比较老的存mysq或nosql新数据存redis。云厂商也有专门针对这类场景的存储产品。大多数情况我们只需要一个数量固定从maximal_id往前取如果取到100条还没完直接返回99完事了。
实际上图中的需求比如“设置”隐私设置是整个产品全局的所以可以弄个简单的广播消息模式广播模式就是维持一个单向的消息的队列所有的人都可以拉取这个队列的消息只需要他们各位维护自己的last_id即可。
已读和未读。它包含两层意思一个判否即内容你是否读过二是计数即这个内容有多少人读过。
长尾原因
如果你用Redis存储成本非常高浪费非常严重。如果不用redis一旦刷到历史数据会非常非常慢。在这里bitmap肯定是搞不定的因为bitmao需要加载全部数据显然不可行。
这个时候通常的策略是[log record]和comb, 我们每产生一个动作比如读赞收藏就会产生一个log record( 取关取消赞...也是一条独立的log record)我们由专门的大数据系统统一收集这些record然后对多个维度的数据统计将统计结果存起来前端获取数据的时候先从缓存取取不到再到comb取。comb的数据规模是远远小于log record的查询速度非常快。
log record因为不涉及查询所以没必要用数据库一般直接存hbase或cassandra这类廉价存储介质。
热门内容
用户互动非常活跃所以在写入log record的时候会直接同步更新缓存但是缓存的数据并不保证十分准确它只是迷惑用户的准确的数据是以log record为准的你在wb经常可以看热门内容的点赞数跟实际的数量不符。因为wb的缓存独立的counter实际的数据不同步。 本文由博客一文多发平台 OpenWrite 发布
