标签：方案 总结 轮询 出现 消费机 点对点 通知 取消 oom
1）消息的转储：在更合适的时间点投递，或者通过一系列手段辅助消息最终能送达消费机。
2）规范一种范式和通用的模式，以满足解耦、最终一致性、错峰等需求。
3）其实简单理解就是一个消息转发器，把一次RPC做成两次RPC。发送者把消息投递到broker，broker再将消息转发一手到接收端。
总结起来就是两次RPC加一次转储，如果要做消费确认，则是三次RPC。
点对点模型 用于 消息生产者 和 消息消费者 之间 点到点 的通信。
点对点模式包含三个角色：
每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在 内存 中也可以 持久化，直到他们被消费或超时。
特点
每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中) 发送者和接收者之间在时间上没有依赖性 接收者在成功接收消息之后需向队列应答成功
发布订阅模型包含三个角色：
多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
特点
生产者发送一条消息到队列queue，只有一个消费者能收到。
发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。
基于Queue消息模型，利用FIFO先进先出的特性，可以保证消息的顺序性。
即消息的Ackownledge确认机制，
为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消
息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。
主要是用“记录”和“补偿”的方式。
本地事务维护业务变化和通知消息，一起落地，然后RPC到达broker，在broker成功落地后，RPC返回成功，本地消息可以删除。否则本地消息一直靠定时任务轮询不断重发，这样就保证了消息可靠落地broker。
broker往consumer发送消息的过程类似，一直发送消息，直到consumer发送消费成功确认。
我们先不理会重复消息的问题，通过两次消息落地加补偿，下游是一定可以收到消息的。然后依赖状态机版本号等方式做判重，更新自己的业务，就实现了最终一致性。
如果出现消费方处理过慢消费不过来，要允许消费方主动ack error，并可以与broker约定下次投递的时间。
对于broker投递到consumer的消息，由于不确定丢失是在业务处理过程中还是消息发送丢失的情况下，有必要记录下投递的IP地址。决定重发之前询问这个IP，消息处理成功了吗？如果询问无果，再重发。
事务：本地事务，本地落地，补偿发送。本地事务做的，是业务落地和消息落地的事务，而不是业务落地和RPC成功的事务。消息只要成功落地，很大程度上就没有丢失的风险。
消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这应该处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。
消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。
在实际生产环境中，使用单个实例的消息队列服务，如果遇到宕机、重启等系统问题，消息队列就无法提供服务了，因此很多场景下，我们希望消息队列有高可用性支持，例如
RabbitMQ的镜像集群模式的高可用性方案，ActiveMQ也有基于LevelDB+ZooKeeper的高可用性方案，以及Kafka的Replication机制等。
具体请参考：高并发架构系列：分布式之消息队列的特点、选型、及应用场景详解
来源：http://www.1994july.club/seo/?p=2800
标签：方案 总结 轮询 出现 消费机 点对点 通知 取消 oom
原文地址：https://www.cnblogs.com/1994july/p/12057026.html
