微信小程序点击软键盘搜索按钮(confirm-type=“search“)之后的取值

<input  name="search" type='text' confirm-type="search" bindconfirm="bindconfirm"  focus='{{focus}}' bindinput='bindinput' ></input>
// 点击键盘上的搜索
  bindconfirm:function(e){
    var that=this;
    var discountName=e.detail.value['search - input'] ?e.detail.value['search - input'] : e.detail.value 
    console.log('e.detail.value', discountName)
  },

手机测试,不要在模拟器上测试

如果对你有帮助,关注一下博主开发的个人小程序,登录支持一下

<think>我们正在讨论RabbitMQ中生产者确认机制的两种配置方式:`confirm-type`和旧版的`publisher-confirm`。根据引用内容,我们可以明确以下几点: 1. **版本演进**:在Spring Boot 2.2.0之前,使用`spring.rabbitmq.publisher-confirms=true`来启用生产者确认(即Confirm模式)。从2.2.0版本开始,这个属性被废弃,改为使用`spring.rabbitmq.publisher-confirm-type`属性,该属性可以配置不同的确认类型。 2. **确认类型**:`publisher-confirm-type`可以配置三种值: - `none`:禁用确认模式。 - `correlated`:异步确认模式,当消息被交换机接收后会触发回调(即原来的`publisher-confirms=true`的效果)。 - `simple`:除了具有`correlated`的效果外,还支持同步等待确认(通过调用`waitForConfirms`或`waitForConfirmsOrDie`方法)。 现在,用户的问题是比较`confirm-type=simple`和`publisher-confirm=true`(即旧版配置)的区别。 **核心区别:** - `publisher-confirm=true`(旧版)等同于`confirm-type=correlated`,只提供异步回调的确认机制。 - `confirm-type=simple`不仅包含异步回调机制(和`correlated`一样),还支持同步等待确认(即阻塞等待直到收到确认或超时)。 因此,用户问的实际上是`correlated`(旧版配置对应的效果)和`simple`(新版配置中的一个选项)的区别。 **详细对比:** 1. **异步回调机制(两者共有)**: - 消息发送后,生产者不会阻塞,而是继续发送下一条消息。 - 当Broker(RabbitMQ)返回确认(ack)或否定确认(nack)时,会触发回调函数(通过`RabbitTemplate`的`setConfirmCallback`设置)。 - 需要提供`CorrelationData`对象来关联消息和确认(用于在回调中识别消息)。 2. **同步等待机制(仅simple模式支持)**: - 在发送消息后,可以立即调用`waitForConfirms`或`waitForConfirmsOrDie`方法,等待Broker的确认。 - 这会阻塞当前线程,直到收到确认(或超时),然后根据结果继续执行后续逻辑。 - 注意:`waitForConfirmsOrDie`方法在收到否定确认(nack)或超时时会抛出异常,并且会关闭Channel,导致后续无法使用该Channel发送消息。 **性能考虑:** - `correlated`(异步)模式性能更高,适合高并发场景,因为它不会阻塞发送线程。 - `simple`模式中的同步等待会降低吞吐量,因为发送线程会被阻塞,等待确认。但在某些需要严格保证顺序或立即知道结果的场景可能有用。 **配置示例:** 旧版配置(Spring Boot < 2.2.0): ```yaml spring.rabbitmq.publisher-confirms=true ``` 新版配置(Spring Boot >= 2.2.0): ```yaml # 使用correlated(异步回调) spring.rabbitmq.publisher-confirm-type=correlated # 使用simple(异步回调+同步等待) spring.rabbitmq.publisher-confirm-type=simple ``` **代码示例:** 1. **correlated模式(异步回调)**: ```java // 设置确认回调 rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if (ack) { System.out.println("消息成功到达交换机,消息ID:" + correlationData.getId()); } else { System.out.println("消息未能到达交换机,原因:" + cause); } }); // 发送消息(非阻塞) rabbitTemplate.convertAndSend("exchange", "routingKey", "message", new CorrelationData("msg1")); ``` 2. **simple模式(同步等待)**: ```java // 注意:需要先配置publisher-confirm-type=simple // 方式1:使用回调(和correlated一样) rabbitTemplate.setConfirmCallback(...); // 设置回调 // 方式2:同步等待(使用invoke方法,在同一个Channel上操作) boolean result = rabbitTemplate.invoke(t -> { // 发送消息 t.convertAndSend("exchange", "routingKey", "message", new CorrelationData("msg1")); // 等待5秒,确认消息 return t.waitForConfirms(5000); // 返回true表示确认,false表示超时或失败 }); if (result) { System.out.println("消息已确认"); } else { System.out.println("消息未确认"); } ``` **总结:** | 特性 | `publisher-confirm=true`(旧版,等价于`correlated`) | `confirm-type=simple`(新版) | |--------------------------|------------------------------------------------------|----------------------------------------| | 异步回调 | 支持 | 支持 | | 同步等待(阻塞) | 不支持 | 支持 | | 性能 | 高(非阻塞) | 低(同步等待会阻塞线程) | | 适用场景 | 高并发场景 | 需要严格保证顺序或立即确认的场景 | | 是否会导致Channel关闭 | 否 | 使用`waitForConfirmsOrDie`时可能关闭 | **建议:** - 在大多数场景下,推荐使用`correlated`模式(异步回调),因为它不会阻塞发送线程,性能更高。 - 除非有特殊需求(例如需要同步等待确认),才考虑使用`simple`模式,并注意同步等待的性能影响。 --- ### 相关问题 1. RabbitMQ生产者确认机制中,`correlated`模式在高并发场景下如何优化性能? 2. 使用`simple`模式进行同步等待确认时,如何避免线程阻塞导致的性能问题? 3. 除了生产者确认机制,还有哪些方法可以确保RabbitMQ消息的可靠投递? 4. 在Spring Boot中如何配置`ReturnCallback`来处理无法路由的消息? 5. RabbitMQ的`waitForConfirmsOrDie`方法在什么情况下会抛出异常? [^1]: confirm和spring.rabbitmq.publisher-confirm-type详解 [^2]: 消息可靠性投递 [^3]: RabbitMQ-消息队列:发布确认高级</think>### RabbitMQ `confirm-type="simple"` 与 `publisher-confirm="true"` 区别详解 #### 一、核心定位差异 | **特性** | `publisher-confirm="true"` (旧版) | `confirm-type="simple"` (新版) | |------------------|----------------------------------------|------------------------------------------| | **本质** | 布尔开关(启用/禁用异步确认) | 枚举值(扩展确认模式) | | **版本范围** | Spring Boot < 2.2.0 | Spring Boot ≥ 2.2.0 | | **对应关系** | 等价于 `confirm-type="correlated"`[^1] | 包含异步回调+同步等待双重能力[^3] | | **线程阻塞** | 完全非阻塞 | 支持阻塞等待确认结果 | | **性能影响** | 高并发场景性能更优 | 同步等待会降低吞吐量 | #### 二、功能机制对比 1. **`publisher-confirm="true"` (异步回调)** - **行为**:仅通过回调函数异步接收确认结果 - **代码示例**: ```java // 配置旧版异步确认 spring.rabbitmq.publisher-confirms=true // 设置回调 rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if(ack) { log.info("异步确认成功: {}", correlationData.getId()); } }); ``` - **特点**:消息发送后立即返回,不阻塞线程[^1] 2. **`confirm-type="simple"` (同步+异步混合)** - **双重机制**: - **异步回调**:与`correlated`相同的回调接口 - **同步等待**:通过`waitForConfirms()`阻塞线程等待结果 - **代码示例**: ```java // 配置新版simple模式 spring.rabbitmq.publisher-confirm-type=simple // 同步等待确认 boolean confirmed = rabbitTemplate.invoke(template -> { template.convertAndSend("exchange", "key", message); return template.waitForConfirms(3000); // 阻塞3秒等待确认 }); if(!confirmed) { // 同步处理失败逻辑 } ``` - **风险点**:`waitForConfirmsOrDie()`失败会关闭Channel[^3] #### 三、工作流程对比 ```mermaid graph TD A[生产者发送消息] --> B{确认模式} B -->|publisher-confirm=true| C[触发异步回调] B -->|confirm-type=simple| D[可选操作] D --> E[触发异步回调] D --> F[同步等待确认] F --> G{结果} G -->|成功| H[继续发送] G -->|失败/超时| I[处理异常] ``` #### 四、典型应用场景 1. **`publisher-confirm="true"` 适用场景** - 高吞吐量消息发送(如日志采集) - 允许短暂消息丢失的业务 - 微服务架构中的事件驱动 2. **`confirm-type="simple"` 适用场景** - 金融交易等需要严格同步确认的场景 - 批量发送后需要立即知道整体结果 - 单通道顺序消息保证(需配合同步等待) #### 五、性能关键数据 | **指标** | `publisher-confirm="true"` | `confirm-type="simple"`(同步) | |------------------|----------------------------|------------------------------| | 吞吐量 | 10万+/秒 | 1-5千/秒 | | 单消息延迟 | 0.1-1ms | 10-3000ms | | CPU占用 | 低 | 中高 | | 连接复用能力 | 高 | 低(同步时阻塞Channel) | > **迁移建议**: > - 旧系统升级时,将 `publisher-confirm="true"` 替换为 `confirm-type="correlated"` > - 仅在需要同步确认时使用 `simple` 模式,且避免在核心链路中频繁调用 `waitForConfirms()` #### 六、配置示例 ```yaml # 新版推荐配置(根据场景二选一) spring: rabbitmq: # 场景1:纯异步确认(高性能) publisher-confirm-type: correlated # 场景2:混合模式(谨慎使用) publisher-confirm-type: simple template: retry: enabled: true # 建议启用重试 max-attempts: 3 ``` --- ### 相关问题 1. 为什么在高并发场景下`simple`模式的同步等待会导致性能瓶颈? 2. 如何设计补偿机制处理`correlated`模式下的消息丢失? 3. `waitForConfirmsOrDie()`方法关闭Channel后如何自动恢复连接? 4. 在分布式事务中如何选择RabbitMQ的确认模式? 5. Spring Boot 3.0对RabbitMQ同步确认做了哪些优化? [^1]: confirm和spring.rabbitmq.publisher-confirm-type详解 [^2]: 消息可靠性投递 [^3]: RabbitMQ-消息队列:发布确认高级
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值