- 博客(292)
- 资源 (2)
- 问答 (5)
- 收藏
- 关注
RSS订阅原创 【Java并发】synchronized
回答锁消除是 JVM 的优化手段：JIT 编译器检测到某些同步代码块的锁对象不存在共享竞争（如局部对象、逃逸分析判定为线程私有），会自动移除锁，减少性能开销。回答JVM 设定偏向锁批量撤销阈值为 40 次，是「性能权衡」的结果，回答synchronized 是 Java 并发的核心考点，面试答题需遵循「先定义→再原理→再场景→最后优化基础层：3 种用法+锁对象，避免基础用法错误；原理层：Mark Word+Monitor+锁升级，理解底层实现；优化层。
2025-12-12 20:15:35
720
原创 【Java并发】线程池
思路：创建多个线程池（对应不同优先级），提交任务时根据优先级选择对应的线程池执行。高优先级任务提交到（核心线程数多、队列容量小），低优先级任务提交到。优点：实现简单，优先级隔离（高优先级任务不会被低优先级任务阻塞）；缺点：资源占用多（多个线程池），可能导致低优先级线程池资源闲置。示例代码// 高优先级线程池（核心线程数多，队列容量小）// 低优先级线程池（核心线程数少，队列容量大）// 提交任务时指定优先级} else {思路：任务实现Comparable接口，通过“
2025-12-12 20:06:11
905
原创 【Java并发】线程
并发：同一时间段内多个任务“交替执行”（单核CPU，通过时间片轮转实现）；因为是交替执行，所以就会诞生高并发问题，也会产生线程安全问题并行：同一时刻多个任务“同时执行”（多核CPU，真正的同时处理）。线程安全：多线程环境下，程序执行结果与单线程一致，且无数据竞争、死锁等问题；临界区：多个线程共享资源的代码块（需同步保护）。多个线程互相持有对方需要的锁且都不释放，导致线程永久阻塞。多线程并发访问时，程序仍保证执行结果正确（符合预期），且无数据污染、死锁等问题。
2025-12-12 19:07:47
764
原创 【MySQL】大厂为什么用 RC（Read Committed）
大厂选择RC的本质是在业务一致性需求和数据库并发性能之间找到最优解：RC以牺牲“不可重复读”和“幻读”的严格一致性为代价，换取更高的并发吞吐量和更灵活的业务适配性，这与大厂高并发、高可用的核心诉求高度匹配。graph LRA[RC核心考点] --> B[基础概念：读已提交，解决脏读]A --> C[底层原理：MVCC+记录锁]A --> D[性能优势：锁范围小，并发高]A --> E[兼容性：Oracle迁移适配]A --> F[binlog：必须搭配Row格式]
2025-12-12 16:45:45
630
原创 【MySQL】索引原理（65道）
数据库索引是帮助数据库系统高效查询、快速定位数据的数据结构加速查询：避免全表扫描（如百万级表全表查需遍历所有数据，索引可直接定位目标数据），降低磁盘I/O次数；优化排序：若查询需按某字段排序（如），若该字段有索引，数据库可直接利用索引的“有序性”返回结果，无需额外排序；减少数据对比：通过索引键的有序性或哈希映射，快速过滤不符合条件的数据，减少无效数据的判断。聚簇索引（Clustered Index）和非聚簇索引（Non-Clustered Index）是B+树索引的两大分类，核心差异在。
2025-12-12 16:30:18
620
原创 【MySQL篇】MySQL8.0新特性
窗口函数（Window Function）允许在一组与当前行相关的行上计算值，不分组聚合（保留原表行数），适用于排名、累计统计等场景。，旧版本双写缓冲区刷新是串行的，而8.0可并行刷新多个页到双写缓冲区和数据文件，提升I/O效率；优势：对于非均匀分布列（如订单状态，大部分为“已完成”），直方图能让优化器准确判断行数，避免选错索引。是存储元数据（表结构、列信息、索引等）的事务性存储引擎（基于InnoDB），替代了旧版本的。：角色是权限的集合，适用于批量管理多个用户的权限（如给所有DBA授予相同权限）。
2025-12-12 16:21:31
776
原创 【MySQL篇】InnoDB
答案答案InnoDB表的物理存储方式，数据按 主键顺序 存储 在B+树的叶子节点，叶子节点包含 完整的行记录数据每张表必须有且仅有一个聚簇索引，通常是主键；若没有显式主键，InnoDB会选择第一个非空唯一索引；若仍没有，则自动生成6字节隐藏主键Insert Buffer(插入缓冲)是InnoDB的一种优化机制，专门针对非唯一二级索引的插入和更新操作自适应哈希索引是InnoDB自动创建的索引结构，通过监控缓冲池中数据页的访问频率，自动为热点数据构建哈希索引，加速等值查询。
2025-12-12 16:15:53
1003
原创 在Mybatis中，Xml映射文件里，除了常见的select|insert|updae|delete 标签之外，还有哪些标签？
通过构造方法注入结果（替代 setter）：定义数据库列与 Java 对象的映射规则。：获取插入后的自增主键（或数据库序列值）：查询用户及其订单（一对一 + 一对多）：处理复杂定制需求（注解中用动态SQL）：像代码中的公共方法，需要时直接调用。：在注解中使用动态 SQL（需配合。：像预制好的「高汤块」，保存常用配方。：VIP顾客优先获取餐号（自增ID）过度嵌套的动态 SQL（可读性差）：设置冷冻库存规则（保存30分钟）：像发黄的纸质菜谱，已被电子菜单（：淘汰策略（LRU/FIFO等）
2025-06-05 12:27:13
939
原创 Mybatis 动态sql有什么用？执行原理？有哪些动态sql？
根据不同条件拼接不同的SQL语句，避免在Java代码中拼接SQL字符串。自动过滤掉无效要求（如顾客说"不要香菜"但本来就没放香菜）顾客改需求："把牛排改全熟，再加黑椒汁" → 自动处理逗号。自动修剪多余的"AND"/"OR"（像去掉菜里多余的装饰）顾客说"如果爱吃辣，就加辣椒" → 实际加辣时才放辣椒。"找浦东新区500-1000万，3房带车位的二手房"把顾客说的"微辣"转换成具体辣度值（如辣度=2）常用的"红烧肉套餐"可以提前备好，直接复用。：忽略矛盾/无效需求（如"冰的热咖啡"）
2025-06-05 12:18:38
660
原创 Mybatis 在mapper中如何传递多个参数?
"面条 牛肉" ← 这是要牛肉面？（厨师困惑：到底是"红烧肉配米饭"还是"红烧肉味的米饭"？清晰高效："#{菜名}：鱼香肉丝 #{辣度}：中辣 ""我要①#{主食}：饺子，②#{蘸料}：醋+辣椒"通过合理选择传参方式，可以使代码既清晰又灵活。厨师要自己解读潦草字迹（通过key取值）：点全套套餐时（前菜+主菜+甜点+饮料）就像去餐厅说："给我第一个和第三个"：字迹不清可能上错菜（key写错）扔出一张便签："多加香菜 不要蒜"对着后厨大喊："米饭 红烧肉"：填菜单（JavaBean）菜单有固定栏目（属性字段）
2025-06-05 12:09:19
3520
原创 Mybatis 如何获取自动生成的(主)键值?
只适用于标准快递柜（MySQL等支持自增的数据库）银行特殊流程（Oracle等需要序列的数据库）快递站同时处理100个包裹，每个包裹自动获得。批量操作时主键会注入到原集合对象的每个元素中。（获取序列），窗口叫号时出示号码（插入数据）你在快递柜寄件（插入数据），柜子自动生成。：插入后获取ID（适合MySQL）→ 把号码写入包裹单的"id"栏。确保快递柜（数据库）支持自增功能。MySQL支持批量获取自增ID。Oracle需配合序列使用。SQL Server需检查。
2025-06-05 11:44:13
876
原创 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
1337
原创 跨域请求是什么？有什么问题？怎么解决？
跨域是指浏览器在发起⽹络请求时，会检查该请求所对应的协议、域名、端⼝和当前⽹⻚是否⼀致，如 果不⼀致则浏览器会进⾏限制，⽐如在www.baidu.com的某个⽹⻚中，如果使⽤ajax去访问 www.jd.com是不⾏的，但是如果是img、iframe、script等标签的src属性去访问则是可以的，之所以浏览器要做这层限制，是为了⽤户信息安全。jsonp的⽅式，该技术底层就是基于script标签来实现的，因为script标签是可以跨域的。⽹关，和第三种⽅式类似，都是交给后台服务来进⾏跨域访问。
2025-05-21 15:36:55
375
原创 浏览器发出⼀个请求到收到响应经历了哪些步骤？
然后servlet来处理这个请求，如果是SpringMVC中的DispatcherServlet，那么则会找到对应的Controller中的⽅法，并执⾏该⽅法得到结果。服务器收到请求后，根据请求所指定的端⼝，将请求传递给绑定了该端⼝的应⽤程序，⽐如8080被tomcat占⽤了。tomcat接收到请求数据后，按照http协议的格式进⾏解析，解析得到所要访问的servlet。Tomcat得到响应结果后封装成HTTP响应的格式，并再次通过⽹络发送给浏览器所在的服务器。
2025-05-21 15:36:16
171
原创 TCP的三次握手和四次挥手
服务端接收FIN后，向客户端发送ACK，表示我接收到了断开连接的请求，客户端你可以不发数据了，不过服务端这边可能还有数据正在处理。TCP协议是7层网络协议中的传输层协议，负责数据的可靠传输。服务端处理完所有数据后，向客户端发送FIN，表示服务端现在可以断开连接。客户端收到服务端的FIN，向服务端发送ACK，表示客户端也会断开连接了。客户端接收到SYN_ACK后，再给服务端发送⼀个ACK。服务端接收到SYN后，给客户端发送⼀个SYN_ACK。客户端向服务端发送⼀个SYN。客户端向服务端发送FIN。
2025-05-21 15:35:35
199
原创 epoll和poll的区别
epoll模型，epoll和poll是完全不同的，epoll是⼀种事件通知模型，当发⽣了IO事件时，应⽤程序才进⾏IO操作，不需要像poll模型那样主动去轮询。poll模型，使⽤的是链表来存储Socket连接⽂件描述符，容量是不固定的，同样需要通过轮询来判断是否发⽣了IO事件。select模型，使⽤的是数组来存储Socket连接⽂件描述符，容量是固定的，需要通过轮询来判断是否发⽣了IO事件。
2025-05-21 15:34:55
188
原创 什么是SSO？与OAuth2.0有什么关系？
OAuth2.0的使⽤场景通常称为联合登录， ⼀处注册，多处使⽤SSO Single Sign On 单点登录。⾸先需要待接⼊的第三⽅应⽤在开放授权平台进⾏注册，注册需要提供⼏个必要的信息clintID, 消息推送地址，密钥(⼀对公私钥，私钥由授权平台⾃⼰保存，公钥分发给第三⽅应⽤)。接下来：授权开放平台同步响应第三⽅应⽤的只是消息是否处理成功的结果。⽽真正的业务数据由授权开放平台异步推动给第三⽅应⽤预留的推送地址。然后，第三⽅应⽤引导客户发起请求时，采⽤公钥进⾏参数加密，授权开放平台使⽤对应的私钥解密。
2025-05-21 15:34:18
296
原创 什么是OAuth2.0协议？有哪⼏种认证⽅式？
OAuth2.0是⼀个开放标准，允许⽤户授权第三⽅应⽤程序访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享他们数据的所有内容。OAuth2.0协议的认证流程，简单理解，就是允许我们将之前的授权和认证过程交给⼀个独⽴的第三⽅进⾏担保。
2025-05-21 15:33:39
261
原创 什么是CSRF攻击？如何防止？
CSRF： Cross Site Requst Forgery 跨站请求伪造，⼀个正常的请求会将合法⽤户的session id保存到浏览器的cookie。这时候，如果⽤户在浏览器中打来另⼀个tab⻚， 那这个tab⻚也是可以获得浏览器的cookie。如果有⼀个⽤户，登录了银⾏⽹站，然后⼜打开浏览器的另⼀个tab⻚，点击了这个图⽚。这时，银⾏就会受理到⼀个带了正确cookie的请求，就会完成转账。在请求中放⼊⼀个攻击者⽆法伪造的信息，并且该信息不存在于cookie当中。尽量使⽤POST请求，限制GET请求。
2025-05-21 15:32:56
247
原创 什么是认证和授权？如何设计⼀个权限认证框架？
当服务器tomcat第⼀次接收到客户端的请求时，会开辟⼀块独⽴的session空间，建⽴⼀个session对象，同时会⽣成⼀个session id，通过响应头的⽅式保存到客户端浏览器的cookie当中。以后客户端的每次请求，都会在请求头部带上这个session id，这样就可以对应上服务端的⼀些会话的相关信息，⽐如⽤户的登录状态。session黏贴： 在负载均衡中，通过⼀个机制保证同⼀个客户端的所有请求都会转发到同⼀个tomcat实例当中。如果没有客户端的Cookie，Session是⽆法进⾏身份验证的。
2025-05-21 15:31:35
202
原创 从业务场景的角度，让你设计⼀个MQ，你会如何设计？
支持多种寄件方式：电话/APP/柜台（HTTP/MQTT协议）全局有序：单写者模式（如Kafka的单Partition）设计：专车直送+全程GPS追踪（同步刷盘+事务消息）设计：临时仓库+分批次发货（内存队列+批量压缩）：高峰期提示"当前排队50人"（令牌桶限流）客户端保存：灵活重置（如RocketMQ）：同一收件人的包裹必须按顺序送（哈希分区）物联网场景：Kafka分区设计+分层存储。服务端保存：简化客户端（如Kafka）设计：空运+多港口备份（多副本同步）让客户先领"电子排队号"（请求入队）
2025-05-21 15:27:36
809
原创 如何保证消息的高效读写？
零拷⻉： 有两种⽅式， mmap和transfile，Java当中对零拷⻉进⾏了封装， Mmap⽅式通过MappedByteBuffer对象进⾏操作，⽽transfile通过FileChannel来进⾏操作。每次顾客要货，店员都得去仓库查库存（磁盘IO），来回跑腿（高延迟）顾客点汉堡后，店员现去农场杀牛（从磁盘读取），等1小时（高延迟）所有顾客排一队，等唯一收银员（全局锁），队伍越来越长（低吞吐）到货架（PageCache），顾客直接取货（内存访问）。：搬运工（CPU）累死，发货慢（高CPU占用）
2025-05-14 15:55:56
1059
原创 消息队列有哪些作用
如果使用消息队列的⽅式来调⽤某个系统，那么消息将在队列中排队，由消费者⾃⼰控制消费速度。使用消息队列来作为两个系统之间的通讯⽅式，两个系统不需要相互依赖了。故障系统恢复后自动继续处理（如物流系统宕机2小时不影响下单）系统A给消息队列发送完消息之后，就可以继续做其他事情了。电商订单系统：订单服务与库存/物流/短信服务解耦。消息存活时间（TTL）：设置30分钟过期。数据仓库：业务系统与数据分析系统隔离。新增消费者无需修改生产者代码。死信队列：处理超时未消费订单。
2025-05-08 16:57:04
345
原创 消息队列如何保证消息可靠传输
broker要等待消费者真正确认消费到了消息时才删除掉消息，这⾥通常就是消费端ack机制，消费 者接收到⼀条消息后，如果确认没问题了，就可以给broker发送⼀个ack，broker接收到ack后才会删除消息。⽣产者发送消息时，要确认broker确实收到并持久化了这条消息，⽐如RabbitMQ的confirm机制， Kafka的ack机制都可以保证⽣产者能正确的将消息发送给broker。消息不能少，意思就是消息不能丢失，⽣产者发送的消息，消费者⼀定要能消费到，对于这个问题，就要考虑两个⽅⾯。
2025-05-08 16:36:43
870
原创 RocketMQ为什么速度快
我们在写⼊commitlog的时候是顺序写⼊的，这样比随机写⼊的性能就会提高很多，写⼊commitlog的时候并不是直接写⼊磁盘，⽽是先写⼊操作系统的PageCache，最后由操作系统异步将缓存中的数据刷到磁盘。传统MQ痛点：磁盘随机I/O瓶颈、网络协议栈开销、内存拷贝过多。设计目标：实现"三高"架构（高吞吐、低延迟、高可靠）极小消息体（<100字节）：协议头开销占比过高。强顺序但低吞吐场景：Kafka分区模式更优。新型压缩算法ZSTD替代LZ4。单集群处理消息：4.6万亿条。最大吞吐：1.2亿TPS。
2025-05-08 16:30:49
696
原创 RocketMQ的实现原理
从消息存储到分布式协调，深入剖析RocketMQ的核心设计，结合阿里双11实战经验，揭示其高吞吐、高可用的秘密。获取Broker服务器地址，根据负载均衡算法选择⼀台服务器来发送消息；：所有Topic消息混合追加，提升磁盘IOPS 10倍。注册，并保持长连接，每30s发送⼀次心跳；Broker（RocketMQ进程）NameServer 注册中心集群。掌握这些原理，你的消息系统就能迎接。地址，然后主动拉取消息来消费。是主车道（所有车辆有序通行）Producer⽣产者集群。Consumer消费者集群。
2025-05-08 14:56:23
957
原创 为什么RocketMQ不使用Zookeeper作为注册中心呢？
⽽且本身存储的数据应该是⾼度定制化的。基于性能的考虑，NameServer本身的实现⾮常轻量，⽽且可以通过增加机器的⽅式⽔平扩展，增加集 群的抗压能⼒，⽽zookeeper的写是不可扩展的，⽽zookeeper要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，⾸先操作起来太复杂，其次这样还是⼜违反了CAP中的A的设计，导致服务之间是不连通的。当RocketMQ需要与其他系统协同（如Dubbo服务发现）时，可额外集成ZooKeeper，但核心路由管理仍由NameServer负责。
2025-05-08 14:34:49
1140
原创 RocketMQ的事务消息是如何实现的
并且⽣产者订单系统还可以提供Broker回调接⼝，当Broker发现⼀段时间half消息没有收到任何操作命令，则会主动调此接⼝来查询订单是否创建成功。⼀旦half消息commit了，消费者库存系统就会来消费，如果消费成功，则消息销毁，分布式事务成功结束。⽣产者订单系统先发送⼀条half消息到Broker，half消息对消费者⽽⾔是不可⻅的。如果消费失败，则根据重试策略进⾏重试，最后还失败则进⼊死信队列，等待进⼀步处理。：发送半消息到Broker（不执行本地事务）：本地事务成功后异步通知Broker。
2025-05-08 14:28:22
663
原创 Kafka如何实现延迟队列？
如果采⽤每秒定时推进， 那么获取到第⼀个超时的任务列表时执⾏的200次推进中有199次属于“空推进”，⽽获取到第⼆个超时任 务时有需要执⾏639次“空推进”，这样会⽆故空耗机器的性能资源，这⾥采⽤DelayQueue来辅助以少量空间换时间，从⽽做到了“精准推进”。Kafka中的定时器真可谓是“知⼈善⽤”，⽤TimingWheel做最擅⻓的任务添加和删除操作，⽽⽤DelayQueue做最擅⻓的时间推进⼯作，相辅相成。Kafka中的定时器借助了JDK中的DelayQueue来协助推进时间轮。
2025-05-08 11:59:09
1679
原创 Kafka中是怎么体现消息顺序性的？
kafka每个partition中的消息在写⼊时都是有序的，消费时，每个partition只能被每⼀个group中的⼀个消费者消费，保证了消费时也是有序的。如果为了保证topic整个有序，那么将partition调整为1.实现消息有序，但需注意全局顺序的限制。以下是关键设计原理和最佳实践。同一车道（分区）内车辆（消息）严格按序行驶。选择合适的分区策略（Key设计）就是。：Kafka原生支持，满足90%场景。✅ 订单状态流、设备事件时序记录。：丧失并行能力，吞吐量骤降。Kafka的顺序性如同。
2025-05-07 11:53:18
535
原创 kafaka⽣产数据时数据的分组策略
⽣产者决定数据产⽣到集群的哪个 partition 中每⼀条消息都是以（ key， value）格式 Key是由⽣产者发送数据传⼊所以⽣产者（ key）决定了数据产⽣到集群的哪个 partition。：保证相同 Key 的消息进入同一分区（如订单状态更新）。✅ 避免热点分区（如大 Key 导致单个分区过载）。→ 用 RoundRobin（如日志收集）。→ 用 Key 哈希（如订单处理）。：完全忽略 Key，严格轮询分区。：均匀分布负载（如日志收集）。分组（如地区、用户类型）。接口（如按地域分组）。
2025-05-07 11:49:33
603
原创 Kafka消费者负载均衡策略
从分区分配算法到Rebalance机制，全面解析Kafka如何实现消费者间的负载均衡，并提供调优建议和问题解决方案。⼀个消费者组中的⼀个分⽚对应⼀个消费者成员，他能保证每个消费者成员都能访问，如果组中成员太多会有空闲的成员。通过合理配置，Kafka消费者组可以像。Kafka提供三种分区分配策略，通过。第一个加入组的消费者成为Leader。理想比例：1消费者处理1-3个分区。Leader负责计算分配方案。：根据网络质量调整超时时间。分区数 ≥ 消费者数量。仅重新分配受影响的分区。：分区数应预留扩容空间。
2025-05-07 11:02:03
1083
原创 Kafka的消费者如何消费数据
消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（ offset）的位置等到下次消费时，他会接着上次位置继续消费。从初始化连接到提交偏移量，详细解析 Kafka 消费者的工作机制，并提供多语言代码示例和调优策略。掌握这些机制后，你的消费者就能像。Kafka消费者通过。→ 组内自动负载分配。
2025-05-07 10:30:44
852
原创 Kafka创建 Topic 时如何将分区放置到不同的 Broker 中
其他分区的第⼀个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个Broker， 5 个分区，假设第⼀个分区放在第四个 Broker 上，那么第⼆个分区将会放在第五个 Broker 上；第三个分区将会放在第⼀个 Broker 上；剩余的副本相对于第⼀个副本放置位置其实是由 nextReplicaShift 决定的，⽽这个数也是随机产生的。第⼀个分区（编号为 0）的第⼀个副本放置位置是随机从 brokerList 选择的；：每个分区的副本会尽量分配到不同 Broker（避免单点故障）。
2025-05-07 10:25:22
1072
原创 Kafka与传统消息系统之间有三个关键区别
类比消息系统，直观对比Kafka与传统方案（如RabbitMQ）的核心差异，揭示其成为大数据时代首选的原因。Kafka 是⼀个分布式系统：它以集群的⽅式运⾏，可以灵活伸缩，在内部通过复制数据提升容错能⼒和⾼可⽤性。Kafka 持久化日志，这些日志可以被重复读取和无限期保留。（即时配送但不留底）。（持久化+批量运输），传统消息系统像。Kafka ⽀持实时的流式处理。RabbitMQ适合。
2025-05-06 17:40:54
668
原创 Kafka高效文件存储设计特点
Kafka 把 topic 中⼀个 parition ⼤⽂件分成多个⼩⽂件段，通过多个⼩⽂件段，就容易定期清除或删除已经消费完⽂件，减少磁盘占⽤。以下是 Kafka 存储系统的核心设计特点，用通俗易懂的方式解释其工作原理。通过索引⽂件稀疏存储，可以⼤幅降低 index 文件元数据占用空间大小。（SSD 可达 500MB/s，HDD 可达 100MB/s）。：相当于每本书都登记位置（索引巨大），Kafka的目录。（传统数据库需要随机读写），大幅提升磁盘写入速度。（即使 TB 级数据，也能快速定位）。
2025-04-30 15:58:15
746
原创 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
1360
原创 为什么要使用 Kafka，为什么要使用消息队列?
项⽬开始的时候，并不能确定具体需求。冗余 ：可以采⽤⼀对多的⽅式，⼀个⽣产者发布消息，可以被多个订阅topic的服务消费到，供多个毫⽆关联的业务使⽤。消息队列提供了异步处理机制，允许⽤户把⼀个消息放⼊队列， 但并不⽴即处理它。上游数据时有突发流量，下游可能扛不住，或者下游没有⾜够多的机器来保证冗余， kafka在中间可以起到⼀个缓冲的作⽤，把消息暂存在kafka中，下游服务就可以按照⾃⼰的节奏进⾏慢慢处理。从系统解耦到实时流处理，深入解析消息队列的核心价值及Kafka的不可替代性，附典型场景和选型对比。
2025-04-30 14:46:27
1033
原创 Kafka的Pull和Push分别有什么优缺点?
push表示Broker主动给消费者推送消息，所以肯定是有消息时才会推送，但是消费者不能按⾃⼰的能⼒来消费消息，推过来多少消息，消费者就得消费多少消息，所以可能会造成⽹络堵塞，消费者 压⼒⼤等问题。pull表示消费者主动拉取，可以批量拉取，也可以单条拉取，所以pull可以由消费者⾃⼰控制，根据自己的消息处理能⼒来进⾏控制，但是消费者不能及时知道是否有消息，可能会拉到的消息为空。从设计哲学到性能影响，全面解析两种消息获取方式的优劣及适用场景，附关键配置建议。：消费者根据自身处理能力拉取，避免过载。
2025-04-30 14:34:22
799
原创 Kafka为什么吞吐量高？
Kafka的生产者采用的是异步发送消息机制，当发送⼀条消息时，消息并没有发送到Broker⽽是缓存起 来，然后直接向业务返回成功，当缓存的消息达到⼀定数量时再批量发送给Broker。这种做法减少了⽹络io，从⽽提⾼了消息发送的吞吐量，但是如果消息⽣产者宕机，会导致消息丢失，业务出错，所以理 论上kafka利⽤此机制提⾼了性能却降低了可靠性。通过6大核心设计原理，结合底层实现细节和性能对比，揭示Kafka百万级TPS背后的工程智慧。：避免磁头寻道（机械硬盘随机IO比顺序IO慢。：减少网络/磁盘IO次数。
2025-04-29 17:39:06
1046
计算机组成原理（唐朔飞）
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关注的人