示例流程
网关发送消息之后，如何接收后端服务的秒杀结果，又如何给APP返回响应呢？
网关接收后端服务秒杀结果，实现方式不只一种，这里给个简单方案。
public class RequestHandler {
// ID生成器
@Inject
private IdGenerator idGenerator;
// 消息队列生产者
@Inject
private Producer producer;
// 保存秒杀结果的Map
@Inject
private Map<Long, Result> results;
// 保存mutex的Map
private Map<Long, Object> mutexes = new ConcurrentHashMap<>();
// 这个网关实例的ID
@Inject
private long myId;
@Inject
private long timeout;
// 在这里处理APP的秒杀请求
public Response onRequest(Request request) {
// 获取一个进程内唯一的UUID作为请求id
Long uuid = idGenerator.next();
try {
Message msg = composeMsg(request, uuid, myId);
// 生成一个mutex，用于等待和通知
Object mutex = new Object();
mutexes.put(uuid, mutex)
// 发消息
producer.send(msg);
// 等待后端处理
synchronized(mutex) {
mutex.wait(timeout);
}
// 查询秒杀结果
Result result = results.remove(uuid);
// 检查秒杀结果并返回响应
if(null != result && result.success()){
return Response.success();
}
} catch (Throwable ignored) {}
finally {
mutexes.remove(uuid);
}
// 返回秒杀失败
return Response.fail();
}
// 在这里处理后端服务返回的秒杀结果
public void onResult(Result result) {
Object mutex = mutexes.get(result.uuid());
if(null != mutex) { // 如果查询不到，说明已经超时了，丢弃result即可。
// 登记秒杀结果
results.put(result.uuid(), result);
// 唤醒处理APP请求的线程
synchronized(mutex) {
mutex.notify();
}
}
}
}
网关在收到APP秒杀请求后，直接给MQ发消息。
消息的内容，并不一定是APP请求的Request，只要包含足够字段：比如用户ID、设备ID、请求时间等。
还需包含这个请求ID和网关ID。
- 如果发消息失败，可直接给APP返回秒杀失败结果
- 成功发送消息后，线程就阻塞等待秒杀结果。这不可无限等待，需设等待超时时间。
等待结束后，去存放秒杀结果的Map中查询是否有返回的秒杀结果
- 有就构建Response，给APP返回秒杀结果
- 没有，按秒杀失败处理
秒杀这个案例中，超时之后不需要补偿机制吗，对于下游服务来说很可能以及成功了。
这个案例中，这种情况是有可能存在的。
是否需要补偿，也无所谓对错，总体效果是一样的。秒杀的目的就是从众多秒杀用户中公平的选择n个用户，补偿或不补偿，影响的只是这n个用户是谁的问题。
所以这是一个架构选择的问题。
建议是不用补偿，按失败处理，锁定的库存超时未支付后会自动释放，好处是比较简单。
等待后端超过timeout设置的时间点，且没有秒杀结果，finally代码块中会remove掉这个请求id，并返回用户秒杀失败；若在remove之前，后端服务返回了秒杀结果并秒杀成功，在非常极致的情况下，会不会出现用户看到秒杀失败，系统却秒杀成功的情况发生呢？
不会出现的。因为，后端服务返回的秒杀结果，只会存放在Map中，并不会直接返回APP。
给APP返回结果的，只能是处理APP请求的那个线程。
这是处理APP请求的线程，接下来我们来看一下，网关如何来接收从后端秒杀服务返回的秒杀结果。
可用RPC返回秒杀结果：网关节点是RPC服务端，后端服务为客户端。
网关发的消息包含网关ID，后端服务可通过网关ID找到对应网关实例，秒杀结果需包含请求ID，这请求ID也是从消息中获取。
网关收到后端服务秒杀结果后，用请求ID为Key，把结果存到秒杀结果的Map，然后通知对应的处理APP请求的线程，结束等待。
处理APP请求的线程，在结束等待后，会去秒杀结果Map中查询结果，然后再给APP返回响应。
- 处理过程流程图
这并非性能最优方案，处理APP请求的线程需要同步等待秒杀结果，可考虑使用异步方式。
1、秒杀的理解:
APP–发送秒杀请求–》网关（也是RPC服务端，和配置中心保持长连接，比如nacos，将其路由和配置信息定时的发送给配置中心，配置中心对其进行管理，定时的清除宕机的网关路由信息，如超过一定时间没有接收到网关的心跳包）–》将其APP请求做一定的封装，增加网关id和网关实例中唯一的请求id发送给消息队列，为了保证消息不丢失，网关对其发送消息出现的异常进行处理，如超时异常，直接返回秒杀失败，网关发送消息的这个过程中可能涉及到分布式事务，使用消息队列的分布式事务进行处理，然后网关需要等待一段时间，等待秒杀服务端使用RPC调用网关实例的接收秒杀结果，为此创建一个新对象，将其请求id做为key，新对象做为value放入CurrentMap中，调用新对象的超时wait方法进行等待秒杀结果–发送封装的APP请求，包含网关id和请求id–》消息队列接收APP请求消息，为了保证消息不丢失，开启Sync_Flush参数将消息保存到磁盘，并且为了防止一台机器磁盘出问题，集群需要2台机器都有消息才确认请求–从消息队列中拉取消息–》秒杀服务端，为了低延迟执行风控、预占库存，拿到消息中网关id，从本地路由中查询网关id的实例信息，如果获取不到调用网关实例时，需先从配置中心获取到网关的路由信息，秒杀服务端也需和配置中心保持长连接，定时的从配置中心拉取网关的路由信息，保存到本地，使用RPC调用网关实例的接收秒杀结果的方法，为了保证消息不丢失，先执行消费逻辑，再响应消息队列，如果根据网关id获取不到网关实例，或者确认消息队列超时或出现异常，秒杀服务端回滚事务，此过程也涉及到分布式事务，为了防止消费重复消息，接口的幂等性，将请求id和网关id做为唯一键。也为了防止消息积压，消息队列中的主题队列和消费组中的消费者一一对应，保证消息被快速消费。
2、秒杀异步，APP发送请求给网关，网关接收请求后将请求做一定的封装（包括请求id，网关id，账户id），然后发送到消息队列中，响应APP请求，无需等待后需的流程，然后秒杀成功以否直接返回，后续流程处理完使用短信的形式告知用户是否秒杀成功，不知道这样做法是否可行。
3、最近在撸rocketmq的源码，搞了namesrv、logging、logappend模块，想成为commiter，立个flag，等后续JMQ出来，撸其源码，也想成为commiter，道阻且长，持续进化。
解答：技术上都没什么问题。
从业务角度，有一些不同的看法。
对于秒杀这种场景，宏观上的设计应该是倾向于利用有限的资源处理短时间内海量的请求，保证服务不宕机。有少量请求处理出错（注意是后端错误，用户不可见）或消息丢失，是可以接受的。
毕竟秒杀拼的就是运气，某个用户秒杀请求在处理的时候丢失，和处理成功但没秒到，对于用户来说都是运气不好而已。
基于这样的设计理念，很多保证数据可靠性的做法都可以牺牲掉，用于换取系统更大的吞吐量比较划算。
2 RocketMQ和Kafka的消息模型
这两个消息队列产品的消息模型是一样的。通过具体案例再次讲解下。
假设有一主题MyTopic，为主题创建5个队列，分布到俩Broker。
消息生产端
设有3个生产者实例：Produer0、Produer1、Producer2。
这3生产者如何对应到2Broker，又如何对应到5个队列？
无需对应，随便发。
每个生产者可在5个队列中轮询发送，也可随机选个队列发送，或只往某队列发，这皆可。
消费端
很多人没搞清消费组、消费者和队列区别。
消费组
每个消费组是一份订阅，它要消费主题MyTopic下所有队列的全部消息。
队列里的消息并非消费掉就没了，这里的“消费”，只是去队列里面读了消息，并不是删除，消费完这消息，还是在队列里。
多个消费组在消费同一主题时，消费组间互不影响。
比如有2个消费组：G0和G1。
- G0消费了哪些消息，G1是不知道的，也不用知道
- G0消费过的消息，G1还可以消费
- 即使G0积压了很多消息，对G1来说也没有任何影响
消费组内部
一个消费组中可包含多个消费者实例。
比如消费组G1，包含2个消费者C0和C1，那这2个消费者又是怎么和主题MyTopic的5个队列对应的呢？
由于消费确认机制，在同一消费组里，每个队列只能被一个消费者实例占用。
至于如何分配，这里面有很多策略，我就不展开说了。总之保证每个队列分配一个消费者就行了。比如，我们可以让消费者C0消费Q0，Q1和Q2，C1消费Q3和Q4，如果C0宕机了，会触发重新分配，这时候C1同时消费全部5个队列。
队列占用只针对消费组内部，对其他消费组没有影响。
比如队列Q2被消费组G1的消费者C1占用，对消费组G2完全没有影响，G2也可分配它的消费者占用和消费队列Q2。
消费位置
每个消费组内部维护自己的一组消费位置，每个队列对应一个消费位置。
消费位置在服务端保存，并且消费位置和消费者没有关系。
每个消费位置一般就是个整数，记录这个消费组中，这个队列消费到哪个位置了，这位置之前的消息都成功消费了，之后的消息都没有消费或正在消费。
- 例子的消费位置表格
并没有消费者这一列，即消费者和消费位置没有关系。
实现单个队列的并行消费
如果不要求严格顺序，如何实现单个队列的并行消费？
有很多的实现方式，讲个实现思路。
比如队列中当前有10条消息，编号0-9，当前的消费位置是5。
同时来了三个消费者拉消息，把编号为5、6、7的消息分别给三个消费者，每人一条。
过了一段时间，三个消费成功的响应都回来了，这时候就可以把消费位置更新为8了，就实现了并行消费。
这是理想的情况。还有可能编号为6、7的消息响应回来了，编号5的消息响应一直回不来，怎么办？
这个位置5就是一个消息空洞。为了避免位置5把这个队列卡住，可以先把消费位置5这条消息，复制到一个特殊重试队列，然后依旧把消费位置更新为8，继续消费。
再有消费者来拉消息的时候，优先把重试队列中的那条消息给消费者就可以了。
这是并行消费的一种实现方式。
并行消费开销还是很大的，不应该作为一个常规的，提升消费并发的手段，如果消费慢需要增加消费者的并发数，还是需要扩容队列数。
4 保证消息的严格顺序
怎么保证消息的严格顺序？
主题层面是无法保证严格顺序的，只有在队列上才能保证消息的严格顺序。
如果说，你的业务必须要求全局严格顺序，就只能把消息队列数配置成1，生产者和消费者也只能是一个实例，才能保证全局严格顺序。
大部分情况下，我们并不需要全局严格顺序，只要保证局部有序即可满足。
比如，在传递账户流水记录的时候，只要保证每个账户的流水有序，不同账户间流水记录无需保证顺序。
保证局部严格顺序，可以这样实现。
在发送端，使用账户ID作为Key，采用一致性哈希算法计算出队列编号，指定队列来发送消息。
一致性哈希算法可以保证，相同Key的消息总是发送到同一队列，保证相同Key的消息严格有序。
如果不考虑队列扩容，也可以用队列数量取模的简单方法来计算队列编号。
消息传入kafka的函数中，参数key本身的实现是普通hash还是一致性hash？
Kafka的分区选择器是可以配置的，默认情况下，如果不传入key，采用轮询算法，传入key的话，按照key做普通hash，然后哈希值与分区总数取模，计算出分区号。
总结
使用消息队列，大部分的难点在宏观架构层面，要解决这些难点，你需要掌握消息队列宏观层面上的实现原理和最佳实践，这样，无论你使用什么消息队列，都可以做到游刃有余。在选定了合适的消息队列产品，准备写代码之前，再去文档中查看这些细节都来得及。
所以，我们先讲的是消息队列的使用，注重通用的原理。
关于事务消息的ACID那个问题没有提到，能不能找机会说下你的看法？
没有实现隔离性，一致性只能保证最终一致，而原子操作和持久化可以通过各种手段实现。
严格的说，ACI都没实现，只有D实现了。
放宽点儿限制的话，或者考虑实际效果的话，A（原子性）绝大多数情况下还是可以保证的，即“要么都成功，要么都失败”。C（一致性）通过补偿，大部分情况下也可以保证最终一致。
如果一个topic中有多个消费者，但每个消费者可能只需要其中的一部分数据，一种可行的方案是消费者消费全量消息，然后自行过滤；另一种方式是生产者将这些消息进行分类，不同类别的消息分别对应不同的topic，但这样可能会出现N多的topic，topic太多是否又会出现随机io太多导致性能问题，另外对生产端的编码也不友好，每种消息都要感知发到哪个topic中，这种情况下应该如何取舍？
可以使用RocketMQ的服务端过滤功能，正好可以满足这个需求。
JSR330的注释 Inject ， 但实际上和spring自身的 Autowired 注释功能相同， 所以我平时都是直接用 spring 自带的注释。 请问老师使用 JSR330 提供的注释是有什么讲究莫
JSR是一个标准，Spring是JSR的一个实现，并做了很多的扩展。
消息队列就是个分布式存储系统。