- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构师之路
im协议设计选型（上）
im协议设计选型（上） 周末在一个Qcon群里分享了一些im技术，抽取出其中im协议选型相关的内容，跟大家分享。 分享人：58沈剑，58同城技术委员会主席，高级架构师，优秀讲师。 im协议设计分为三层：应用层、安全层、传输层。 ? 后文将详细介绍这三层的协议应该如何选型与设计。 二、im应用层协议设计 应用层协议选型，常见的有三种：文本协议、二进制协议、流式XML协议。 四、im传输层协议设计 可选的协议有TCP和UDP 现在的im传输层基本都是使用TCP，有了epoll等技术后，多连接就不是瓶颈了，单机几十万链接没什么问题。58同城现在线上单机连接好像是10w？ （可能单机性能测试可以到百万，线上一般跑到几十万） 关于QQ使用UDP的问题 个人不清楚QQ使用UPD作为传输层协议的初衷，但猜测是因为10多年前C10K问题没有得到很好解决，一台服务器支撑不了1W个TCP ps：文本只介绍了im协议选型，只是协议设计的上半部分，选型完之后，协议细节如何设计也没有展开讲，后续会撰文讨论《im协议设计细节（下）》。
1.5K110发布于 2018-03-01 - 来自专栏即时通讯技术
移动端IM系统的协议选型：UDP还是TCP？
从PC时代的IM开始，IM开发者就在为数据传输协议的选型争论不休（比如：《为什么QQ用的是UDP协议而不是TCP协议？》这样的问题，隔一段时间就能在社区里看到）。 （本文同步发布于：http://www.52im.net/thread-33-1-1.html） 2、学习交流 - 移动端IM开发推荐文章：《新手入门一篇就够：从零开发移动端IM》 3、参考资料 《为什么 这些问题都是讨论�移动端IM、消息推送等类似话题时，几乎一定被问到的问题。这里尝试正本清源一下。 10、高级应用网络通讯要求 不过，移动端IM系统、推送系统一方面提供终端在线服务，另外一方面也需要考虑内容信息的完整性和安全性。毕竟信息的丢失，或者通讯的被窃听，都是难以接受的。 （本文同步发布于：http://www.52im.net/thread-33-1-1.html）
2.3K10发布于 2018-08-23 2026年IM（即时通讯）厂商如何选型？
在移动互联网深度渗透的背景下，即时通讯（IM）早已从“功能模块”演变为“基础设施能力”。 当前国内IM市场已形成多家成熟厂商并存的格局，环信、融云、网易云信、腾讯云IM等均具备较强技术沉淀与行业覆盖能力。 （一）高效率接入：缩短研发周期的工程化能力对于研发团队而言，IM选型的首要指标往往是“集成成本”。 腾讯云IM继承QQ与微信的通信技术积累，与腾讯生态体系高度协同，在社交、电商场景具备生态优势。总结：如何做IM技术选型？IM选型本质上是对稳定性、扩展性、合规能力与研发效率的综合权衡。 选型中具备更全面的适配能力。
25010编辑于 2026-02-22- 来自专栏IT技术精选文摘
IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？
1、前言 在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此 但市面上的MQ消息中间件产品很多，作为IM系统中必不可少的一环，我们该如何选型？那么请继续阅读本文。 举个例子：消息第一次消费失败入重试队列 Q1，Q1 的重新投递延迟为 5s，在 5s 过后重新投递该消息；如果消息再次消费失败则入重试队列 Q2，Q2 的重新投递延迟为 10s，在 10s 过后再次投递该消息 6、具体技术选型指标2：性能 功能维度是消息中间件选型中的一个重要的参考维度，但这并不是唯一的维度。 10、消息中间件选型误区总结 在进行消息中间件选型之前可以先问自己一个问题：是否真的需要一个消息中间件？在搞清楚这个问题之后，还可以继续问自己一个问题：是否需要自己维护一套消息中间件？
2K30发布于 2018-06-22 - 来自专栏即时通讯技术
IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？
但市面上的MQ消息中间件产品很多，作为IM系统中必不可少的一环，我们该如何选型？那么请继续阅读本文。 实际应用中大多采用基于队列的延迟，设置不同延迟级别的队列，比如 5s、10s、30s、1min、5mins、10mins 等，每个队列中消息的延迟时间都是相同的，这样免去了延迟排序所要承受的性能之苦，通过一定的扫描策略 举个例子：消息第一次消费失败入重试队列 Q1，Q1 的重新投递延迟为 5s，在 5s 过后重新投递该消息；如果消息再次消费失败则入重试队列 Q2，Q2 的重新投递延迟为 10s，在 10s 过后再次投递该消息 7、具体技术选型指标2：性能 功能维度是消息中间件选型中的一个重要的参考维度，但这并不是唯一的维度。 10、具体技术选型指标5：社区力度及生态发展 对于目前流行的编程语言而言，如 Java、Python，如果你在使用过程中遇到了一些异常，基本上可以通过搜索引擎的帮助来得到解决，因为一个产品用的人越多，踩过的坑也就越多
2.4K30发布于 2018-08-29 - 来自专栏Lambda
IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？
IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？ 1、前言 在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此 但市面上的MQ消息中间件产品很多，作为IM系统中必不可少的一环，我们该如何选型？那么请继续阅读本文。 举个例子：消息第一次消费失败入重试队列 Q1，Q1 的重新投递延迟为 5s，在 5s 过后重新投递该消息；如果消息再次消费失败则入重试队列 Q2，Q2 的重新投递延迟为 10s，在 10s 过后再次投递该消息 10、具体技术选型指标5：社区力度及生态发展 对于目前流行的编程语言而言，如 Java、Python，如果你在使用过程中遇到了一些异常，基本上可以通过搜索引擎的帮助来得到解决，因为一个产品用的人越多，踩过的坑也就越多
1.3K20编辑于 2022-04-13 - 来自专栏即时通讯技术
探探的IM长连接技术实践：技术选型、架构设计、性能优化
本文将要分享的是陌生人社交应用探探的IM长连接模块从技术选型到架构设计，再到性能优化的整个技术实践过程和经验总结。 （▲ 上图引用自《移动端IM/推送系统的协议选型：UDP还是TCP？》） TCP实现长连接的四个问题: 1）移动端的消息量还是比较稀疏，用户每次拿到手机之后，发的消息总数比较少，每条消息的间隔比较长。 10、动态Ping包时间间隔算法 PS：在IM里这其实有个更专业的叫法——“智能心跳算法”。 我们还设计了一个动态的Ping包时间间隔算法。 基本可以在4到10分钟之内发一个Ping包就行，可以维持网络运营商设备里的缓存，一直保持着，这样就没有问题，使长连接一直保活着。 （本文已同步发布于：http://www.52im.net/thread-3780-1-1.html） 14、参考资料 [1] 移动端IM/推送系统的协议选型：UDP还是TCP？
2K20编辑于 2021-12-14 - 来自专栏用户4215420的专栏
即时通讯(im)框架系统开发思考(1)-通讯协议选型
1.前言： 近来笔者接到公司的一个IM开发需要，要在原来的Web业务系统、移动端系统上加入一个即时聊天的功能，具有就是能聊天就行。 相信各位也会接到需要开发IM的系统的任务，那么，开发一个im系统应选用哪种通讯协议? 开发成本高，如要支持多个平台, 每个客户端都需要定制，IM方面的开源社区不活跃，技术文档少。 跨平台: 差, 每个客户端都需要实现MQTT的聊天协议。
3.3K00发布于 2020-06-14 - 来自专栏MySQL
10款常见MySQL高可用方案选型解读
关于对高可用的分级我们暂不做详细的讨论，这里只讨论常用高可用方案的优缺点以及选型。 二、高可用方案 1 、主从或主主半同步复制 使用双节点数据库，搭建单向或者双向的半同步复制。
6.5K100发布于 2018-05-11 - 来自专栏即时通讯技术
IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实践总结
、打包、踩坑等)》《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实践总结》（* 本文）《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实践》（稍后发布 .. ）《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK改造实践总结》（稍后发布.. ）《IM跨平台技术学习(六)：网易云信基于Electron的IM消息全文检索技术实践》（稍后发布 4、开发技术栈选型4.1编程语言选型我们最终选择的是Typescript，理由如下。 10、本文小结本文介绍了我们对跨系统桌面端技术的调研、确定技术选型，以及用 electron 开发过程中，总结的实践经验及踩坑填坑过程，如构建、性能优化、质量保障、安全等。 的聊天消息全文检索技术实践学习交流：- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》 - 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK
2K31编辑于 2022-09-29 - 来自专栏音视频咖
你问我答 | 即时通信IM（2021年8月-10月）
即时通信IM 你问我答 第2季 本期共解答10个问题 Q1：即时通信IM是否支持海外数据独立部署？ Q2：IM 专业版与旗舰版是否有日活跃用户数（DAU）的限制？ Q4：即时通信 IM 数据存储在哪里？ 如果您使用的是腾讯云中国站的 IM 服务，默认数据存储在中国站点（服务全球可用）。 Q8：IM发送表情，消息列表显示为空、或者乱码？ 即时通信 IM 不提供表情包，具体的解析需要自己对齐。 Q10：即时通信IM群 @ 消息怎么处理？ 群内 @ 消息与普通消息没有本质区别，仅是在被 @ 的人收到消息时，需要在 UI 上做特殊处理。例如 QQ 的消息列表中会有标红提示。
1.3K70编辑于 2021-12-11 - 来自专栏数据库与编程
IM表达式的目的（IM 5.2）
上接IM 5.1，本章为IM系列第五章 使用In-Memory表达式优化查询第二部分IM表达式的目的。 IM表达式的目的 IM表达式通过预先计算计算密集表达式来加速大数据集的查询速度。 IM表达式和物化视图解决了相同的问题：如何避免重复计算表达式。然而，IM表达式具有优于物化视图的优点： · IM表达式可以捕获未持久存储的数据。 （IM-4.2 第二部分） 第四章 为IM 启用填充对象之启用和禁用列（IM-4.3 第三部分） 第四章 为IM 启用填充对象之在NO INMEMORY表上指定INMEMORY列属性：示例（IM-4.4 第四部分） 第四章 为IM 启用填充对象之启用和禁用表空间的IM列存储（IM 4.5） 第四章 为物化视图启用和禁用IM列存储（IM 4.6） 第四章 为IM 启用填充对象之强制填充In-Memory 对象：教程（IM 4.7） 第四章 为IM 启用填充对象之为IM列存储启用ADO（IM 4.8） 第五章 使用In-Memory表达式优化查询（IM 5.1） 山东Oracle用户组(Shandong
1.5K30编辑于 2022-04-23 - 来自专栏数据库与编程
用户接口和IM表达式（IM 5.6）
上接IM 5.5。本章为IM系列第五章 使用In-Memory表达式优化查询第六部分用户接口和IM表达式。 · DISABLE 数据库不会将IM表达式（无论是静态还是动态）都填充到IM列存储中。 注: IM表达式不支持依赖于NLS的数据类型。 （IM-4.2 第二部分） 第四章 为IM 启用填充对象之启用和禁用列（IM-4.3 第三部分） 第四章 为IM 启用填充对象之在NO INMEMORY表上指定INMEMORY列属性：示例（IM-4.4 第四部分） 第四章 为IM 启用填充对象之启用和禁用表空间的IM列存储（IM 4.5） 第四章 为物化视图启用和禁用IM列存储（IM 4.6） 第四章 为IM 启用填充对象之强制填充In-Memory 对象：教程（IM 4.7） 第四章 为IM 启用填充对象之为IM列存储启用ADO（IM 4.8） 第五章 使用In-Memory表达式优化查询（IM 5.1） IM表达式的目的（IM 5.2） IM表达式如何工作
1.6K20编辑于 2022-04-23 - 来自专栏【腾讯云开发者】
10分钟搞懂！消息队列选型全方位对比
本文对Kafka、Pulsar、RocketMQ、RabbitMQ、NSQ这几个消息队列组件进行了一些调研，并整理了相关资料，为业务对MQ中间件选型提供参考。 近几年出现了一些关注度较高的消息队列中间件选型，如Kafka、Pulsar、RocketMQ等，首先从宏观上做一些对比： 结论： 日志处理、大数据处理等场景，高吞吐量、低延迟的特性考虑，Kafka依旧是一个较好的选型 二、选型要点 先来个汇总，接下来会对消息队列中间件的各项功能进行逐个分析。 RocketMQ开源版本延迟消息临时存储在一个内部主题中，不支持任意时间精度，支持特定的level，例如定时5s，10s，1m等。 例如，如果订阅B没有活动消费者，则在配置的TTL时间段过后，消息M10将自动标记为已确认，即使没有消费者实际读取该消息。 RocketMQ提及到消息TTL的资料比较少，不过看接口似乎是支持的。
16.3K11编辑于 2022-02-17 - 来自专栏Bypass
SaaS应用选型，必须考虑的10个安全问题
本文整理了10个必问的SaaS安全问题，包括基础安全，应用安全，安全合规、数据安全、安全责任划分等方面，可以快速了解SaaS厂商的安全能力。 ---- 1、SaaS软件的部署方式？ 10、一旦出现数据泄露事件，责任如何划分？ 目前，安全责任共担模式在业界已经达成共识，亚马逊AWS、微软Azure、阿里云、腾讯云均采用了与用户共担风险的安全策略。
3.8K30发布于 2020-02-14 - 来自专栏即时通讯技术
IM消息ID技术专题(七)：网易严选分布式ID的技术选型、优化、落地实践
本篇中的订单ID虽然不同于IM系统中的消息ID，但其技术实践仍然相通，希望能给你的IM系统消息ID技术选型也来更多的启发。 3、系列文章本文是系列文章中的第7篇，本系列总目录如下：《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践 （容灾方案篇）》《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator 的技术实现》《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》《IM消息ID技术专题(七)：网易严选分布式ID的技术选型、优化、落地实践》（* 本文）4、为什么需要分布式ID 5、我们的分布式ID架构原理5.1 技术选型下表是业内常见的分布式ID解决方案：综合考虑是否支持水平扩展以及能够显示指定ID长度，最终选择的是Leaf的Segment模式（详见《深度解密美团的分布式ID
46420编辑于 2022-11-03 - 来自专栏即时通讯技术
IM开发快速入门(一)：什么是IM系统？
2、系列文章目录 《IM开发快速入门(一)：什么是IM系统？》（* 本文） 《IM开发快速入门(二)：什么是IM系统的实时性？ (稍后发布)》 《IM开发快速入门(三)：什么是IM系统的可靠性？ (稍后发布)》 《IM开发快速入门(四)：什么是IM系统的一致性？ (稍后发布)》 《IM开发快速入门(五)：什么是IM系统的安全性？ (稍后发布)》 《IM开发快速入门(六)：什么是IM系统的的心跳机制？ (稍后发布)》 《IM开发快速入门(七)：如何理解并实现IM系统消息未读数？ 下面这些场景是我们大家都熟悉的，都用到了IM技术： 1）微信、qq、钉钉等主流IM应用：这是IM技术的典型应用场景； 2）微博、知乎等社区应用：它们利用IM技术实现了用户私信等点对点聊天； 3）抖音、快手等直播 以下文章适合IM架构设计入门，有兴趣可以读一读： 《浅谈IM系统的架构设计》 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》 《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
3.4K22发布于 2020-07-09 - 来自专栏即时通讯技术
基于Netty，徒手撸IM(一)：IM系统设计篇
注意：本系列是给IM初学者的文章，IM老油条们还望海涵，勿喷！ ，有的只是从IM入门者的角度的思路和实战，适合IM初学者阅读。 2、知识准备* 重要提示：本系列文章主要是代码实战分享，如果你对即时通讯（IM）技术理论了解的不多，建议先详细阅读：《零基础IM开发入门：什么是IM系统？》、《新手入门一篇就够：从零开发移动端IM》。 [8] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等[9] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等[10] 从新手到专家：如何设计一套亿级消息量的分布式IM系统 [11] 基于实践：一套百万消息量小规模IM系统技术要点总结[12] 探探的IM长连接技术实践：技术选型、架构设计、性能优化（本文已同步发布于：http://www.52im.net/thread-3963
2.7K12编辑于 2022-07-04 从 50ms 到 < 10ms：IM 系统性能优化实战
从50ms到<10ms：IM系统性能优化实战在IM系统中，响应时间直接影响体验。本文介绍AQChat如何将消息发送响应时间从50ms优化到<10ms。 (userId);//2.查询房间信息（数据库查询，5-10ms）RoomInforoom=roomService.getRoomInfo(roomId);//3.消息去重检查（数据库查询，5-10ms =null&&messageIds.contains(msgId);}}优化效果：用户信息查询：从数据库5-10ms降到Redis<1ms房间信息查询：从数据库5-10ms降到Redis<1ms消息去重 数据库查询房间信息查询5-10ms数据库查询消息去重查询5-10ms数据库查询消息广播10-20ms同步处理消息持久化20-30ms数据库写入总响应时间50-80ms-优化后性能：操作耗时说明用户信息查询 5.性能优化需要持续监控和调整通过以上优化，AQChat的响应时间从50ms降到<10ms，用户体验得到明显提升。
20210编辑于 2025-12-27- 来自专栏即时通讯技术
一套分布式IM即时通讯系统的技术选型和架构设计
为了更好的理解分布式IM即时通讯系统的设计，我站在架构师的角度，在充分了解系统需求、业务流程和技术流程后，从全局视角为系统设定方案目标，对技术方案进行选型，对系统进行总体架构设计和分层架构设计，并梳理清楚发送消息的交互链路 3、技术选型 在技术选型上，除了采用SpringBoot等基础框架外，也会采用容器化方案。 同时，考虑到为了尽量降低技术门槛，在整个分布式IM即时通讯系统的技术选型中，主要采用市面上比较流行的技术框架和方案。 10、IM群聊交互链路 群聊就是在分布式IM即时通讯系统中，多个用户在同一个群组中进行聊天。 此时在发送消息时，我们可以通过群组ID找出群内所有在线的用户，将消息即时发送给在线的用户。 系统 [9] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等 [10] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制 [11] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路
4.6K04编辑于 2024-01-16
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号