- 博客(285)
- 资源 (2)
- 问答 (5)
- 收藏
- 关注
RSS订阅原创 在Mybatis中，Xml映射文件里，除了常见的select|insert|updae|delete 标签之外，还有哪些标签？
通过构造方法注入结果（替代 setter）：定义数据库列与 Java 对象的映射规则。：获取插入后的自增主键（或数据库序列值）：查询用户及其订单（一对一 + 一对多）：处理复杂定制需求（注解中用动态SQL）：像代码中的公共方法，需要时直接调用。：在注解中使用动态 SQL（需配合。：像预制好的「高汤块」，保存常用配方。：VIP顾客优先获取餐号（自增ID）过度嵌套的动态 SQL（可读性差）：设置冷冻库存规则（保存30分钟）：像发黄的纸质菜谱，已被电子菜单（：淘汰策略（LRU/FIFO等）
2025-06-05 12:27:13
722
原创 Mybatis 动态sql有什么用？执行原理？有哪些动态sql？
根据不同条件拼接不同的SQL语句，避免在Java代码中拼接SQL字符串。自动过滤掉无效要求（如顾客说"不要香菜"但本来就没放香菜）顾客改需求："把牛排改全熟，再加黑椒汁" → 自动处理逗号。自动修剪多余的"AND"/"OR"（像去掉菜里多余的装饰）顾客说"如果爱吃辣，就加辣椒" → 实际加辣时才放辣椒。"找浦东新区500-1000万，3房带车位的二手房"把顾客说的"微辣"转换成具体辣度值（如辣度=2）常用的"红烧肉套餐"可以提前备好，直接复用。：忽略矛盾/无效需求（如"冰的热咖啡"）
2025-06-05 12:18:38
533
原创 Mybatis 在mapper中如何传递多个参数?
"面条 牛肉" ← 这是要牛肉面？（厨师困惑：到底是"红烧肉配米饭"还是"红烧肉味的米饭"？清晰高效："#{菜名}：鱼香肉丝 #{辣度}：中辣 ""我要①#{主食}：饺子，②#{蘸料}：醋+辣椒"通过合理选择传参方式，可以使代码既清晰又灵活。厨师要自己解读潦草字迹（通过key取值）：点全套套餐时（前菜+主菜+甜点+饮料）就像去餐厅说："给我第一个和第三个"：字迹不清可能上错菜（key写错）扔出一张便签："多加香菜 不要蒜"对着后厨大喊："米饭 红烧肉"：填菜单（JavaBean）菜单有固定栏目（属性字段）
2025-06-05 12:09:19
1014
原创 Mybatis 如何获取自动生成的(主)键值?
只适用于标准快递柜（MySQL等支持自增的数据库）银行特殊流程（Oracle等需要序列的数据库）快递站同时处理100个包裹，每个包裹自动获得。批量操作时主键会注入到原集合对象的每个元素中。（获取序列），窗口叫号时出示号码（插入数据）你在快递柜寄件（插入数据），柜子自动生成。：插入后获取ID（适合MySQL）→ 把号码写入包裹单的"id"栏。确保快递柜（数据库）支持自增功能。MySQL支持批量获取自增ID。Oracle需配合序列使用。SQL Server需检查。
2025-06-05 11:44:13
617
原创 Mybatis如何执行批量插入?
SQL长度有限制（需注意数据库配置的max_allowed_packet）箱子太大（SQL太长）会被收费站（max_allowed_packet）拦下。1000个快递要重复1000次流程，前台累瘫（性能差）寄100件要跑100次，累到虚脱（10秒）流水线自动处理，100件秒过（0.5秒）整列车直接发走，万件起步（0.1秒）1车拉走100件，但装箱慢（3秒）包裹预处理（预编译SQL）只做一次。但需要提前报备（文件预处理）卡车（数据库连接）只跑一趟。传送带自动分拣（批量执行）批量操作必须显式管理事务。
2025-06-05 11:33:48
996
原创 跨域请求是什么？有什么问题？怎么解决？
跨域是指浏览器在发起⽹络请求时，会检查该请求所对应的协议、域名、端⼝和当前⽹⻚是否⼀致，如 果不⼀致则浏览器会进⾏限制，⽐如在www.baidu.com的某个⽹⻚中，如果使⽤ajax去访问 www.jd.com是不⾏的，但是如果是img、iframe、script等标签的src属性去访问则是可以的，之所以浏览器要做这层限制，是为了⽤户信息安全。jsonp的⽅式，该技术底层就是基于script标签来实现的，因为script标签是可以跨域的。⽹关，和第三种⽅式类似，都是交给后台服务来进⾏跨域访问。
2025-05-21 15:36:55
282
原创 浏览器发出⼀个请求到收到响应经历了哪些步骤？
然后servlet来处理这个请求，如果是SpringMVC中的DispatcherServlet，那么则会找到对应的Controller中的⽅法，并执⾏该⽅法得到结果。服务器收到请求后，根据请求所指定的端⼝，将请求传递给绑定了该端⼝的应⽤程序，⽐如8080被tomcat占⽤了。tomcat接收到请求数据后，按照http协议的格式进⾏解析，解析得到所要访问的servlet。Tomcat得到响应结果后封装成HTTP响应的格式，并再次通过⽹络发送给浏览器所在的服务器。
2025-05-21 15:36:16
112
原创 TCP的三次握手和四次挥手
服务端接收FIN后，向客户端发送ACK，表示我接收到了断开连接的请求，客户端你可以不发数据了，不过服务端这边可能还有数据正在处理。TCP协议是7层网络协议中的传输层协议，负责数据的可靠传输。服务端处理完所有数据后，向客户端发送FIN，表示服务端现在可以断开连接。客户端收到服务端的FIN，向服务端发送ACK，表示客户端也会断开连接了。客户端接收到SYN_ACK后，再给服务端发送⼀个ACK。服务端接收到SYN后，给客户端发送⼀个SYN_ACK。客户端向服务端发送⼀个SYN。客户端向服务端发送FIN。
2025-05-21 15:35:35
129
原创 epoll和poll的区别
epoll模型，epoll和poll是完全不同的，epoll是⼀种事件通知模型，当发⽣了IO事件时，应⽤程序才进⾏IO操作，不需要像poll模型那样主动去轮询。poll模型，使⽤的是链表来存储Socket连接⽂件描述符，容量是不固定的，同样需要通过轮询来判断是否发⽣了IO事件。select模型，使⽤的是数组来存储Socket连接⽂件描述符，容量是固定的，需要通过轮询来判断是否发⽣了IO事件。
2025-05-21 15:34:55
131
原创 什么是SSO？与OAuth2.0有什么关系？
OAuth2.0的使⽤场景通常称为联合登录， ⼀处注册，多处使⽤SSO Single Sign On 单点登录。⾸先需要待接⼊的第三⽅应⽤在开放授权平台进⾏注册，注册需要提供⼏个必要的信息clintID, 消息推送地址，密钥(⼀对公私钥，私钥由授权平台⾃⼰保存，公钥分发给第三⽅应⽤)。接下来：授权开放平台同步响应第三⽅应⽤的只是消息是否处理成功的结果。⽽真正的业务数据由授权开放平台异步推动给第三⽅应⽤预留的推送地址。然后，第三⽅应⽤引导客户发起请求时，采⽤公钥进⾏参数加密，授权开放平台使⽤对应的私钥解密。
2025-05-21 15:34:18
116
原创 什么是OAuth2.0协议？有哪⼏种认证⽅式？
OAuth2.0是⼀个开放标准，允许⽤户授权第三⽅应⽤程序访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享他们数据的所有内容。OAuth2.0协议的认证流程，简单理解，就是允许我们将之前的授权和认证过程交给⼀个独⽴的第三⽅进⾏担保。
2025-05-21 15:33:39
191
原创 什么是CSRF攻击？如何防止？
CSRF： Cross Site Requst Forgery 跨站请求伪造，⼀个正常的请求会将合法⽤户的session id保存到浏览器的cookie。这时候，如果⽤户在浏览器中打来另⼀个tab⻚， 那这个tab⻚也是可以获得浏览器的cookie。如果有⼀个⽤户，登录了银⾏⽹站，然后⼜打开浏览器的另⼀个tab⻚，点击了这个图⽚。这时，银⾏就会受理到⼀个带了正确cookie的请求，就会完成转账。在请求中放⼊⼀个攻击者⽆法伪造的信息，并且该信息不存在于cookie当中。尽量使⽤POST请求，限制GET请求。
2025-05-21 15:32:56
194
原创 什么是认证和授权？如何设计⼀个权限认证框架？
当服务器tomcat第⼀次接收到客户端的请求时，会开辟⼀块独⽴的session空间，建⽴⼀个session对象，同时会⽣成⼀个session id，通过响应头的⽅式保存到客户端浏览器的cookie当中。以后客户端的每次请求，都会在请求头部带上这个session id，这样就可以对应上服务端的⼀些会话的相关信息，⽐如⽤户的登录状态。session黏贴： 在负载均衡中，通过⼀个机制保证同⼀个客户端的所有请求都会转发到同⼀个tomcat实例当中。如果没有客户端的Cookie，Session是⽆法进⾏身份验证的。
2025-05-21 15:31:35
136
原创 从业务场景的角度，让你设计⼀个MQ，你会如何设计？
支持多种寄件方式：电话/APP/柜台（HTTP/MQTT协议）全局有序：单写者模式（如Kafka的单Partition）设计：专车直送+全程GPS追踪（同步刷盘+事务消息）设计：临时仓库+分批次发货（内存队列+批量压缩）：高峰期提示"当前排队50人"（令牌桶限流）客户端保存：灵活重置（如RocketMQ）：同一收件人的包裹必须按顺序送（哈希分区）物联网场景：Kafka分区设计+分层存储。服务端保存：简化客户端（如Kafka）设计：空运+多港口备份（多副本同步）让客户先领"电子排队号"（请求入队）
2025-05-21 15:27:36
718
原创 如何保证消息的高效读写？
零拷⻉： 有两种⽅式， mmap和transfile，Java当中对零拷⻉进⾏了封装， Mmap⽅式通过MappedByteBuffer对象进⾏操作，⽽transfile通过FileChannel来进⾏操作。每次顾客要货，店员都得去仓库查库存（磁盘IO），来回跑腿（高延迟）顾客点汉堡后，店员现去农场杀牛（从磁盘读取），等1小时（高延迟）所有顾客排一队，等唯一收银员（全局锁），队伍越来越长（低吞吐）到货架（PageCache），顾客直接取货（内存访问）。：搬运工（CPU）累死，发货慢（高CPU占用）
2025-05-14 15:55:56
956
原创 消息队列有哪些作用
如果使用消息队列的⽅式来调⽤某个系统，那么消息将在队列中排队，由消费者⾃⼰控制消费速度。使用消息队列来作为两个系统之间的通讯⽅式，两个系统不需要相互依赖了。故障系统恢复后自动继续处理（如物流系统宕机2小时不影响下单）系统A给消息队列发送完消息之后，就可以继续做其他事情了。电商订单系统：订单服务与库存/物流/短信服务解耦。消息存活时间（TTL）：设置30分钟过期。数据仓库：业务系统与数据分析系统隔离。新增消费者无需修改生产者代码。死信队列：处理超时未消费订单。
2025-05-08 16:57:04
266
原创 消息队列如何保证消息可靠传输
broker要等待消费者真正确认消费到了消息时才删除掉消息，这⾥通常就是消费端ack机制，消费 者接收到⼀条消息后，如果确认没问题了，就可以给broker发送⼀个ack，broker接收到ack后才会删除消息。⽣产者发送消息时，要确认broker确实收到并持久化了这条消息，⽐如RabbitMQ的confirm机制， Kafka的ack机制都可以保证⽣产者能正确的将消息发送给broker。消息不能少，意思就是消息不能丢失，⽣产者发送的消息，消费者⼀定要能消费到，对于这个问题，就要考虑两个⽅⾯。
2025-05-08 16:36:43
798
原创 RocketMQ为什么速度快
我们在写⼊commitlog的时候是顺序写⼊的，这样比随机写⼊的性能就会提高很多，写⼊commitlog的时候并不是直接写⼊磁盘，⽽是先写⼊操作系统的PageCache，最后由操作系统异步将缓存中的数据刷到磁盘。传统MQ痛点：磁盘随机I/O瓶颈、网络协议栈开销、内存拷贝过多。设计目标：实现"三高"架构（高吞吐、低延迟、高可靠）极小消息体（<100字节）：协议头开销占比过高。强顺序但低吞吐场景：Kafka分区模式更优。新型压缩算法ZSTD替代LZ4。单集群处理消息：4.6万亿条。最大吞吐：1.2亿TPS。
2025-05-08 16:30:49
593
原创 RocketMQ的实现原理
从消息存储到分布式协调，深入剖析RocketMQ的核心设计，结合阿里双11实战经验，揭示其高吞吐、高可用的秘密。获取Broker服务器地址，根据负载均衡算法选择⼀台服务器来发送消息；：所有Topic消息混合追加，提升磁盘IOPS 10倍。注册，并保持长连接，每30s发送⼀次心跳；Broker（RocketMQ进程）NameServer 注册中心集群。掌握这些原理，你的消息系统就能迎接。地址，然后主动拉取消息来消费。是主车道（所有车辆有序通行）Producer⽣产者集群。Consumer消费者集群。
2025-05-08 14:56:23
788
原创 为什么RocketMQ不使用Zookeeper作为注册中心呢？
⽽且本身存储的数据应该是⾼度定制化的。基于性能的考虑，NameServer本身的实现⾮常轻量，⽽且可以通过增加机器的⽅式⽔平扩展，增加集 群的抗压能⼒，⽽zookeeper的写是不可扩展的，⽽zookeeper要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，⾸先操作起来太复杂，其次这样还是⼜违反了CAP中的A的设计，导致服务之间是不连通的。当RocketMQ需要与其他系统协同（如Dubbo服务发现）时，可额外集成ZooKeeper，但核心路由管理仍由NameServer负责。
2025-05-08 14:34:49
969
原创 RocketMQ的事务消息是如何实现的
并且⽣产者订单系统还可以提供Broker回调接⼝，当Broker发现⼀段时间half消息没有收到任何操作命令，则会主动调此接⼝来查询订单是否创建成功。⼀旦half消息commit了，消费者库存系统就会来消费，如果消费成功，则消息销毁，分布式事务成功结束。⽣产者订单系统先发送⼀条half消息到Broker，half消息对消费者⽽⾔是不可⻅的。如果消费失败，则根据重试策略进⾏重试，最后还失败则进⼊死信队列，等待进⼀步处理。：发送半消息到Broker（不执行本地事务）：本地事务成功后异步通知Broker。
2025-05-08 14:28:22
575
原创 Kafka如何实现延迟队列？
如果采⽤每秒定时推进， 那么获取到第⼀个超时的任务列表时执⾏的200次推进中有199次属于“空推进”，⽽获取到第⼆个超时任 务时有需要执⾏639次“空推进”，这样会⽆故空耗机器的性能资源，这⾥采⽤DelayQueue来辅助以少量空间换时间，从⽽做到了“精准推进”。Kafka中的定时器真可谓是“知⼈善⽤”，⽤TimingWheel做最擅⻓的任务添加和删除操作，⽽⽤DelayQueue做最擅⻓的时间推进⼯作，相辅相成。Kafka中的定时器借助了JDK中的DelayQueue来协助推进时间轮。
2025-05-08 11:59:09
1127
原创 Kafka中是怎么体现消息顺序性的？
kafka每个partition中的消息在写⼊时都是有序的，消费时，每个partition只能被每⼀个group中的⼀个消费者消费，保证了消费时也是有序的。如果为了保证topic整个有序，那么将partition调整为1.实现消息有序，但需注意全局顺序的限制。以下是关键设计原理和最佳实践。同一车道（分区）内车辆（消息）严格按序行驶。选择合适的分区策略（Key设计）就是。：Kafka原生支持，满足90%场景。✅ 订单状态流、设备事件时序记录。：丧失并行能力，吞吐量骤降。Kafka的顺序性如同。
2025-05-07 11:53:18
415
原创 kafaka⽣产数据时数据的分组策略
⽣产者决定数据产⽣到集群的哪个 partition 中每⼀条消息都是以（ key， value）格式 Key是由⽣产者发送数据传⼊所以⽣产者（ key）决定了数据产⽣到集群的哪个 partition。：保证相同 Key 的消息进入同一分区（如订单状态更新）。✅ 避免热点分区（如大 Key 导致单个分区过载）。→ 用 RoundRobin（如日志收集）。→ 用 Key 哈希（如订单处理）。：完全忽略 Key，严格轮询分区。：均匀分布负载（如日志收集）。分组（如地区、用户类型）。接口（如按地域分组）。
2025-05-07 11:49:33
495
原创 Kafka消费者负载均衡策略
从分区分配算法到Rebalance机制，全面解析Kafka如何实现消费者间的负载均衡，并提供调优建议和问题解决方案。⼀个消费者组中的⼀个分⽚对应⼀个消费者成员，他能保证每个消费者成员都能访问，如果组中成员太多会有空闲的成员。通过合理配置，Kafka消费者组可以像。Kafka提供三种分区分配策略，通过。第一个加入组的消费者成为Leader。理想比例：1消费者处理1-3个分区。Leader负责计算分配方案。：根据网络质量调整超时时间。分区数 ≥ 消费者数量。仅重新分配受影响的分区。：分区数应预留扩容空间。
2025-05-07 11:02:03
880
原创 Kafka的消费者如何消费数据
消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（ offset）的位置等到下次消费时，他会接着上次位置继续消费。从初始化连接到提交偏移量，详细解析 Kafka 消费者的工作机制，并提供多语言代码示例和调优策略。掌握这些机制后，你的消费者就能像。Kafka消费者通过。→ 组内自动负载分配。
2025-05-07 10:30:44
520
原创 Kafka创建 Topic 时如何将分区放置到不同的 Broker 中
其他分区的第⼀个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个Broker， 5 个分区，假设第⼀个分区放在第四个 Broker 上，那么第⼆个分区将会放在第五个 Broker 上；第三个分区将会放在第⼀个 Broker 上；剩余的副本相对于第⼀个副本放置位置其实是由 nextReplicaShift 决定的，⽽这个数也是随机产生的。第⼀个分区（编号为 0）的第⼀个副本放置位置是随机从 brokerList 选择的；：每个分区的副本会尽量分配到不同 Broker（避免单点故障）。
2025-05-07 10:25:22
882
原创 Kafka与传统消息系统之间有三个关键区别
类比消息系统，直观对比Kafka与传统方案（如RabbitMQ）的核心差异，揭示其成为大数据时代首选的原因。Kafka 是⼀个分布式系统：它以集群的⽅式运⾏，可以灵活伸缩，在内部通过复制数据提升容错能⼒和⾼可⽤性。Kafka 持久化日志，这些日志可以被重复读取和无限期保留。（即时配送但不留底）。（持久化+批量运输），传统消息系统像。Kafka ⽀持实时的流式处理。RabbitMQ适合。
2025-05-06 17:40:54
432
原创 Kafka高效文件存储设计特点
Kafka 把 topic 中⼀个 parition ⼤⽂件分成多个⼩⽂件段，通过多个⼩⽂件段，就容易定期清除或删除已经消费完⽂件，减少磁盘占⽤。以下是 Kafka 存储系统的核心设计特点，用通俗易懂的方式解释其工作原理。通过索引⽂件稀疏存储，可以⼤幅降低 index 文件元数据占用空间大小。（SSD 可达 500MB/s，HDD 可达 100MB/s）。：相当于每本书都登记位置（索引巨大），Kafka的目录。（传统数据库需要随机读写），大幅提升磁盘写入速度。（即使 TB 级数据，也能快速定位）。
2025-04-30 15:58:15
689
原创 Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么
AR:Assigned Replicas 所有副本ISR是由leader维护，follower从leader同步数据有⼀些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只⽀持replica.lag.time.max.ms这个维度），任意⼀个超过阈值都会把follower剔除出ISR, 存⼊OSR（Outof-Sync Replicas）列表，新加⼊的follower也会先存放在OSR中。
2025-04-30 15:30:59
1056
原创 为什么要使用 Kafka，为什么要使用消息队列?
项⽬开始的时候，并不能确定具体需求。冗余 ：可以采⽤⼀对多的⽅式，⼀个⽣产者发布消息，可以被多个订阅topic的服务消费到，供多个毫⽆关联的业务使⽤。消息队列提供了异步处理机制，允许⽤户把⼀个消息放⼊队列， 但并不⽴即处理它。上游数据时有突发流量，下游可能扛不住，或者下游没有⾜够多的机器来保证冗余， kafka在中间可以起到⼀个缓冲的作⽤，把消息暂存在kafka中，下游服务就可以按照⾃⼰的节奏进⾏慢慢处理。从系统解耦到实时流处理，深入解析消息队列的核心价值及Kafka的不可替代性，附典型场景和选型对比。
2025-04-30 14:46:27
855
原创 Kafka的Pull和Push分别有什么优缺点?
push表示Broker主动给消费者推送消息，所以肯定是有消息时才会推送，但是消费者不能按⾃⼰的能⼒来消费消息，推过来多少消息，消费者就得消费多少消息，所以可能会造成⽹络堵塞，消费者 压⼒⼤等问题。pull表示消费者主动拉取，可以批量拉取，也可以单条拉取，所以pull可以由消费者⾃⼰控制，根据自己的消息处理能⼒来进⾏控制，但是消费者不能及时知道是否有消息，可能会拉到的消息为空。从设计哲学到性能影响，全面解析两种消息获取方式的优劣及适用场景，附关键配置建议。：消费者根据自身处理能力拉取，避免过载。
2025-04-30 14:34:22
609
原创 Kafka为什么吞吐量高？
Kafka的生产者采用的是异步发送消息机制，当发送⼀条消息时，消息并没有发送到Broker⽽是缓存起 来，然后直接向业务返回成功，当缓存的消息达到⼀定数量时再批量发送给Broker。这种做法减少了⽹络io，从⽽提⾼了消息发送的吞吐量，但是如果消息⽣产者宕机，会导致消息丢失，业务出错，所以理 论上kafka利⽤此机制提⾼了性能却降低了可靠性。通过6大核心设计原理，结合底层实现细节和性能对比，揭示Kafka百万级TPS背后的工程智慧。：避免磁头寻道（机械硬盘随机IO比顺序IO慢。：减少网络/磁盘IO次数。
2025-04-29 17:39:06
856
原创 Kafka是什么
broker：Kafka 服务器，负责消息存储和转发topic：消息类别， Kafka 按照 topic 来分类消息partition：topic 的分区，⼀个 topic 可以包含多个 partition， topic 消息保存在各个partition 上offset：消息在⽇志中的位置，可以理解是消息在 partition 上的偏移量，也是代表该消息的唯⼀序号。」类比Kafka的核心概念，结合架构图和关键配置，让你彻底掌握这一高吞吐消息系统的设计精髓。系统调用跳过用户空间拷贝。的提交日志服务，通过。
2025-04-29 17:33:16
827
原创 RabbitMQ镜像队列机制
镜像queue有master节点和slave节点。master和slave是针对⼀个queue⽽⾔的，⽽不是⼀个node作为 所有queue的master，其它node作为slave。⼀个queue第⼀次创建的node为它的master节点，其它node为slave节点。⽆论客户端的请求打到master还是slave最终数据都是从master节点获取。当请求打到master节点时， master节点直接将消息返回给client，同时master节点会通过GM（Guaranteed Multicast）协议将
2025-04-29 14:43:17
1024
原创 RabbitMQ死信队列、延时队列
为每个需要使⽤死信的业务队列配置⼀个死信交换机，这⾥同⼀个项目的死信交换机可以共⽤⼀个，然后为每个业务队列分配⼀个单独的路由key，死信队列只不过是绑定在死信交换机上的队列，死信交换 机也不是什么特殊的交换机，只不过是⽤来接受死信的交换机，所以可以为任何类型【Direct、 Fanout、Topic】如果同时配置了队列的TTL和消息的TTL，那么较⼩的那个值将会被使。“死信” 消息会被RabbitMQ进⾏特殊处理，如果配置了死信队列信息，那么 该消息将会被丢进死信队列中，如果没有配置，则该消息将会被丢弃。
2025-04-29 11:11:51
787
原创 RabbitMQ事务消息
如果其中任意⼀个环节出现问题，就会抛出IoException异常，⽤户可以拦截异常进⾏事务回滚，或决定要不要重复消息。autoAck=true，不⽀持事务的，也就是说你即使在收到消息之后在回滚事务也是于事⽆补的，队列已经把消息移除了。从实现原理到生产实践，全面剖析RabbitMQ的事务机制及其替代方案，助你在可靠性与性能间做出平衡。发送消息，可以是多条，可以是消费消息提交ack。autoAck=false，⼿动提交ack，以事务提交或回滚为准；channel.txCommit()提交事务；
2025-04-29 10:32:11
467
原创 RabbitMQ如何确保消息发送 ？ 消息接收？
⼀旦消息被投递到queue（可持久化的消息需要写⼊磁盘），信道会发送⼀个确认给⽣产者（包含消息唯⼀ ID）。但是没有对消息被 confirm 的快慢做任何保证，并且同⼀条消息不会既被 confirm⼜被nack 发送⽅确认模式是异步的，⽣产者应⽤程序在等待确认的同时，可以继续发送消息。RabbitMQ不会为未ack的消息设置超时时间，它判断此消息是否需要重新投递给消费者的唯⼀依据是消费该消息的消费者连接是否已经断开。消费者接收每⼀条消息后都必须进⾏确认（消息接收和消息确认是两个不同操作）。
2025-04-29 10:06:34
566
原创 简述RabbitMQ的架构设计
多个消费者可以订阅同⼀个队列，这时队列中的消 息会被平均分摊(轮询)给多个消费者进⾏消费，⽽不是每个消费者都收到所有的消息进⾏消费。(注意：RabbitMQ不⽀持队列层⾯的⼴播消费，如果需要⼴播消费，可以采⽤⼀个交换器通过路由Key绑定多个队列，由多个消费者来订阅这些队列的⽅式。⽣产者将消息发送给交换器的时候，⼀般会指定⼀个RoutingKey，⽤来指定 这个消息的路由规则。通过绑定将交换器和队列关联起来，在绑定的时候⼀般会指定⼀个绑定键，这样RabbitMQ就 可以指定如何正确的路由到队列了。
2025-04-28 17:29:19
618
原创 如何进行产品选型？
基于性能、可靠性、生态等核心维度，结合真实生产经验，给出可落地的选型建议。附对比矩阵和场景化推荐。多语言方案：通过Proxy代理层（如RocketMQ-Proxy）提供HTTP接口。：关键业务用RocketMQ+非关键日志用Kafka。与Spark/Flink等大数据工具无缝集成。灵活的路由规则（直连/主题/扇出交换器）事务消息+死信队列确保资金操作可靠性。轻量级AMQP协议适合设备资源限制。选择没有银弹，只有最适合！超高吞吐适配日志批量传输。使用惰性队列减少内存压力。：设计可替换的消息抽象层。
2025-04-28 16:05:56
898
计算机组成原理（唐朔飞）
2018-03-08
Java SSH spring 无法读取候选组件类
2017-11-15
ASP.NET MVC 怎么实现显示登录用用户名
2017-06-11
Asp.net</form> 的问题
2017-05-31
这是什么问题 看的不是很明白
2017-05-30
TA创建的收藏夹 TA关注的收藏夹
TA关注的人