For-的博客

消息的顺序消费场景虽然用的不多，但在面试过程中还是会经常被问到的。打个比方，在用户购买商品的场景中，正常的流程是先发送 【创建订单消息 —> 支付 —> 发货】，如果还没支付成功就先发货了，那只好准备收拾东西走人了~那在 Spring Cloud Stream 中该怎么保证消息的顺序性呢？我们能够使用基于键值的方式做分区，让一个队列只存在一个消费者去做消费即可。Spring Cloud Stream 为我们提供了自定义策略，分别为分区键策略与 分区选择策略；

由于使用的方式配置需要改生成者与消费者代码，RabbitMQ Binder 使用 Java 的序列化方式性能低下、发送与接收端使用的类需要一样（最起码保证 serialVersionUID 一致）否则强转失败，加上官方不建议使用 payload 的内容作为分区键表达式取值等等问题，导致使用起来非常的不便利，因此直接使用 headers 的方式会更加的简单明了，虽然从payload复制多了一份数据到headers但如果对象不大可以忽略不计。

开发阶段，使请求调用有限调用到本地，基于负载均衡实现

项目升级了 Spring Cloud 的架构，顺带把 Spring Cloud Stream 的版本升级到了 3.2.x，然后发现以前使用注解的从3.1版本开始过时了，如 、 等注解。于是在定义新的 binding 时使用函数式，但是却无法生效。新建一个 biding ，按照官网的教程，写好配置文件与代码启动应用后，发现配置并不生效，最后发现原来是新的写法与旧的是不兼容的，源码在启动时会校验 bean 上下文是否有标注 的类，如果有则函数式的定义不会生效。 的源码如下：三、解决方案目前本人的

引起错误的原因，在负载均衡调用时 BlockingLoadBalancerClient 会有一个 block 的操作 @Override public <T> ServiceInstance choose(String serviceId, Request<T> request) { // 略... // block Response<ServiceInstance> loadBalancerResponse = Mono.from