不同环境下RabbitMQ的安装-1 为什么要使用消息服务

在不同的环境下安装RabbitMQ总是遇到各种问题，最终导致RabbitMQ安装失败，怎么破？

为了给大家解答这些问题，所以本文就如何在ARM架构、X86架构和Window系统下安装RabbitMQ进行详细介绍

为什么要使用消息服务

在安装RabbitMQ之前，先回顾下，我们为什么要使用消息服务？

在多数应用尤其是分布式系统中，消息服务是不可或缺的重要部分，它使用起来比较简单，同时也给我们解决了不少难题，例如异步处理、应用解耦、流量削锋、分布式事务管理等，使用消息服务可以让我们实现一个高性能、高可用、高扩展的系统。接下来我们就通过实际开发中的若干场景，来分析和说明为什么要使用消息服务，以及使用消息服务的好处。

1 异步处理

1.异步处理

**场景说明：**用户注册后，系统需要将信息写入数据库，并发送注册邮件和注册短信通知。下面我们使用图示的方式直观展示上述场景的不同处理方式。

针对上述注册业务的场景需求，处理方式有3种。

• 串行处理方式：

  用户发送注册请求后，服务器会先将注册信息写入数据库，依次发送注册邮件和短信消息，服务器只有在消息处理完毕后才会将处理结果返回客户端。这种串行处理消息的方式非常耗时，用户体验不友好。

• 并行处理方式：

  用户发送注册请求后，将注册信息写入数据库，同时发送注册邮件和短信，最后返回给客户端，这种并行处理的方式在一定程度上提高了后台业务处理的效率，但如果遇到较为耗时的业务处理，仍然显得不够完善。

• 消息服务处理方式：

  可以在业务中嵌入消息服务进行业务处理，这种方式先将注册信息写入数据库，在极短的时间内将注册信息写入消息队列后即可返回响应信息。此时前端业务不需要理会不相干的后台业务处理，而发送注册邮件和短信的业务会自动读取消息队列中的相关消息进行后续业务处理。

2 应用解耦

**场景说明：**用户下单后，订单服务需要通知库存服务。下面我们使用图示的方式直观展示此需求的不同处理方式。

如果使用传统方式处理订单业务，用户下单后，订单服务会直接调用库存服务接口进行库存更新，这种方式有一个很大的问题是：一旦库存系统出现异常，订单服务会失败导致订单丢失。如果使用消息服务模式，订单服务的下订单消息会快速写入消息队列，库存服务会监听并读取到订单，从而修改库存。相较于传统方式，消息服务模式显得更加高效、可靠。

3 流量削峰

**场景说明：**秒杀活动是流量削峰的一种应用场景，由于服务器处理资源能力有限，因此出现峰值时很容易造成服务器宕机、用户无法访问的情况。为了解决这个问题，通常会采用消息队列缓冲瞬时高峰流量，对请求进行分层过滤，从而过滤掉一些请求。

针对上述秒杀业务的场景需求，如果专门增设服务器来应对秒杀活动期间的请求瞬时高峰的话，在非秒杀活动期间，这些多余的服务器和配置显得有些浪费；如果不进行有效处理的话，秒杀活动瞬时高峰流量请求有可能压垮服务，因此，在秒杀活动中加入消息服务是较为理想的解决方案。通过在应用前端加入消息服务，先将所有请求写入到消息队列，并限定一定的阈值，多余的请求直接返回秒杀失败，秒杀服务会根据秒杀规则从消息队列中读取并处理有限的秒杀请求。

4 分布式事务管理

**场景说明：**在分布式系统中，分布式事务是开发中必须要面对的技术难题，怎样保证分布式系统的请求业务处理的数据一致性通常是要重点考虑的问题。针对这种分布式事务管理的情况，目前较为可靠的处理方式是基于消息队列的二次提交，在失败的情况可以进行多次尝试，或者基于队列数据进行回滚操作。因此，在分布式系统中加入消息服务是一个既能保证性能不变，又能保证业务一致性的方案 。

针对这种分布式事务处理的需求，下面我们以图示的方式展示使用消息服务的处理机制。

针对上述分布式事务管理的场景需求，如果使用传统方式在订单系统中写入订单支付成功信息后，再远程调用库存系统进行库存更新，一旦库存系统异常，很有可能导致库存更新失败而订单支付成功的情况，从而导致数据不一致。针对这种分布式系统的事务管理，通常会在分布式系统之间加入消息服务进行管理。上图中，订单支付成功后，写入消息表；然后定时扫描消息表消息写入到消息队列中，库存系统会立即读取消息队列中的消息进行库存更新，同时添加消息处理状态；接着，库存系统向消息队列中写入库存处理结果，订单系统会立即读取消息队列中的库存处理状态。如果库存服务处理失败，订单服务还会重复扫描并发送消息表中的消息，让库存系统进行最终一致性的库存更新。如果处理成功，订单服务直接删除消息表数据，并写入到历史消息表。

通过以上四种场景，给大家介绍了消息服务，想必大家对为什么要使用消息服务已经有了深入的了解。那下面就请各位跟着新哥的节奏，继续探讨如何安装RabbitMQ。