前言
一款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即可。
当然,消息列表的存储,读取,就比较多样了。可以是MySQL,nosql,hbase,redis。一般我们是混合存储,特别老的存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 发布!