1）seq：自增长的序列号，每条消息对应一个（见：《微信的海量IM聊天消息序列号生成实践》）；
6）appinfo：每条消息对应的唯一strid，全局唯一。同一条消息的appinfo在所有的接收方中是相同的。

这块怎么理解呢，为什么有了 seq 还需要 appinfo？
按我的理解，seq 应该已经是每条消息的唯一标识了 (就是递增的消息 ID)，那为什么还需要一个全局唯一的 appinfo 呢？

消息回执没看太明白，谁有解读链接

引用：Frank 发表于 2023-05-10 19:53
es 就是搜索； 可以看下lucene 想怎么建索引都可以的。专为搜索而生。

专业

引用：ZJoker 发表于 2022-11-06 02:29
大佬，如果用es ，es的index怎么设计 ，怎么去存在，index按群id为单位吗

es 就是搜索； 可以看下lucene 想怎么建索引都可以的。专为搜索而生。

引用：JackJiang 发表于 2021-07-20 11:22
你去了解一下 elasticsearch

大佬，如果用es ，es的index怎么设计 ，怎么去存在，index按群id为单位吗

引用：椎锋陷陈 发表于 2021-08-30 10:46
总结来讲，通篇文章看下来，感受最深的就是以下两点：
策略降级：没肉包就吃馒头，反正都是填饱肚子。
体 ...

说的通俗

总结来讲，通篇文章看下来，感受最深的就是以下两点：
策略降级：没肉包就吃馒头，反正都是填饱肚子。
体验优先：干就完了，失败了我再跟你说。

对于文章中的「柔性策略」这一块，想说一下自己的理解。

引用：im系统对及时性要求比较高，没办法进行削峰处理

这里的及时性指的应该是对「发送方消息发送状态获知」的及时性，而非「接收方接收到消息」的及时性，否则下文的Hold住请求异步处理应该并实际没有解决「及时性」的问题。

这里整个的过程我认为可以用双11寄收快递来类比，
高峰期系统压力大，偶发的网络波动或者机器过载，都有可能导致大量的系统失败->
双11包裹量剧增，分拣员忙不过来严重累垮，快递点爆仓。

im系统对及时性要求比较高，没办法进行削峰处理->
本来可以临时租用另外一个仓库用于存储快件，原仓库分拣员正常工作，实际揽收了再去修改订单状态。
但对于买家来讲，就会看到订单状态一直是处于「待揽收」的状态，内心焦急。

如果svr过载，则拒绝掉部分正常请求，防止机器被压垮，依然能对外服务->
超出快递点工作能力后，快递点就不再揽件，告知情况并让其晚点再寄。

系统过载返回失败，前端发消息显示失败，显示红点，会严重影响产品体验->
快递点居然不揽件？用户内心有怨言。

逻辑层hold住失败请求，返回前端成功，不出红点，后端异步重试，直至成功->
同样是临时租用另外一个仓库用于存储快件，但这次是及时告知用户包裹「已揽收」，原仓库分拣员正常工作，就是用户实际收到包裹可能会晚点。

当然以上只是我为方便理解举的例子，与实际快递点的流程处理可能不一致。

引用：daydayup 发表于 2021-07-31 13:14
发送的消息，通过MQ异步写入接收方存储，如何保证顺序性？

理论上说服务端是很难严格控制消息顺序的，因为顺序和异步本身就是矛盾体，不过消息id是趋势递增，客户端可对消息顺序进行兜底

发送的消息，通过MQ异步写入接收方存储，如何保证顺序性？

引用：Monkey 发表于 2021-07-20 19:40
很硬核，要是有微信类MapReduce异步队列的方案介绍就好了

暂时还没有这方面深入的分享文章

很硬核，要是有微信类MapReduce异步队列的方案介绍就好了

引用：逍遥小子 发表于 2021-07-20 13:05
谢谢楼主分享。
有几个问题想请教下
这里的消息收发模型，是推拉结合的方式

推拉结合，说到底就是用牺牲实时性换性能。

1、会话消息指的是聊天界面里聊天内容，会话列表你可以认为是类似于打开微信界面后首页的那个“消息”列表。
2、这个可以用来辅助消息排序等

谢谢楼主分享。
有几个问题想请教下
这里的消息收发模型，是推拉结合的方式
1、这样的方式是适合单聊群聊两种吗？
2、推拉结合的优势相比单推单拉有什么优势呢？
3、推拉结合方式推过去的只是一个通知吗？具体内容可以有什么呢？

关于消息扩散模型的方式
1、会话列表和会话消息，这里的会话指的是临时会话嘛？会话要存在服务端嘛？要怎么存储?
2、文中扩散读的缺点中，说到每个会话都会维护一个序列号，这个序列号有什么用呢？


刚开始接触IM，提问的有点多，麻烦楼主有空看到解答下哈，十分感谢

引用：小张 发表于 2021-07-19 21:45
我这边的场景是面向企业，用户说啥，基本就要尽量满足啥。我们的聊天记录也不多，1个月也就是千来万（纯 ...

你去了解一下 elasticsearch

引用：JackJiang 发表于 2021-07-19 20:08
聊天记录这种数据，对于个人而言，跟普通电商里的订单这类数据相比，价值很低。服务端要存，也最多只存一 ...

我这边的场景是面向企业，用户说啥，基本就要尽量满足啥。我们的聊天记录也不多，1个月也就是千来万（纯聊天，不包括应用类消息）。如果要真实现服务端搜索，有什么好架构介绍吗？

引用：小张 发表于 2021-07-19 16:33
但是，消息量巨大，比如有个50-100G。那是否放到es这种中间件？那会扩散的更大的数据量了吧？

聊天记录这种数据，对于个人而言，跟普通电商里的订单这类数据相比，价值很低。服务端要存，也最多只存一定期限内的记录。从个人而言，比如你自已，绝大多数情况下，几个月以前的聊天，我想信你再也不会再回头去看了，有啥意义。所以服务端即使存也都是热数据，热数据，除非你是微信这种量级，一般情况下，都不会有那么夸张

引用：JackJiang 发表于 2021-07-19 15:41
服务端有消息记录就能搜索。本地搜索是因为像微信这种，号称不存储用户聊消息（张小龙说他看不到你的聊天 ...

但是，消息量巨大，比如有个50-100G。那是否放到es这种中间件？那会扩散的更大的数据量了吧？

引用：小张 发表于 2021-07-19 15:38
楼主，漫游IM消息，客户端聊天记录搜素功能。是不是基本都是本地搜索？没有很好的办法做到服务端搜索吧？

服务端有消息记录就能搜索。本地搜索是因为像微信这种，号称不存储用户聊消息（张小龙说他看不到你的聊天），做不到服务端搜索，而且也不经济。