纸上谈兵-实时消息系统:0-序言

Q: 我是谁

一个普普通通、技术二流北漂程序员，在中关村一巴掌打下去能拍死10个的那种；

前后分别在某KID做做过互动白板信令、在某跳动做过RTC音视频信令，高不成低不就。

Q: 什么叫实时消息系统

本来这个系列是想起名叫实时通信系统（real-time communications system）来着，但业内提起实时通信的时候往往代指的是WebRTC这种实时音视频通信。虽然以个人的观点来看，广义上任何实现低延迟（时延<1s）的数据交互（包括但不限于音视频数据、聊天文本数据等）的系统都应该归类为实时通信系统，但是想了想音视频通信我虽然在工作中略有涉及，但更多的还是非音视频相关。别说深究起来，就是浅究起来音视频相关的东西我也不会啊，说学逗唱短一门怎么行呢（手动郭老师脸）？所以就打个折扣，只讲讲我比较熟悉的非音视频相关的内容。

那无论是白板信令、WebRTC信令，或者QQ、微信这种IM，又或者Android、IOS手机上的消息通知推送，从抽象上看其实都是一种消息系统，其主要功能就是将消息准确、及时的传递到它该去的地方。所谓实时消息系统就可以理解为以低延迟传递消息的系统。

Q：为什么要写这个

很幸运最近3年都在这个领域里耕耘，从业内各种前辈大佬身上学到了很多东西，也算是略有那么一丢丢成绩和心得。都说3年是程序员实现质变的一个坎，我觉得是时候把自己关于这个领域的经验做一下沉淀，以blog的形式记录下来。

Q: 为什么叫纸上谈兵

这个世界上没有完美的系统，也没有一种架构能解决所有场合所有问题，软件工程的世界里没有银弹；一个好的软件架构设计者在面对不同的业务场景设计出的系统架构肯定是不同的，但其思想、内核一定是相接近的。

我并不想（事实上根据保密原则也不可以）将自己做过的系统架构流水帐一般列出来，而是尝试脱离业务场景将如何设计一个还过得去的实时消息系统的一些思想和经验记录下来。

这个系列的内容以思路、方案为主，这些内容有些是我在实际生产环境中应用验证过的，有些是因为客观条件不允许没有真正应用但觉的应该这么搞的；所有内容会尽可能用文字和图来描述，尽量避免出现大量的代码。

所以叫纸上谈兵。

最后

准备开这个坑，完全是某天和朋友胡吃海喝之后一时心血来潮，因为平时工作很忙，只有在周末才有时间，随缘填坑。

各位是藏龙卧虎，比我不知道高到哪里去了，要是觉的我写的对不妨会心一笑，要是看到内容有误大可暗笑一声竖子无知，当然如果肯不吝指教的话我在这先行拜谢了。