qmq

消息队列使用场景：解耦/最终一致性/广播/错峰与流控(解决producer，consumer速度差异矛盾)

可靠投递（最终一致性）：带来重复性问题和延迟，A机器加钱，B机器扣钱，A本地事务保证加钱和消息一起落地，A可反复重发保证消息broker落地，broker保证消息consumer（B）落地，达到分布式事物
业务解耦：A接口调用B，B消息调用A，避免循环依赖，你不再依赖多个下游了，只需要发消息就好了
group的概念：每一个group只有一台机器收到
broker，producer，和consumer这三者是通过zk进行协同的
producer需要找到broker list，负载均衡选择group内机器
事务性消息：业务操作决定是否发送消息，同一db instance内不同库的事务，调用发送方法消息入库
幂等：参数一样，返回结果就必须一样，消息重复发送，业务上要去重
顺序消费：保证消费顺序和生产顺序一致
异步消费：关闭自动ack，手动ack，保证异步操作完成再ack
重复消息：broker记录MessageId，重复的ID到来不做处理
对于server投递到consumer的消息，重发前先询问，consumer端再幂等
push or pull
push：慢消费即consumer处理太慢，会reject掉broker的push
pull模式，consumer可以按需消费，但会带来延迟，

broker服务端提供两个RPC服务，一个用来接收消息，一个用来确认消息收到。并且做到不管哪个server收到消息和确认消息，结果一致即可

高可用：依赖rpc和存储（消息队列）的可用性
消息队列高可用：broker接受消息和确认消息的接口是幂等的，consumer的几台机器处理消息是幂等的，幂等需要共享存储保证
broker是否会持久化消息（高可靠，低性能，高容量）
单播与广播：组间广播、组内单播（常见）
维护广播关系（zk，config server）

主流消息队列的设计范式里，应该是不丢消息的前提下，尽量减少重复消息，不保证消息的投递顺序。
消费方需保证重复消息下和乱序消息下业务的正确
异步和oneway
异步关注结果，通过callback或轮询，oneway不关注结果
qmq：https://github.com/qunarcorp/qmq/blob/master/README.md
qmq 是通过host+appid +consumergroup 来标识一个消费者
qmq broker 端没有对topic 针对 messageId 做去重， 这种情况一般producer 重复发送消息（messageId 一样）导致的（这个设计不好）