共计 2377 个字符，预计需要花费 6 分钟才能阅读完成。
人生是一连串的难题，解决人生问题的首要计划，乃是自律。
目录
一、音讯队列的个性
二、为什么须要音讯队列？
三、应用音讯队列有什么益处？
四、为什么须要分布式？
五、分布式环境下须要解决哪些问题？
六、如何实现？
七、常见音讯队列比照和选型
一、音讯队列的个性
业务无关，一个具备普适性质的音讯队列组件不须要思考下层的业务模型，只做好音讯的散发就能够了，下层业务的不同模块反而须要依赖音讯队列所定义的标准进行通信。
FIFO，先投递先达到的保障是一个音讯队列和一个 buffer 的本质区别。
容灾，对于普适的音讯队列组件来说，节点的动静增删和音讯的长久化，都是反对其容灾能力的重要根本个性。当然，这个个性对于游戏服务器中大部分利用中的音讯队列来说不是必须的，这个也是跟利用情景无关的，很多时候没有这种长久化的需要。
性能，这个不用多说了，音讯队列的吞吐量下来了，整个零碎的外部通信效率也会有进步。
二、为什么须要音讯队列？
当零碎中呈现“生产“和“生产“的速度或稳定性等因素不统一的时候，就须要音讯队列，作为形象层，弥合单方的差别。“音讯”是在两台计算机间传送的数据单位。音讯能够非常简单，例如只蕴含文本字符串；也能够更简单，可能蕴含嵌入对象。音讯被发送到队列中，“音讯队列”是在音讯的传输过程中保留音讯的容器。
举几个例子
1）业务零碎触发短信发送申请，但短信发送模块速度跟不上，须要将来不及解决的音讯暂存一下，缓冲压力。就能够把短信发送申请丢到音讯队列，间接返回用户胜利，短信发送模块再能够缓缓去音讯队列中取音讯进行解决。
2）调近程零碎下订单老本较高，且因为网络等因素，不稳固，攒一批一起发送。
3）工作解决类的零碎，先把用户发动的工作申请接管过去存到音讯队列中，而后后端开启多个应用程序从队列中取工作进行解决。
三、应用音讯队列有什么益处？
3.1、进步零碎响应速度
应用了音讯队列，生产者一方，把音讯往队列里一扔，就能够立马返回，响应用户了。无需期待处理结果。
处理结果能够让用户稍后本人来取，如医院取化验单。也能够让生产者订阅（如：留下手机号码或让生产者实现 listener 接口、退出监听队列），有后果了告诉。取得约定将后果放在某处，无需告诉。
3.2、进步零碎稳定性
思考电商零碎下订单，发送数据给生产零碎的状况。电商零碎和生产零碎之间的网络有可能掉线，生产零碎可能会因保护等起因暂停服务。如果不应用音讯队列，电商零碎数据公布进来，顾客无奈下单，影响业务发展。两个零碎间不应该如此严密耦合。应该通过音讯队列解耦。同时让零碎更强壮、稳固。
异步化、解耦、打消峰值
以上三点其实能够用一个例子来解释——构想有一款 MMO 游戏，没有人肉写的缓存层或者 ORM，所有逻辑节点都直连 MySQL，逻辑节点内除了要关注场景、战斗、交互等简单逻辑以外，还要有个拼 SQL 语句的模块，想想几乎是蛋疼。先考虑一下这样设计的弊病所在：
- 逻辑节点与 Db 的交互会有大量 IO，即便把与 Db 交互的模块耦合在逻辑节点内，其实现对你来说是黑盒，如果外部是同步实现的，那就间接卡你游戏主逻辑，就因为一次存盘操作，玩家们都掉线了，服务器也能够关掉了。
- 那么咱们改良一下，针对 1 的状况，能够把这个模块做到一个线程里挂在逻辑节点上。这样其实逻辑节点跟这个 Db 前端模块的交互就会基于一个比拟原始的音讯队列。然而这样还有一个害处，那就是这两种工作一种是计算密集的（玩家的逻辑解决）、一种是 IO 密集的（只负责写入读取 MySQL），搞到一个节点中，扩大起来会十分麻烦，而且耦合度太高。比如说当初发现场景放单节点上有瓶颈，要按场景分节点，那么这种挂在下面的数据模块怎么跟其余场景的交互呢？
- 峰值的问题。在分布式系统中，一次分布式事务关联的是多个节点，其中每一个节点呈现问题都会成为整个事务处理流程中的瓶颈。如果逻辑节点与数据库之间没有一个起到缓冲作用的节点，那就是每次操作都要拜访数据库，对于 MMO 来说，一个玩家上线 load 几百 K 数据，一个服 10 万个玩家上线曾经足够搞垮一个 mysql 节点了。如果间接搞垮还是比拟好的后果，至多是后面的玩家的确登录下来了并且能够失常游戏，前面的玩家登录不上。然而很惋惜，十年前开始风行的 C10K 说法就是在讲：并发量上来之后，会造成 chain reaction，大量的并发不会间接挂掉你的 mysql 节点，然而会拖慢速度，升高吞吐量，一个玩家的申请因为解决工夫太长，导致玩家放弃重试，然而对于后端来说，对该玩家之前的处理过程耗费的资源就全副节约了，陷入恶性循环。
所以，这种情景下，一个介于逻辑节点和 db 节点之间的缓存节点就是天经地义的事件了。这个缓存节点其实很多时候也能够看作是一个更简单的音讯队列节点。
四、为什么须要分布式？
4.1、多零碎合作须要分布式
音讯队列中的数据须要在多个零碎间共享数据能力施展价值。所以必须提供分布式通信机制、协同机制。
4.2、单零碎内部署环境须要分布式
单零碎外部，为了更好的性能、为了防止单点故障，多为集群环境。集群环境中，利用运行在多台服务器的多个 JVM 中；数据也保留在各种类型的数据库或非数据库的多个节点上。为了满足多节点合作须要，须要提供分布式的解决方案。
五、分布式环境下须要解决哪些问题？
5.1、并发问题
需进行良好的并发管制。确保“线程平安“。不要呈现一个订单被出货两次。不要呈现顾客 A 下的单，发货发给了顾客 B 等状况。
5.2、简略的、对立的操作机制
需定义简略的，语义明确的，业务无关的，失当稳当的对立的拜访形式。
5.3、容错
管制好单点故障，确保数据安全。
5.4、可横向扩大
可便捷扩容。
六、如何实现？
成熟的音讯队列中间件产品太多了，族繁不迭备载。成熟产品通过验证，接口标准，可扩展性强。
联合事业环境因素、组织过程遗产、施行运维思考、技术路线思考、开发人员状况等起因综合思考。
