即时通讯IM架构设计

接上篇《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》，本文主要聚焦分布式IM聊天系统消息可靠性问题，即如何保证消息不丢失。

分布式IM聊天系统中，IM消息怎么做到不丢、不重、还按顺序到达？这个问题，涉及到IM系统的两个核心。本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

本文要分享的是B站IM消息系统的新架构升级实践总结，内容包括原架构的问题分析，新架构的整体设计以及具体的升级实现等。

1、引言经历过稍有些规模的IM系统开发的同行们都有体会，要想实现大规模并发IM（比如亿级用户和数十亿日消息量这样的规模），在架构设计上需要一些额外的考虑，尤其是要解决用户高并发、服务高可用，架构和实现

上篇《跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天》中，我们使用 WebSocket 实现了一个简单的 IM 功能，支持身份认证、私聊消息、群聊消息。 然后就有人发私信，

今天下午跟大家分享的主题是：微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的。 回忆一下春晚的活动，有什么样的活动形式呢？

与传统意义上的红包相比，本文将由微信团队工程师张文瑞分享微信春节摇一摇红包技术背后的方方面面，希望能给同行们带来启发。

本文在编写时参考了博客作者“鹿呦呦”和在线课程“即时消息技术剖析与实战”的相关资料，一并表示感谢。 IM系统看似简单（没错，很多土老板认为开发个qq和微信也就是几万块钱的事... ），实责是众多技术的应用合体，包括网络编程、移动开发、后端开发、高并发、高可用、高安全等技术范畴，…

本文将基于IM消息系统的技术实践，分享关于离线消息和历史消息的正确理解，以及具体的技术配合和实践，希望能为你的离线消息和历史消息技术设计带来最佳实践灵感。

基于闲鱼现有的即时消息系统架构和技术体系，如何来优化它的消息稳定性、可靠性？应该从哪里开始治理？当前系统现状到底是什么样？如何客观进行衡量？希望本文能让大家看到一个不一样的闲鱼即时消息系统。

接下来的内容，我会为你介绍如何开发一个IM的方方面面，包括系统架构、通信协议、单聊群聊、表情发送、UI事件驱动等，以及全套的实践源码让你可以上手学习。

本文将探秘得物自研客服IM中收发聊天消息背后的技术逻辑和思考实现，帮助大家了解如何在IM聊天场景中提供高效、安全、可靠和良好的用户体验。

本文原作者Chank，原题“如何设计一个亿级消息量的 IM 系统”，为了提升内容质量，本次有修订和改动。1、写有前面本文将在亿级消息量、分布式IM系统这个技术前提下，分析和总结实现这套系统所需要掌握的

本文分享的离线消息推送系统设计并非专门针对IM产品，但无论业务层的差别有多少，大致的技术思路上都是相通的，希望借喜马拉雅的这篇分享能给正在设计大用户量的离线消息推送的你带来些许启发。

本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路，以期更多的同行们在此基础上汲取经验，得到有价值的启发。

本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。

本文分享了微信基于大规模微服务架构的后台过载管控和保护策略，以及微信根据IM业务特点的一些独特的架构设计做法，其中很多方法很有借鉴意义，值得一读。

IM聊天消息的可靠投递，是每个线上产品都要考虑的IM热点技术问题。 IM聊天消息能保证可靠送达，对于用户来说，就好比把钱存在银行不怕被偷一样，是信任的问题。试想，如果用户能明显感知到聊天消息无法保证送达，谁还愿意来用你的APP？谁也不希望自已的话就像浮云一样随风飘逝。 必竟用I…

对于IM应用来说，消息ID（或称序列号）是个看似不起眼，但非常重要的东西之一。 但，IM系统高度个性化的特性（设计上没有统一的标准和思路），包括聊天消息ID的生成算法在内，每个产品都有自已的思路和考量。 从某种意义上来讲，消息ID的生成策略决定了IM应用层某些功能实现的难易度，…

本文内容和编写思路是基于邓昀泽的“大规模并发IM服务架构设计”、“IM的弱网场景优化”两文的提纲进行的，感谢邓昀泽的无私分享。1、引言接上篇《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分