本文主要是介绍淘宝notify-消息中间件(2)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
核心原理
Notify在设计思路上与传统的MQ有一定的不同，他的核心设计理念是
为了消息堆积而设计系统
无单点，可自由扩展的设计
下面就请随我一起，进入到我们的消息系统内部来看看他设计的核心原理
为了消息堆积而设计系统在市面上的大部分MQ产品，大部分的核心场景就是点对点的消息传输通道，然后非常激进的使用内存来提升整体的系统性能，这样做虽然标称的tps都能达到很高，但这种设计的思路是很难符合大规模分布式场景的实际需要的。
在实际的分布式场景中，这样的系统会存在着较大的应用场景瓶颈，在后端有大量消费者的前提下，消费者出现问题是个非常常见的情况，而消息系统则必须能够在后端消费不稳定的情况下，仍然能够保证用户写入的正常并且TPS不降，是个非常考验消息系统能力的实际场景。
也因为如此，在Notify的整体设计中，我们最优先考虑的就是消息堆积问题，在目前的设计中我们使用了持久化磁盘的方式，在每次用户发消息到Notify的时候都将消息先落盘，然后再异步的进行消息投递，而没有采用激进的使用内存的方案来加快投递速度。
这种方式，虽然系统性能在峰值时比目前市面的MQ效率要差一些，但是作为整个业务逻辑的核心单元，稳定，安全可靠是系统的核心诉求。
无单点，可自由扩展的设计
图3-5展示了组成Notify整个生态体系的有五个核心的部分。
发送消息的集群这主要是业务方的机器，这些APP的机器上是没有任何状态信息的，可以随着用户请求量的增加而随时增加或减少业务发送方的机器数量，从而扩大或缩小集群能力。
配置服务器集群(Config server)这个集群的主要目的是动态的感知应用集群，消息集群机器上线与下线的过程，并及时广播给其他集群。如当业务接受消息的机器下线时，config server会感知到机器下线，从而将该机器从目标用户组内踢出，并通知给notify server，notify server 在获取通知后，就可以将已经下线的机器从自己的投递目标列表中删除，这样就可以实现机器的自动上下线扩容了。
消息服务器(Notify Server)消息服务器，也就是真正承载消息发送与消息接收的服务器，也是一个集群，应用发送消息时可以随机选择一台机器进行消息发送，任意一台server 挂掉，系统都可以正常运行。当需要增加处理能力时，只需要简单地增加notify Server就可以了
存储(Storage)Notify的存储集群有多种不同的实现方式，以满足不同应用的实际存储需求。针对消息安全性要求高的应用，我们会选择使用多份落盘的方式存储消息数据，而对于要求吞吐量而不要求消息安全的场景，我们则可以使用内存存储模型的存储。自然的，所有存储也被设计成了随机无状态写入存储模型以保障可以自由扩展。
消息接收集群业务方用于处理消息的服务器组，上下线机器时候也能够动态的由config server 感知机器上下线的时机，从而可以实现机器自动扩展。
3.2、Notify双11准备与优化
在双11的整个准备过程中，Notify都承载了非常巨大的压力，因为我们的核心假定就是后端系统一定会挂，而我们需要能够承载整个交易高峰内的所有消息都会堆积在数据库内的实际场景。
在多次压测中，我们的系统表现还是非常稳定的，以60w/s的写入量堆积4.5亿消息的时候，整个系统表现非常淡定可靠。在真正的大促到来时，我们的后端系统响应效率好于预期，所以我们很轻松的就满足了用户所有消息投递请求，比较好的满足了用户的实际需要。
这篇关于淘宝notify-消息中间件(2)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
