IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:concurrency control

共 5 篇相关文章

IT 累计浏览 3,114

深入理解Oracle中的Mutex

这篇讲的是Oracle数据库中两种底层串行机制——Mutex与Latch的深度对比分析。作者从内部机制出发,清晰阐述了Mutex为何以及如何在多个场景下成为更优的选择。 关键差异首先体现在效率上:Mutex获取仅需约30~35个CPU指令,而Latch需要150~200个;其内存结构也仅16字节,远小于Latch的112字节。更重要的是,Mutex的设计能大幅减少伪争用——不同于一个Latch保护多个热点对象,一个Mutex可以专门服务于单个数据结构(如每一个父游标或子游标),使得串行控制点更精准。 文章详细剖析了Mutex如何兼具传统Latch和Pin的双重职责。其内嵌的引用计数(ref count)机制,使其能像Pin一样防止对象被释放,同时自身又提供了必要的串行保护。在10.2版本后,这直接替代了游标执行时频繁创建/销毁library cache pin的昂贵操作,后续进程只需轻量级地增减引用计数即可。作者以KKS游标共享为例,列举了在父游标检查、统计信息访问等操作中,Mutex如何带来更低的解析成本和更好的并发性能。 最后,文章也提供了从AWR报告解读Mutex等待事件(如cursor:mutex S/X, cursor:pin S)的思路,并附上了统计信息表示例,为实际的性能诊断提供了具体指引。

IT 累计浏览 2,820

关于两种限流模式

这篇讲的是高并发系统中两种主流的限流模式:滑窗模式与响应模式。滑窗模式是“事后统计”,通过检查过去多个单位时间窗口内的请求总量是否超标来决定是否放行。它的实现像一个环形计数器数组,逻辑直观,但阈值设定依赖经验或压测,且可能因单位时间请求分布不均导致“先松后紧”。文章指出,它更适合作为对单一资源(如数据库、特定API)的刚性保护承诺。 而响应模式则是一种“实时反馈”策略,它只关心当前正在处理的请求数。文章巧妙地指出了限流的根本目的——是保护系统资源不被拖垮。由于系统容量会受GC、依赖抖动等动态因素影响,响应模式通过公式(QPS/1000*RT)动态计算最大并发数,让限流阈值能随系统实际承载能力自动调整,展现了更强的适应性。 文章最后对比了二者的实现思路:滑窗模式基于数组和环形队列记录历史计数;响应模式则仅需一个原子计数器跟踪活跃请求数。这为在确定性资源保护和自适应系统保护两种场景下的选型提供了清晰的技术参考。

IT 累计浏览 5,747

微博架构与平台安全演讲稿

这篇演讲稿来自微博技术团队的分享,深入剖析了微博在架构设计与平台安全方面的实战经验。作者首先指出了微博作为超大规模社交媒体平台所面临的核心挑战:既要平稳承载数亿用户的高并发访问与海量数据洪流,又要时刻应对日益复杂严峻的网络攻击与安全威胁。 针对这些挑战,文章详细阐述了微博架构的演进思路与核心方案。从早期的单一应用架构,逐步演进到现在的微服务化、容器化部署,并通过智能流量调度与多级缓存体系来保障核心业务的稳定性与高性能。在平台安全层面,则重点分享了构建纵深防御体系的实践,包括如何通过精细化的访问控制、实时风险感知以及高效的攻击对抗机制,来保护用户数据与平台服务免受侵害。 整个分享并非泛泛而谈,而是结合了微博真实遇到的性能瓶颈、安全事件以及调优数据进行讲解,清晰地展现了从问题发现、方案设计到最终落地取得效果的完整闭环。其对于高并发场景下的架构弹性设计,以及攻防对抗中的动态防御策略,提供了极具价值的行业参考。

IT 累计浏览 2,642

没有比解决瓶颈更高效的事情了

这篇讲的是作者在虹桥机场排队等车时,观察到的一个让人恼火的效率陷阱。一边是大量出租车空等数小时,另一边是数百位乘客排着长队苦等上车,系统明明有大量闲置运力,却被一个环节死死卡住,导致整体吞吐效率低下。更令人深思的是,即使机场扩建了几倍,这个瓶颈的逻辑却没有被改变。 作者从这个日常痛点出发,提炼出了一个核心观点:在复杂系统中,真正的低效往往不是资源不足,而是资源流动路径上的某个“瓶颈”点在制造堵塞。解决这个瓶颈,哪怕只有一点点松动,带来的整体效率提升,也远比在非瓶颈环节投入大量资源优化要高效得多。 这个观察超越了机场管理,指向了所有涉及流程与资源调度的场景——从软件架构设计、生产流水线到团队工作流。它提醒我们,识别并攻克那个唯一的卡脖子环节,是撬动整体效能提升的最有力支点。

IT 累计浏览 3,823

InnoDB线程并发检查机制

这篇讲的是 InnoDB 在处理高并发请求时,一个关键但有时被忽视的内部机制——并发线程检查。当数据库同时涌入大量连接时,如果不对进入 InnoDB 引擎的线程数量进行控制,极易因资源争抢导致性能急剧下降。 文章核心解释了 innodb_thread_concurrency 这个参数如何充当“交通警察”。当它被设为大于0的值时,检查机制就启动了,InnoDB 只会放行该数量的线程同时进入内部处理,其他线程则需要排队等候。这就像是为发动机设置了一个恒定的进气量,避免“过载”。而当这个参数设为0时,检查机制则被完全关闭,理论上允许所有到达的线程立即竞争资源。 理解这个机制的意义在于,它为我们提供了一个直接干预 InnoDB 内部调度行为的杠杆。在遇到因线程过多导致的上下文切换频繁、CPU 利用率高但吞吐量下降的问题时,合理设置这个参数,往往能起到立竿见影的稳定效果,让数据库的并发处理从混乱归于有序。