更有甚者，钉钉的群聊“强制已读回执”功能，甚至能够知道谁读了消息，谁没有读消息（老板的福音啊）。 那么群聊消息的收发流程、消息的送达保证、已读回执机制，到底该怎么实现呢？这就是今天要讨论的话题。...6、已读回执流程的设计 前面的基础知识我们已经了解的差不多，本节来讨论本文的重点内容，即群聊已读回执流程到底该怎么设计。...这里的初步结论是： 如果发送方在线：会实时被推送已读回执； 如果发送方不在线：会在下次在线时拉取已读回执。...8、本文小结 对于群消息已读回执，一般来说： 如果发送方在线，会实时被推送已读回执； 如果发送方不在线，会在下次在线时拉取已读回执。...如果要对进行优化，可以： 接收方累计收到N条群消息再批量ack； 发送方轮询拉取已读回执。 物理删除已读回执数据，定时删除或归档非核心历史数据。
微信用于个人社交，产品设计上，在线状态，强制已读回执都有可能暴露个人隐私，故微信并无相关功能。 钉钉用于商务交流，其“强制已读回执”功能，让职场人无法再“假装不在线”，“假装没收到”。...二、已读回执流程 对于发送方发送的任何一条群消息，都需要知道，这条消息有多少人已读多少人未读，就需要一个基础表来记录这个关系。 消息回执表：用来记录消息的已读回执。...（如果发送方在线） 如果发送方不在线，ta会在下次登录的时候： （5）从关联表里拉取每条消息的已读回执 这里的初步结论是： 如果发送方在线，会实时被推送已读回执 如果发送方不在线，会在下次在线时拉取已读回执...答：回执数据不是核心数据 已读的消息，可以进行物理删除，而不是标记删除 超过N长时间的回执，归档或者删除掉 四、总结 对于群消息已读回执，一般来说： 如果发送方在线，会实时被推送已读回执 如果发送方不在线...，会在下次在线时拉取已读回执 如果要对进行优化，可以： 接收方累计收到N条群消息再批量ack 发送方轮询拉取已读回执 物理删除已读回执数据，定时删除或归档非核心历史数据 推送还是拉取？
收发消息双方需存在至少一种关系才允许发消息； 2）回执消息：每条消息都需记录已读和未读人员列表，涉及频繁的状态读写操作； 3）撤回消息：支持24小时的有效期撤回动作； 4）消息存储：云端存储时间跨度长，...例如：回执消息，发送方能看到已读未读列表，接受方只能看到是否已读的状态。云端删除某条群消息，在自己的消息列表消失，其他人还是可见。 缺点：存储容量的增加。...=a1，追加写入到a的消息流； 5）接收方c已读同一条消息，在c的消息流走同样的逻辑； 6）发送方a，读出msgid=a1的消息体，把c加入到已读列表，把新的已读列表保存到消息体中，生成新消息msgid...11.4 优化2：合并处理 客户端收到大量消息，并不是一条一条消息已读确认，而是多条消息一起已读确认。为了提高回执消息的处理效率，可以对多条消息合并处理。...流程如下： 1）发送方某条消息的已读状态是X； 2）接收方a确认已读，已读状态修改为X+a； 3）接收方b确认已读，已读状态修改为X+b； 4）接收方a的状态先写入，接受方b的状态后写入。
前提： 假如现在有2个模块需要提示消息：只要存在用户在上个时间点之后没有看过的信息就提示用户有新的信息 思路如下： 使用hash存储用户上次看过的时间，使用so...
假如现在有2个模块需要提示消息：只要存在用户在上个时间点之后没有看过的信息就提示用户有新的信息
一朋友和我讨论他前段时间面试某大公司的一题目 ： 企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成...x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid...（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？...仔细分析，按照目前的设计，每一条消息，已读未读详情就要占用8B * 群成员数的内存，如果一个活跃的200人大群，每发一条消息，已读未读就要1600B，如果平均每天消息量是1k，那每个这样的群，每天就要1.6MB...1、增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计 2、每个成员已读未读由8B（64bit）优化成2bit，减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8
x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid...（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？...仔细分析，按照目前的设计，每一条消息，已读未读详情就要占用8B * 群成员数的内存，如果一个活跃的200人大群，每发一条消息，已读未读就要1600B，如果平均每天消息量是1k，那每个这样的群，每天就要1.6MB...其实未读已读就是一个0/1的标记而已，可以维护一个bitmap来实现呢？具体应该怎么做呢？...增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计 每个成员已读未读由8B（64bit）优化成2bit，减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8) *
前言 一款app，消息页面有：钱包通知、最近访客等各种通知类别，每个类别可能有新的通知消息，实现已读、未读功能，包括多少个未读，这个是怎么实现的呢？...所有，判断有没有小红点，或者小红点的数字是多少，就是简单的获取你与虚拟人的对话的未读的消息的数量。..."已读和未读"。它包含两层意思，一个判否，即内容你是否读过，二是计数，即这个内容有多少人读过。 长尾原因 如果你用Redis存储，成本非常高，浪费非常严重。...这个时候，通常的策略是"[log record]"和"comb", 我们每产生一个动作，比如读，赞，收藏，就会产生一个log record( 取关，取消赞...也是一条独立的log record)，我们由专门的大数据系统统一收集这些
前言 本文我们基于飞书开放平台提供的服务端SDK，展示下如何查询一个消息有哪些人已读了。...= nil { fmt.Println(err) return } // 读取已读信息 ReadUsersMsg(client, msgID)...// 读取已读信息 ReadUsersMsg(client, msgID) } debug运行，然后再ReadUsersMsg处断点，然后再飞书上读消息后，继续运行结果如下： image.png
BigTable 数据模型 已读服务虽然从业务模式看非常简单，但它在技术上的挑战确并不低。目前知乎已读的数据规模已超万亿并以每天接近30 亿的速度持续高速增长。...已读的业务需求可以非常直观的映射到 BigTable 的数据模型上。...已读服务核心业务指标 全面云化，面向未来 从已读的业务指标上看我们交出了一份还让人满意的答卷，但作为已读服务的开发和运维人员我们深知目前的这套架构还存在着一些核心的痛点没有解决好。...带着已读服务的这些问题我们于近期开始了新一轮的迭代，本轮迭代的核心目标是将已读服务全面云化，达到全系统高可用规模随需扩展的目标。...计算存储分层的分布式数据库架构 考虑到已读服务过去构建于MySQL 技术上，相比之下兼容 MySQL 的 TiDB 比 CockroachDB 对已读服务有着更低的迁移门槛。
Google Gmail邮箱一次性标记所有未读邮件为已读 Google Gmail邮箱一次性标记所有未读邮件为已读 和许多 Gmail 用户一样，您的收件箱中也可能塞满了数百甚至数千封未读电子邮件...5000封邮件的用户无疑是个灾难，本文 晓得博客 为你介绍 Google Gmail 邮箱一次性标记所有未读邮件为已读的方法。...怎么批量将 Gmail 电子邮件标记为已读 这是将所有电子邮件标记为已读的最快、最简单的方法： 如有必要，请转至mail.google.com并登录。...单击超链接部分 单击顶部工具栏中的“ 标记为已读 ”，弹出如图所示，点击” 确定 ”即可。...从顶部工具栏中选择“ 标记为已读 ”图标，点击后即可标记选定的Gmail邮件为已读。
，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了...），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？...上就好了，客户端更新到messageid对应的详情列表，就可以展示m人已读，n人未读 显然这么简单粗暴的方案面试官是不会满意的，追问有没有更好的方案呢？...仔细分析，按照目前的设计，每一条消息，已读未读详情就要占用8B * 群成员数的内存，如果一个活跃的200人大群，每发一条消息，已读未读就要1600B，如果平均每天消息量是1k，那每个这样的群，每天就要1.6MB...增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计 每个成员已读未读由8B（64bit）优化成2bit，减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8) *
于是也看到了别人的方案： 发送者发送消息给服务端 服务端接收到消息后发送回执给发送者 发送者确认收到则结束，如果未收到就重发 服务端将消息记录一下，并推送给接收者，等待接收者的回执 接收者接收消息并发回执给服务端...服务端接收回执删除掉消息回执记录，表示已经发送完毕 如果一定时间内没收到重新推送消息给客户端 接收者如果收到消息进行去重处理，如果不重复的执行第5-6步 这个流程基本就是完成了消息回执的功能，核心点就是在于发送者...基本的设计思路也有了： 客户端维护两个列表（发送回执队列和接收回执队列），用于保存发送/接收消息回执情况 服务端也维护一个列表，用于记录消息回执的接收与发送情况，服务端对列表进行超时检查，如果回执未发送的重发消息...，如果收到重复的消息则去重处理 客户端定期检查两个列表里的回执状态，如果未收到回执的要做重发处理，如果收到的是重复的回执则进行去重处理 方案差不多有了，只不过在检阅网上资料时有了新的发现。...柳暗花明 在看别人的总结时发现XMPP有扩展协议是支持消息回执功能的，就是XEP-0184.了解下来这个协议确实是一套消息回执的实现方法，但是呢。。
Problem Description 时间过的好快，一个学期就这么的过去了，xhd在傻傻的看着表，出于对数据的渴望，突然他想知道这个表的时针和分针的夹角是...
1、引言 IM系统中，特别是在企业应用场景下，消息的已读未读状态是一个强需求。 以阿里的钉钉为例，钉钉的产品定位是用于商务交流，其“强制已读回执”功能，让职场人无法再“假装不在线”、“假装没收到”。...更有甚者，钉钉的群聊“强制已读回执”功能，甚至能够知道谁读了消息，谁没有读消息（老板的福音啊）。 ▲ 钉钉里的群聊消息已读未读功能效果 功能看起来很酷，但用起来是一言难尽（上班族心里苦.... ）。...3、相关文章 如果你还想了解更多有关IM群聊中已读未读功能的实现逻辑，可以进一步阅读干货文章《IM群聊消息的已读回执功能该怎么实现？》（强烈推荐）。...如果你对IM中的已读未读功能有产品方面的痛点困惑，可以参考一下微信对已读未读功能的设计定位，详见《IM热门功能思考：为什么微信里没有消息“已读”功能？》。...服务端收到小宝的已读通知时，需完成以下事项： 1）存储消息的已读状态； 2）返回应答给小宝； 3）向已读列表的消息的原始发送者通知消息已读。
选课时间(题目已修改,注意读题) Time Limit: 1000/1000 MS (Java/Others) Memory Limit: 32768/32768 K (Java/Others)
下拉刷新、加载更多、标记已读、轮播条、缓存 下拉刷新------- 1.addHeaderView必须在setAdapter之前调用 2.将paddingTop设置一个headerView高度的负值去隐藏它...position, long id) { System.out.println("被点击:" + position); // 35311,34221,34234,34342 // 在本地记录已读状态...mNewsList.get(position).url); mActivity.startActivity(intent); } }); return view; } /** * 改变已读新闻的颜色
发送者如果在App上做别的事情，根本不需要关心当前有多少人已读。因此直接推送已读确认也不合适。 如果变为客户端查看的时候主动拉取呢？...具体做法如下 1、客户端打开会话，查看回执消息时，通过短连接向服务端拉取未读人数。...2、同时客户端向服务端请求订阅该条消息的回执消息（退出这个会话取消订阅） 3、服务端收到此消息的已读确认消息，向用户推送 这样看似较完美，实际上仍然面临推消息的挑战。...1、User1发出一条回执消息，其他用户（User2、User3……UserN）读取消息后，向服务端发送已读确认消息。...服务端进行未读人数计算，并缓存 2、User1在查看回执消息时，主动拉取已读人数或未读人数 主动拉取策略怎么设置呢？ 用户查看回执消息时，20秒之内，每2秒拉取一次；如果用户退出会话则停止拉取。
有时候我们需要展示一些内容,如果等所有内容都加载完毕再展示这样反而会降低用户体验; 因为如果消耗时间长那么用户需要瞪着空白的页面,反而会失去兴趣; 所以我们...
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
