为什么要使用消息服务

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

1．异步处理

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

图1 异步处理场景说明图示

在图1中，针对上述注册业务的场景需求，处理方式有三种，其中：

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

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

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

2．应用解耦

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

图2 应用解耦场景说明图示

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

3．流量削峰

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

图3 流量削峰场景说明图示

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

4．分布式事务管理

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

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

图4 分布式事务管理场景说明图示

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

通过上述几个常用场景的说明，相信读者对为什么要使用消息服务以及使用消息服务的好处有了一定的认识，除此之外，消息服务还有其他一些用处，这里不再详细说明了