缓存优化（接收请求和处理之间）

处于“处理－转发”模式下运行的生产者往往被设计成请求驱动型的服务，即每个请求都会触发一个处理线程，线程处理完后将结果写入分布式队列。但是如果队列不可用，那么生产者的处理线程就会产生堆积，则会导致以下两个问题：

  • 系统可用性降低。由于每个线程都需要一定的内存开销，线程过多会使系统内存耗尽，甚至可能产生雪崩效应导致最终完全不可用。
  • 信息丢失。为了避免系统崩溃，一般会给请求驱动型服务设置一个处理线程池，设置最大处理线程数量。这是一种典型的降级策略，目的是为了防止系统崩溃。但是，后续的请求会因为没有处理线程而被迫阻塞，最终可能产生信息丢失。

解决思路来自CAP理论，即通过降低一致性来保证可用性。具体如下：

生产者接收线程在收到请求之后第一时间不去处理，直接将请求缓存在内存中（牺牲一致性），而在后台启动多个处理线程从缓存中读取请求、进行处理并写入分布式队列。

与线程所占用的内存开销相比，大部分的请求所占内存几乎可以忽略。通过在接收请求和处理请求之间增加一层内存缓存，可以大大提高系统的处理吞吐量和可扩展性。这个方案本质上是一个内存生产者消费者模型。

批量写入优化（处理请求和写入队列之间）

如果生产者请求过大，写入分布式队列则会成为瓶颈，有以下几点原因：

  • 队列自身性能不高；
  • 分布式队列编程模型往往被应用在跨机房的系统里面，跨机房的网络开销往往容易成为系统瓶颈；
  • 消息确认机制往往会大大降低队列的吞吐量以及响应时间。

如果在处理请求和写队列之间添加一层缓存，消息写入程序批量将消息写入队列，可以大大提高系统的吞吐量。原因如下：

  • 批量写队列可以大大减少生产者和分布式队列的交互次数和消息传输量。特别是对于高吞吐小载荷的消息实体，批量写可以显著降低网络传输量；
  • 对于需要确认机制的消息，确认机制往往会大大降低队列的吞吐量以及响应时间，某些高敏感的消息需要多个消息中间件代理同时确认，这近一步恶化性能。在生产者的应用层将多条消息批量组合成一个消息体，消息中间件就只需要对批量消息进行一次确认，这可能会数量级的提高消息传输性能。

持久化优化

添加缓存可以提高吞吐行，但是也会导致新的问题，内存数据丢失。对于敏感数据，要考虑以下问题：

  • 如果内存中存在未处理完的请求，而某些原因导致生产者服务宕机，内存数据就会丢失而可能无法恢复；
  • 如果分布式队列长时间不可用，随着请求数量的不断增加，最终系统内存可能会耗尽而崩溃，内存的消息也可能丢失。

所以缓存中的数据要定时持久化到磁盘中。主要有两种 ：

  • 定期触发，即每隔一段时间进行一次持久化；
  • 定量触发，即每当缓存中的请求数量达到一定阈值后进行持久化。

是否需要持久化优化，以及持久化策略应该由请求数据的敏感度、请求量、持久化性能等因素共同决定。

参考

《美团博客》