从Redis谈起（三）—— Redis和消息中间件

什么是消息中间件

1. 消息 消息中间件定义了一个协议（模型），基于该协议可以传递消息
2. 分布式 消息中间件的引入是为了解决分布式系统的问题，对于简单的单应用系统用不着

消息中间件的衡量标准

1. 消息路由 消息如何经过消息中间件到达消费者，在一定程度上决定了消息中间件的灵活性。简单的命名队列，TOPIC订阅能满足大部分的场景，对于复杂的业务可能需要比如基于PATTERN的路由（RabbitMQ），消息复制，消息生命周期管理（beanstalk）。
2. 消息可靠性 大部分场景下消息是容忍丢失的，或者说对性能的渴求大于可靠性，比如异步发短信，异步发邮件，概数数据统计，日志等。另外有的场景是不允许消息丢失的，消息的丢失会带来数据的不一致，不一致的数据很多时候是灾难的开始，比如异步写数据，下单后减库存，转账等。可靠性基本都依赖于持久化。
3. 消息重放 不常用但是很有用。这个说的是即使是消费过的消息也能设定offset（一般是时间点）重新消费。这个功能在消息下游数据丢失，新系统导入旧数据的时候非常有用，不用再去理繁杂的数据对应关系，按照正常的业务逻辑处理消息就OK了，非常好用！非常好用！非常好用！
4. 消息堆积 抗流量神技。像双十一这种超高峰流量都会用到这个功能，这时候一方面会把消息中间件下游业务（Consumer端）的机器挪到核心业务，另一方面消息中间件在高并发投递消息的时候可能出问题，所以把消息暂存在中间件，等流量高峰过去了再投递到下游业务。
5. 分布式集群支持 高可用的需求，解决单点问题。
6. ACK 消息确认，在下游业务确认后才将消息标记为已消费，处理超时则重新投递消息，这里要求下游业务自己做可重入（幂等）
7. 消息顺序 有的业务要求消息投递顺序和消费顺序一致，或者至少要求对于单个用户顺序一致，比如用户的赞/取消操作，顺序反了数据就会错乱
8. 性能和扩展 这里指的扩展是能否通过增加Consumer来提高消息的消费速率以及消息中间件的容量是否有理论的上线；性能主要指tps、qps以及并发连接数。
9. 消息协议 优先考虑标准协议或者使用广泛的协议，有利于后期的维护和扩展

Redis作为消息中间件

1. Redis自带的PUB/SUB机制，即发布-订阅模式。这种模式生产者(producer)和消费者(consumer)是1-M的关系，即一条消息会被多个消费者消费，当只有一个消费者时即可以看做一个1-1的消息队列，但这种方式并不适合题主的场景。首先，数据可靠性的无法保障，题主的数据最终需要落库，如果消息丢失、Redis宕机部分数据没有持久化甚至突然的网络抖动都可能带来数据的丢失，应该是无法忍受的。其次，扩展不灵活，没法通过多加consumer来加快消费的进度，如果前端写入数据太多，同步会比较慢，数据不同步的状态越久，风险越大，可以通过channel拆分的方式来解决，虽然不灵活，但可以规避。这种方案更适合于对数据可靠性要求不高，比如一些统计日志打点。
2. Redis的PUSH/POP机制，利用的Redis的列表(lists)数据结构。比较好的使用模式是，生产者lpush消息，消费者brpop消息，并设定超时时间，可以减少redis的压力。这种方案相对于第一种方案是数据可靠性提高了，只有在Redis宕机且数据没有持久化的情况下丢失数据，可以根据业务通过AOF和缩短持久化间隔来保证很高的可靠性，而且也可以通过多个client来提高消费速度。但相对于专业的消息队列来说，该方案消息的状态过于简单(没有状态)，且没有ack机制，消息取出后消费失败依赖于client记录日志或者重新push到队列里面。

转自微信公众号：中间件架构