关于即时通讯:即时通讯技术文集第34期IM群聊技术合集Part1-共15篇

40次阅读

共计 2613 个字符,预计需要花费 7 分钟才能阅读完成。

为了更好地分类浏览 52im.net 总计 1000 多篇精编文章,我将在每周三推送新的一期技术文集,本次是第 34 期。

[- 1 -] 疾速裂变:见证微信弱小后盾架构从 0 到 1 的演进历程(一)

[链接] http://www.52im.net/thread-168-1-1.html

[摘要] 2 个月的开发工夫,微信后盾零碎经验了从 0 到 1 的过程。从小步慢跑到疾速成长,经验了平台化到走出国门,微信交出的这份优异答卷,解题思路是怎么的?

[- 2 -] 如何保障 IM 实时音讯的“时序性”与“一致性”?

[链接] http://www.52im.net/thread-714-1-1.html

[摘要] 实时音讯时序和一致性是分布式系统架构设计中十分难的问题(尤其 IM 利用这种以音讯为核心的利用状态),艰难在哪?有什么常见优化实际?这就是本文要探讨的内容。

[- 3 -] IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”?

[链接] http://www.52im.net/thread-715-1-1.html

[摘要]“用户在线状态的一致性”(单聊好友在线状态、群聊用户在线状态)是 IM 应用领域比拟难解决的一个技术问题,如何精准实时的取得好友、群友的在线状态,是明天将要探讨的话题。

[- 4 -]IM 群聊音讯如此简单,如何保障不丢不重?

[链接] http://www.52im.net/thread-753-1-1.html

[摘要] 因为“音讯风暴扩散系数”的存在(概念详见《IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”?》),群音讯的复杂度要远高于一对一的单聊音讯。群音讯的实时性、可达性、离线音讯是明天将要探讨的外围话题。

[- 5 -] 微信后盾团队:微信后盾异步音讯队列的优化降级实际分享

[链接] http://www.52im.net/thread-801-1-1.html

[摘要] 本文分享了该组件 2.0 版本的性能特点及优化实际,心愿能为相似业务(比方挪动端 IM 零碎等)的音讯队列设计提供肯定的参考。

[- 6 -] 挪动端 IM 中大规模群音讯的推送如何保障效率、实时性?

[链接] http://www.52im.net/thread-1221-1-1.html

[摘要] 当然,理论在生产环境下,群音讯的发送都会想尽办法进行压缩,并发展各种改善性能的解决方法,而不是像上述举例里的间接扩散写(即 2000 人群里,一条音讯被简略地复制为 2000 条一对一的音讯投递)。具体有哪些优先策略?本文或者能够带给你一些启发。

[- 7 -] 古代 IM 零碎中聊天音讯的同步和存储计划探讨

[链接] http://www.52im.net/thread-1230-1-1.html

[摘要] 本文内容次要波及 IM 零碎中的音讯零碎架构,探讨一种实用于大用户量的音讯同步以及存储系统的架构实现,可能反对音讯零碎中的高级个性『多端同步』以及『音讯漫游』。在性能和规模上,可能做到全量音讯云端存储,百万 TPS 以及毫秒级提早的音讯同步能力。

[- 8 -] 对于 IM 即时通讯群聊音讯的乱序问题探讨

[链接] http://www.52im.net/thread-1436-1-1.html

[摘要] 问题形容:客户端 A、B、C,服务端 S,例如:A 发三条群音讯,B、C 收到的音讯都是乱序,目前问题:A 发第一条音讯失败之后排到队列,这时服务端还在继续发消息,那么第二条音讯送达到 B、C,而后客户端最先显示的就不是第一条音讯,导致乱序呈现。

[- 9 -] IM 群聊音讯的已读回执性能该怎么实现?

[链接] http://www.52im.net/thread-1611-1-1.html

[摘要] 那么群聊音讯的收发流程、音讯的送达保障、已读回执机制,到底该怎么实现呢?这就是明天要探讨的话题。

[- 10 -] IM 群聊音讯到底是存 1 份 (即扩散读) 还是存多份(即扩散写)?

[链接] http://www.52im.net/thread-1616-1-1.html

[摘要] 任何技术计划,都不是蠢才般灵感乍现想到的,肯定是一个演进迭代,逐渐优化的过程。明天就聊一聊,IM 群聊音讯,为啥只须要存一份。

[- 11 -] 一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际

[链接] http://www.52im.net/thread-2015-1-1.html

[摘要] 本文将分享的是一套生产环境下的 IM 群聊音讯零碎的高可用、易伸缩、高并发架构设计实际,属于原创第一手材料,内容较业余,适宜有肯定 IM 架构教训的后端程序员浏览。

[- 12 -] [技术脑洞] 如果把 14 亿中国人拉到一个微信群里技术上能实现吗?

[链接] http://www.52im.net/thread-2017-1-1.html

[摘要] 听到这个问题,全厂的人都炸了。要晓得一个微信群最多只能有 500 人啊,QQ 群也只有 2000 而已。当你有机会退出一个 2000 人 QQ 群的时候,你就曾经感触到“信息爆炸”的可怕……

[- 13 -] IM 群聊机制,除了循环去发消息还有什么形式?如何优化?

[链接] http://www.52im.net/thread-2213-1-1.html

[摘要] 目前我是用循环来获取群成员,而后获取群成员 ID 去循环调用 senddata()办法,想不必循环或者用其余什么形式来优化群聊循环发送这个机制,各位大佬有什么方法没?

[- 14 -] 网易云信技术分享:IM 中的万人群聊技术计划实际总结

[链接] http://www.52im.net/thread-2707-1-1.html

[摘要] 本文内容是网易云信团队为了响应万人群聊性能需要,在设计实现万人群聊技术计划中总结的技术实际,借此机会分享给各 IM 开发者同行。

[- 15 -] 阿里钉钉技术分享:企业级 IM 王者——钉钉在后端架构上的过人之处

[链接] http://www.52im.net/thread-2848-1-1.html

[摘要] 本文适宜有肯定 IM 后端架构设计教训的开发者浏览,或者出于商业产品技术秘密的思考,分享者在本次所分享的内容上有所保留,鉴于阿里对于钉钉在技术上的内容分享做的非常少,所以本文尽管内容不够全面,但依然值得一读。

👉52im 社区本周新文:《抖音技术分享:飞鸽 IM 桌面端基于 Rust 语言进行重构的技术选型和实际总结》,欢送浏览!👈

我是 Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

正文完
 0