Report of the Week [5] – Always a Full Stack

/ 0评 / 0

一次全栈,一生全栈。

消息队列

最终我们需要一个可以保证「消息至少到达一次」的东西。那么自然的,我们需要引入一个正经的消息队列服务。

所以我就来到了北京选择了 RabbitMQ. 对应地选择了 AMQP 0-9-1.

所谓正经的消息队列和 Redis 的 PUB/SUB 的主要不同点在于前者可以保证消息至少送达一次;而后者只保证消息至多送达一次。 在一些场景下,我们可能会需要不漏任何消息.

在 AMQP 中,消息的传递由两个组件进行:Exchange 和 Queue. 消息产生者将消息发给 Exchange, 再由 Exchange 转发到对应的 Queue 内。Exchange 有三种类型:Direct, Fanout 和 Topic. Direct Exchange 的作用是直接将接收到的消息转发到由路由键指定的 Queue 内;Fanout Exchange 则是将收到的任何消息都复制一份到所有的 Queue 内;Topic Exchange 则为典型的 Pub/Sub.

保证消息至少送达一次的方法则是引入消息确认机制。当消费者从 Queue 中取出消息后,这个消息必须由消费者进行确认后才会从 Queue 中移除。对于那些未被确认的消息,队列可能会重试投递直到消息过期。

连接去耦合

在上一篇,我们提到了一些与底层结合紧密的状态是难以去耦合的。所以我们需要将这一部分做得尽量的小。那么,使用一种方法将连接状托管起来就成了一种必要。这种将状态托管给外部的方法虽然说有点作弊的感觉,但是毕竟我们也知道一个典型的应用程序有三层:状态层、逻辑层和表示层。逻辑层和表示层通常是可以做成无状态的,但这是因为将状态托管给了状态层,而不仅仅是因为逻辑和表示本身是无状态的。

那么,结合上面的消息队列,对连接进行托管就非常简便了。同时,消息队列本身也可以提供一定程度的负载均衡,做横向扩展也比较方便。

但比较成问题的是,所有的有状态的程序想要进行扩展都是不太好搞的。所以这个部分仍然需要继续完善。

发表评论

邮箱地址不会被公开。 必填项已用*标注