知乎MQ消息推送架构的设计缺陷是啥
首先我不是开发人员，其实我觉得APP在这个上面是有点点个小bug的，我说一说，不一定对，仅供大家参考，现在消息系统是分两块，一块是主动刷新，一块是被动推送。
我以回答问题这个功能为说明说一下，下面是被动推送流程：
1、张三，李四，王五同时关注了问题
2、当钱七回答了问题时：
3、有一个线程专门负责把数据库里的推送信息发送到消息服务器（非实时，有延迟）
4、推送消息给用户，并通知数据库修改推送状态（非实时，有延迟），由于网络延迟，用户离线等原因，推送消息并非100%可靠的，如下图，如果王五离线了，消息服务器在尝试一定次数后，就不再推送了。
5、由以上看来，用户是不直接和数据库直接打交道的，而是被动接收消息服务器发过来的消息内容。
6、假如用户在这个延迟推送的过程中（第3、4步还未收到推送消息）去刷新消息列表（触发主动刷新），APP要保证用户操作的实时性，才不管是不是在推送中，直接拿到最新的结果去更新APP显示的内容。
7、这时候消息服务器推送消息过来了，其实我们已经主动刷新了APP消息列表，但APP可能有bug存在，并没有去验证这条消息是否已经刷新存在本地了，还去显示小蓝点点，增加未读信息条数等，与实际数字不一致，造成重复推送的假象，其实只推送一次。建议APP在主动刷新时先本地前检查一下这个消息ID是否已经到了本地，如果到了，APP端处理一下，偷偷过滤掉即可。关于延时问题，服务端是可以增加消息服务器来解决问题，但受制于用户网络等各种因素，消息丢失不可避免，反复重试推送又会增加服务器压力，这个需要折中处理。
注：1、以上推送流程是简化后的流程，实际中更为复杂。
2、上面说的持久化数据库中的数据库不一定是关系型数据库，有可能是NOSQL等。
3、以上回答是我的个人理解，如果有误，请高人指出。
■网友
根据我粗浅的表面使用感官，有几个方面可能可以讨论
既然消息提示和消息本身是两个message，消息提示并不带有复核信息，这样消息提示到了，消息还没到，还不如复核，消息没到之前消息提示显示
消息数量提示发送早于消息本身这个是没问题，因为点消息还刷了一下，那么就是刷这一步出了问题，在无法快速调整代码框架和服务器硬件的情况下，不如把消息仅显示未读，这样减少网络数据量
我看我海外访问的节点是新加坡akamai的CDN节点，这个上面是不是有速度损失，这个就不是我一个客户端能知道的了
架构再好，也怕烂infra，这个先确定不是网络的锅。
谁有空抓几个包看看服务器推过来的是什么样的格式，反过来推测下
hmmm，我实在是闲的，我懂了。
你看，如果你开Dev Tool，可以抓到的通知是这个api
推荐阅读
- ■个税扣缴新方式来了！对年收入不超过6万元的人来说是个好消息
- 为啥知乎上普便有一种【我在北上广深打工，所以拥有更好的视野】这样的错觉
- 骨裂|
- 知乎有没有必要增加一个特别关注功能
- SUV|小道消息传大众将在美国和欧洲停售帕萨特，这是几个意思？
- 就业政策|
- 怎样评价3月10日起外资企业不能在中国大陆提供视听服务这一消息
- 知乎上关于人生经验的介绍是否可能对青少年造成潜在危害
- 像知乎豌豆夹这种新兴互联网公司发展的实际状况咋样
- 只看报纸、杂志、知乎、微博等文字而很少阅读书籍的人，和喜欢看书的延迟接受信息的人，哪种会比较优秀呢