- 综合排序
- 最热优先
- 最新优先
- 来自专栏这里只有VxWorks
关于ISR
ISR，中断服务程序或中断处理程序，就是用来响应中断的。当硬件触发中断时，ISR就会立即执行。 在大多数架构里，所有中断使用同一个栈。 这个中断栈是在系统启动时初始化，其尺寸由宏ISR_STACK_SIZE定义。 下文是默认值，可以在BSP中再重新定义 CPU ISR_STACK_SIZE AM29XXX 10000 COLDFIRE 1000 I960 1000 MC680X0 1000 MIPS 5000 PPC 使用命令isrShow()，可以查看已安装的所有ISR ? define IVEC_TO_INUM(intVec) (intVec) #define INUM_TO_IVEC(intNum) ((VOIDFUNCPTR *)intNum) 例如上图中isr5
1.8K20发布于 2020-10-19 - 来自专栏这里只有VxWorks
ISR之编程限制
编写ISR最基本的原则就是:尽可能短。代码少是一方面，更重要的是ISR里不能调用可能阻塞或延迟的操作。 因为ISR不在常规任务上下文中运行，并且没有TCB，而是所有ISR共享一个栈(ISR_STACK_SIZE)。因此，ISR不能调用可能阻塞的函数。 ISR还可以调用VxWorks的一些机制来将消息打印到系统控制台：logMsg()、kprintf()和kputs()。 ISR不能调用使用浮点协处理器的机制。 如果ISR必须要使用浮点指令，则需要使用fppArchLib中的函数显式保存和还原浮点协处理器的寄存器。 ISR中调用C++语句时要特别小心。 ISR可以向管道发送消息。如果管道已满，则丢弃该消息 信号。ISR可以向任务发送信号，从而导致其信号处理程序的异步调度 VxWorks Event。
1.5K20发布于 2020-01-17 - 来自专栏我的技术专刊
ISR HW、LEO、LSO、LW 详解
分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW，对消费这而言只能消费HW之前的消息。 所有与leader副本保持一定程度同步的副本（包括Leader）组成ISR（In- Sync Replicas），ISR集合是AR集合中的一个子集。 -1：producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。 但是这样也不能保证数据不丢失，比如当ISR中只剩下一个leader时，这样就变成了acks=1的情况。 false：只有在ISR中存在的replica才有成为leader的可能。
1.1K10编辑于 2021-12-15 - 来自专栏后端进阶
Kafka ISR 副本同步机制
ISR（in-sync replica） 就是 Kafka 为某个分区维护的一组同步集合，即每个分区都有自己的一个 ISR 集合，处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。 一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟 zk 的同步机制不一样，zk 只需要超过半数节点写入，就可被视为已写入成功。 ，因此，该集群需要把 replica.lag.max.messages 的值设置成很大才能够避免 follower 副本频繁被踢出 ISR。 中，这就很好地避免了在某个瞬间生产者一下子发送大量消息到 leader 副本导致该分区 ISR 频繁收缩与扩张的问题了。
3.9K10发布于 2019-11-11 - 来自专栏shysh95
Kafka副本与ISR设计(I)
因此Kafka内部维护了一组具有资格的follower副本，他们统称ISR。 ISR中的副本会被剔除，也会有新增。 只有所有处于ISR中副本都更新了自己LEO以后，leader的HW才会右移表示写入消息成功。 ISR ISR其实就是Kafka内部维护的具有竞争上岗的一组与leader同步follower的副本集合。 中的副本消息数落后于leader副本的消息数超过了该参数的设置，将会被踢出ISR。 考虑以下这个情况，kafka在的生产者的生产速率不是平稳的，会有高峰会有低峰，在高峰的时候，由于消息大量聚集产生，导致ISR中的消息与Leader的消息差超过了该数值，因此ISR中的副本将会被踢出。
92620发布于 2020-03-06 - 来自专栏EffectiveCoding
Kafka “不丢消息” ISR 机制解析
Kafka 交付语义、producer中都提到了消息提交给broker中，基本就不会丢消息了，而这个不丢消息主要是依赖于broker 中的ISR机制。 ISR （in-sync replica）也就是这组与leader保持同步的replica集合，我们要保证不丢消息，首先要保证ISR的存活（至少有一个备份存活），并且消息提交成功。 第一个问题很简单，跟上节奏就加入ISR，跟不上节奏就踢出ISR。 0.9.0.0 之后提供了一个更加适合的方式来解决这个问题，采用Kafka 落后于消费进度的时间长度来判断是否踢出ISR，这样有效的避免了在突发流量偶然落后于leader 被不合理的踢出ISR的情况，如果长时间落后于 leader 这种情况实际故障是需要去踢的也没问题，也就有效的避免了ISR的反复移进移出所带来的代价。
5.8K40发布于 2019-07-31 - 来自专栏运维小路
Kafka-Leader分区(AR +ISR + OSR)
若 ISR 为空，根据 unclean.leader.election.enable 配置决定是否允许从非 ISR 副本选举（可能丢失数据）。 3. ISR（In-Sync Replicas） 当前与 Leader 保持同步的副本集合。只有 ISR 中的副本才可能被选举为 Leader。 生产者可通过 acks=all 确保消息被所有 ISR 副本确认后才视为提交。ISR 中的副本是数据一致性和高可用的核心保障。 4. min.insync.replicas 最小 ISR 副本数，若 ISR 副本数不足，生产者 acks=all 会写入失败。 (3) 故障恢复示例 场景：Leader 宕机，ISR 中有副本 A 和 B。 恢复：Kafka 控制器从 ISR（A 或 B）选举新 Leader。
31300编辑于 2025-06-07 - 来自专栏轻量级微服务
Next.js - SSR SSG CSR ISR Dynamic Routing
ISR (Incremental Static Regeneration)在 Next.js 中使用增量静态生成，只需在 getStaticProps 中添加属性 revalidate，该动作在用户发起页面请求时执行 使用 ISR，就可以在运行时实现静态页面生成，而无需重新构建整个网站。
1.6K20编辑于 2022-12-01 - 来自专栏EffectiveCoding
Kafka “不丢消息” ISR LEO&HW解析
前言 上一篇介绍的ISR的不丢消息的种种备份及冗余机制的所有的核心逻辑都是围绕着HW值、LEO值来展开的，如何合理的更新和存储显得尤为重要。 前面提到了，在producer 产生消息并且LEO成功更新时，HW的值可能会尝试更新（这需要根据ISR的同步策略来确定），然后还有leader在处理FETCH的请求时也会尝试更新。 另外还有就是follower时、某个副本被提出ISR时都会尝试更新对应的HW值。 这四种情形里面，最常见的就是接受FETCH请求时，通过比较自己的LEO值与缓存的其他的follower的LEO值，选择其中最小的LEO值来作为HW值，所以说HW值实际上就是ISR中最小的副本的LEO值啦 ISR新老版本的消息同步策略基本都在这里了，大家对于整个消息的保存策略、内部消息同步策略、消息交付语义的保证应该有了一定程度上的认知啦。
1.7K20发布于 2019-07-31 - 来自专栏后端从入门到精通
副本与ISR设计--Kafka从入门到精通（十四）
Broker消息设计--Kafka从入门到精通（十三） 一、副本与ISR设计 首先kafka本质就是个备份日志，利用多份相同的数据来提供冗余机制保证高可用。 ISR(in-sync replicas)，就是kafka动态维护副本的机制，每个topic分区都有自己的ISR列表，isr中所有副本都和leader保持数据同步，也包含leade，只有isr中副本才有选举资格 ISR副本集合：包含leader副本和所有follower副本集合。 2、Broker崩溃导致副本被踢出ISR。 3、Leader处理follower的fetch请求时。 4、Producer向leader副本写入消息时候。 满足两个条件才可以更新： 1、处于ISR中。 2、副本LEO落后leader LEO的时长不大于replica.lag.time.ms（默认10s）。
67810编辑于 2022-12-14 - 来自专栏分布式系统进阶
ISR列表是如何变化的?Kafka源码分析-汇总
ISR列表: 所有同partiton leader数据同步的Replica集合; 在不允许partition leader脏选举的情况下, partition leader只能从ISR列表中选取; 根据 ISR的定义可知, ISR列表的成员是有可能动态变化的, 集合可能被扩充, 也可能被收缩; ISR列表的维护由每个Partition的leader replica负责; ---- ISR列表收缩 ReplicatManager 在启动时会启动一个周期性任务, 来定期查看是否有ISR列表需要收缩: scheduler.schedule("isr-expiration", maybeShrinkIsr, period = config.replicaLagTimeMaxMs ISR列表扩容 ISR扩容操作位于Partition::maybeExpandIsr中: val leaderHWIncremented = inWriteLock(leaderIsrUpdateLock ; ReplicaManager在启动时还会启动一个周期性任务maybePropagateIsrChanges, 来定期将ISR在变化的TopicAndParition信息写入zk的/isr_change_notification
3.1K20发布于 2018-09-05 - 来自专栏绿盟科技研究通讯
网络侦察技术在ISR中的应用与挑战
随着信息技术的飞速发展，ISR（情报、监视与侦察）作为维护国家安全的重要手段，在海陆空及网络领域的作用日益凸显。网络侦察技术已成为现代ISR体系中不可或缺的一环。 本文探讨了网络侦察在ISR中的应用，并分析了在网络侦察时在数据方面遇到的一些挑战。 二. 网络侦察在ISR中的应用 ISR作为一项关键的军事活动，通过收集、处理和分析信息来支持军事决策和行动。 如图2.1所示，ISR的情报获取可以分为四个阶段：数据采集、数据组织与存储、情报分析以及决策支持。在数据采集阶段，采用多种技术和方法来获取信息，包括卫星侦察、无人机监视、通信监听和地面侦察。 图2.1 ISR中情报获取流程 2.1 基于网络侦察的信息获取 具体来说，网络侦察技术作为数据采集阶段的重要方式，专注于识别和评估网络环境中的设备和资源。 总结 本文简要探讨了网络侦察技术在ISR领域中的应用，通过主动探测技术发现目标区域的网络设备，对其进行定位、标记生成有效信息，再利用AI技术挖掘关键目标的情报信息，以支持军事决策。
64210编辑于 2024-04-10 - 来自专栏小工匠聊架构
Kafka - AR 、ISR、OSR，以及HW和LEO之间的关系
引子 AR（Assigned Replication）： 分区中的所有副本统称为AR（Assigned Replicas） ISR（In-Sync Replicas）：同步副本集合 ISR是指当前与主副本保持同步的副本集合。 当主副本发生故障时，Kafka会从ISR中选举一个新的主副本来接管工作。因此，ISR的大小对于分区的可用性和性能至关重要。 如果ISR太小，那么当主副本故障时，选举新的主副本可能会导致数据丢失或延迟；如果ISR太大，那么同步数据的成本会变得很高，影响分区的性能。
68620编辑于 2023-07-24 - 来自专栏kk大数据
说一说你对 Kafka 中 ISR 的理解
1、ISR 是什么 首先，ISR 的全称叫做：In-Sync Replicas （同步副本集）, 我们可以理解为和 leader 保持同步的所有副本的集合。 那么此时，ISR=【0,1,2,3】，OSR=【4,5】 如果此时副本 4 追上了 leader-replica，也就是和 leader 保持到了同步 那么此时，ISR=【0,1,2,3,4】，OSR= 【5】 从上面的场景我们就可以明白，ISR 动态维护了一个和 leader 副本保持同步副本集合，ISR 中的副本全部都和 leader 的数据保持同步。 那么对应的，通过 ISR，我们知晓了哪些 follower 与 leader 保持着同步， 那么我们就可以在写入消息的时候，设置写入处于 ISR 中所有的副本才算成功， 那么我们在进行 leader 切换的时候 这就是 ISR 的作用：是通过副本机制实现消息高可靠，服务高可用时，不可缺少的一环；这也是为什么讲到副本不得不提到 ISR 的原因。
3.2K30编辑于 2023-03-03 - 来自专栏前端开发
现代前端开发中的 ISR 概念及其实际应用
ISR 的核心理念ISR 的核心思想是在构建网站时，通过静态生成的方式预渲染部分页面，同时允许在运行时动态更新这些页面的内容。 传统 SSG 和 ISR 的对比在传统的 SSG 中，所有页面的内容都在构建时生成，因此内容的更新需要重新构建和部署整个站点。而在 ISR 中，只需更新需要变更的页面，其余页面仍然使用之前的静态文件。 ISR 的技术实现ISR 的实现通常依赖于现代框架和基础设施的支持。 以下是一些常用框架和平台如何实现 ISR 的案例：Next.js 的 ISRNext.js 是现代前端开发中非常流行的框架之一，其对 ISR 的支持使开发者能够轻松实现增量静态再生。 总结与展望ISR 是现代前端开发中一项重要的技术突破，特别适用于需要高性能和高动态性的场景。通过结合 SSG 和动态更新的优点，ISR 提供了更加灵活和高效的开发模式。
45700编辑于 2024-12-28 - 来自专栏Spark学习技巧
Kafka源码系列之副本同步机制及isr列表更新
kafkaScheduler, logManager, isShuttingDown) replicaManager.startup() 启动的实际上是一个定时调度线程，周期性的检测是否有副本掉队，进而收缩isr 列表 // start ISR expiration thread scheduler.schedule("isr-expiration", maybeShrinkIsr, period = config.replicaLagTimeMaxMs in zk and in cache updateIsr(newInSyncReplicas) // we may need to increment high watermark since ISR replicaManager.isrShrinkRate.mark() } case None => // do nothing if no longer leader } 判断一个副本是否从isr 本文牵涉到一个重要的概念就是ShrinkIsr，弄懂这个概念，首先是要理解什么事isr列表和如何判断一个副本是否应该被移除isr列表。
3.4K61发布于 2018-01-30 - 来自专栏后端进阶
日均千亿消息量的 Kafka 集群频繁发生 ISR 变化，原因竟是...
发现某个节点日志出现 ISR 频繁收缩又扩张的现象，接着查看其他节点，发现只有某个节点会出现这种现象，在 ZMS 中再次查看各个节点的 major GC 情况： ? 从上图可看出，该节点的流出流量少了很多，猜测是因为 follower 副本拉取消息的流量少了很多，也是该节点的 Leader 副本会将 follower 副本踢出 ISR 列表的表现现象。 排查解决问题 既然是增加了那么多客户端连接，那是不是由于 Kafka Broker 处理请求不过来，导致请求阻塞，超时后被断开了，因此才会出现 ISR 变化的同时还会出现连接断开的日志？ 直至目前写完文章，集群现在依然是稳如老狗，集群各个节点没有再发生过 ISR 频繁变化，连接频繁断开的现象了。 下次看到日志由出现频繁断开连接，以及 ISR 频繁发生变化，就需要注意下是否是 Broker 的网络线程出现阻塞了。
1.8K10发布于 2021-02-26 - 来自专栏全栈程序员必看
dirsearch使用方法_ISR6051中文使用手册
dirsearch是一种高级的命令行工具，旨在对web服务器中的目录和文件进行暴力激活成功教程。
3.1K20编辑于 2022-11-08 ZooKeeper生态整合与扩展：深度解析Kafka中的Controller选举与ISR管理
ISR管理：ZooKeeper在数据一致性中的关键角色 在分布式消息系统Kafka中，ISR（In-Sync Replicas，同步副本集）机制是保障数据一致性与高可用性的核心组件之一。 同时，Watcher机制确保了ISR变更的实时性：一旦ZooKeeper中的ISR状态发生变化，相关Broker能够迅速感知并调整数据复制行为。 ISR的管理过程还涉及副本同步机制的细节。 当Leader副本发生故障时，Controller会基于ZooKeeper中存储的ISR列表选举新的Leader——优先选择ISR中的副本，以保证新Leader拥有最新数据。 如果ISR中没有可用副本，Kafka会根据配置策略（如unclean.leader.election.enable）决定是否允许非ISR副本成为Leader，但这可能引发数据丢失。 例如，Controller本身通过ZooKeeper选举产生，并负责监听ISR变更事件；而Broker节点通过/brokers/ids注册自身信息，为ISR列表提供副本标识基础。
26810编辑于 2025-11-28- 来自专栏cc log
卷起来，前端建站SSG，SSR，ISR，Hydration, Island...一网打尽
toc 让建站酷起来 SSR SSG ISR 轮询式刷新 按需刷新 Edge Rendering 酷的“代价” Hydration Selective Hydration Islands ISR ISR（Incremental Static Regeneration）渐进式的静态内容生成。应该是NextJS的首创，从一定程度上优化了SSG了的问题。 the last successfully generated page return res.status(500).send('Error revalidating') } } 当然ISR 上面NextJs的ISR或多或少也是为了解决这个问题。当然另一个更彻底的思路，在边缘的节点上也能有数据持久化的能力，例如cloudflare，或者使用一些分布式的数据库，这里不再展开。
2.3K30编辑于 2022-09-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号