消息中间件服务SQS

Simple Queuing Service（SQS）是AWS提供的一款云端消息中间件服务，使用该服务能够解耦复杂庞大的分布式应用中的各个组件。其中有些组件能够向SQS里推送消息，而另外一些组件则从SQS里获取对应的消息进行处理得到结果。

市场上有各种个样的消息中间件，比如我们常见的Kafka、RabbitMQ、AWS SQS等等，其中SQS是完全托管在云端，无需自己搭建中间件服务和提供硬件资源，直接能够使用。而Kafka和RabbitMQ均是开源项目，其中Kafka是LinkedIn的杰作，已经被LinkedIn检验，其特点是吞吐量高、低延时、数据持久、能容错、可分布、可扩展、高并发、实时性。但是2者均需要自己部署，需要为之建立监控方案。

Kafka vs SQS

由于有太多的消息中间件可供选择，那么让我们看看如何在Kafka或者SQS进行选择？

选择消息中间件主要从2个方面来进行评估1、技术方面；2、成本方面。

1、技术方面

当选择一个服务或者一个开源项目作为自家系统的一个组件时，往往需要评估该服务或项目的易用性、维护性、扩展性、性能等等诸多因素，当然在这些指标之上，最重要的是能够满足业务要求。

2、成本方面

引入任何第3方的服务或者开源项目都会引发成本，如何将成本控制在一定范围内或者降低成本也是至关重要的。成本的计算可以精确到天或者月。

有了以上2个纬度，接下来我们看看如何选择Kafka或SQS。

SQS是托管于AWS，这就意味着使用者不需要提供或购买任何硬件资源，而是直接端到端进行使用，非常简单直接，同时按需收取服务费。但是从自由度来讲自然会受到各种限制，比如消息的大小、消息的留存时间等等，这些参数虽然可以设置，但是依然限制了使用者的自由。

Kafka是一个开源的项目，因此使用者的束缚不多，甚至可以修改其源码来适应自己的要求，但是也有不必要的麻烦之处：比如需要自己部署，需要自己建立监控系统对其进行监控等等，不过Kafka在成本和性能方面都是不错的，因此你会看到有很多体量巨大的服务会使用它。

通过以上描述其实可以看出虽然AWS SQS提供了托管的消息队列，但是却对使用者有诸多限制，因此它只是针对简单的消息队列场景能够使用，对于那些业务需求独特的业务场景一般会选择Kafka。

{{ c.display_datetime }}

{{ title }}

消息中间件服务SQS

Kafka vs SQS

{{ c.user.name }}

{{ title }}

{{ selected_gold.title }}

{{ title }}

消息中间件服务SQS

Kafka vs SQS

创建新文章

删除文章或章节

{{ title }}