- 博客(1545)
- 资源 (14)
- 收藏
- 关注
原创 mysql——count(*)、count(1)和count(字段)谁更快?有什么区别?
本文探讨了MySQL中count()、count(1)和count(属性)的性能差异。通过示例表测试发现,count()和count(1)均统计总行数(包括NULL值),而count(属性)只统计非NULL值行数。MySQL官方文档证实count()和count(1)在功能与性能上完全一致,执行计划显示count()会被优化为count(0)。理论上count(*)略优,因无需SQL优化步骤,但实际性能差异极小。开发者可根据编码规范选择使用,无需过度关注性能差异。
2025-08-14 23:19:44
500
原创 MySql——聚簇索引(主键索引)和非聚簇索索引(非主键索引)引区别(即聚集索引和非聚集索引区别)
本文主要介绍了聚簇索引(主键索引)和非聚簇索引(非主键索引)的区别。聚簇索引将索引和数据存储在同一个B+树中,查询效率较高;而非聚簇索引需要先查询索引再回表获取数据,效率较低。在InnoDB引擎中,主键索引采用聚簇索引结构,数据和索引存储在同一个文件中;而MyISAM引擎则采用非聚簇索引结构,数据和索引分开存储,查询时需要进行回表操作。文章通过图解和存储引擎对比,详细说明了两种索引的结构特点和性能差异,为数据库索引选择提供了参考依据。
2025-08-14 22:23:58
1160
原创 MySql——binlog和redolog的区别
MySQL中的binlog和redolog虽然都记录数据修改,但二者功能不同。binlog是所有存储引擎共用的日志,记录所有操作日志,主要用于主从同步和数据恢复;redolog是InnoDB引擎特有的日志,用于事务数据恢复和BufferPool的崩溃恢复。两者不能互相替代,binlog针对磁盘数据恢复,redolog则确保事务完整性。
2025-08-14 21:39:25
176
原创 MySQL——binlog刷盘机制
MySQL的binlog日志提供三种刷盘策略,通过sync_binlog参数配置:0表示实时写入PageCache但延迟刷盘(性能最高但可能丢失数据);1表示每次事务提交都强制刷盘(最安全但性能低);2表示N次事务提交后刷盘(平衡方案)。MySQL 5.7.7前默认值为0,之后改为1。不同策略在数据安全性和性能间取得平衡,适用于不同业务场景。
2025-08-13 23:33:41
284
原创 Mysql——如何做到Redolog崩溃后恢复的
MySQL引擎层BufferPool工作原理:执行修改语句时,InnoDB首先检查BufferPool缓存,若无则从磁盘加载数据页到BufferPool,修改后成为脏页并记录UndoLog。提交时通过RedoLog保证崩溃恢复,其顺序写入特性比直接写磁盘更高效。InnoDB提供三种刷盘策略:0(延迟1秒写)、1(实时写最安全)、2(系统缓存写),默认采用策略1确保数据不丢失。RedoLog结合BufferPool机制实现了事务持久性和高性能的平衡。
2025-08-13 22:58:17
1163
原创 MySQL——MySQL引擎层BufferPool工作过程原理
MySQL引擎层BufferPool工作过程:执行修改语句时,首先检查BufferPool中是否存在目标数据,若不存在则从磁盘加载整个数据页到BufferPool。修改数据后,BufferPool形成脏页(与磁盘数据不一致),修改前的数据存入UndoLog用于回滚。提交事务时,脏页数据同步到磁盘文件,恢复为正常页。整个过程通过BufferPool减少磁盘I/O,提高性能。
2025-08-12 22:52:04
498
原创 MySql——B树和B+树区别(innoDB引擎为什么把B+树作为默认的数据结构)
本文对比分析了B树和B+树的异同点。二者共同特征是通过有序索引实现快速数据定位,且都遵循"左小右大"的存储原则,减少磁盘IO次数。主要区别在于:B树每个节点存储键值对,适合随机读写;B+树非叶节点仅存键指针,叶节点通过链表连接,存储密度更高,特别适合范围查询和顺序访问。实际应用中,B+树因其更优的查询效率和范围查询性能,成为数据库索引的优先选择。
2025-08-12 22:19:10
404
原创 Mysql——单表最多数据量多少需要分表
MySQL单表分表标准及B+树存储容量分析 阿里开发公约建议单表超过500万行或2GB时考虑分表。B+树的存储能力取决于页大小和行数据量,默认16KB的页可存储约16184字节有效数据。以一个包含5列的表为例,每行约100字节,单页可存161条记录。三层B+树理论上可存储约4.2亿条记录(100字节/行)。实际存储量会随行大小变化,如1KB/行时约4000万条。因此,单纯以行数判断是否分表并不准确,需结合数据容量综合评估。
2025-08-11 22:54:52
872
原创 Mysql——Sql的执行过程
SQL执行过程主要分为建立连接、服务层处理和引擎层操作三个阶段。首先客户端建立数据库连接并验证身份;随后服务层依次执行缓存查询(5.7后默认关闭)、语法解析、预处理、SQL优化(生成执行计划)等操作;最后引擎层通过缓冲池(BufferPool)查询数据,未命中则访问磁盘,并记录binlog/undolog等日志。整个过程涉及多个组件的协同工作,其中优化器会调整SQL以遵循索引规则(如最左前缀原则),提高查询效率。
2025-08-11 21:13:32
476
原创 使用winsw把SpringBoot项目注册成window服务
本文介绍了使用WinSW将Spring Boot项目注册为Windows服务的详细步骤。首先需要将项目打包为JAR文件(如test-server.jar),下载WinSW并重命名为服务名称(如test-server-service.exe)。随后创建XML配置文件,设置服务ID、名称、描述、JVM参数及日志路径等信息。将exe和xml文件与JAR包放在同一目录后,通过管理员权限的命令行执行安装命令(test-server-service.exe install)。文中还提供了服务启动、停止和卸载的具体命令。
2025-08-07 22:11:21
623
原创 架构——异地多活成熟的架构模式
摘要: 本文系统介绍了三种异地多活架构模式:业务定制型、业务通用型和存储通用型。业务定制型针对核心业务定制化设计,复杂度低但扩展性差;业务通用型通过统一配套服务(流量调度、配置中心等)实现多业务兼容,适合业务量大但一致性要求不高的场景;存储通用型依托分布式一致性数据库(如OceanBase、TiDB)天然支持强一致性,适合金融等高要求场景,但对部署距离和成本有较高限制。文章对比了各模式的优缺点及适用场景,为不同业务需求下的架构选型提供了实践指导。
2025-08-03 16:21:44
1657
原创 微服务架构技巧篇——全局幂等
本文探讨了分布式系统中实现全局幂等的关键技术与设计模式。文章首先阐述了幂等在分布式环境中的必要性,特别是在接口调用和消息传递可能失败的情况下。随后提出全局幂等的核心原理:通过"全局唯一标识+状态控制"确保操作一致性。文中详细介绍了三种主要模式:事务级同步处理模式(适合快速同步场景)、事务级异步处理模式(适合耗时异步操作)和接口级自动幂等(适用于关键业务接口)。在技术实现层面,提出了四种幂等判断手段:数据库唯一索引、Redis SETNX命令、ZooKeeper节点创建和状态机判断,并分析
2025-08-03 11:08:07
949
原创 微服务架构技巧篇——分布式事务
摘要:本文探讨了微服务架构下数据一致性的挑战及解决方案。由于微服务拆分导致传统数据库事务失效,需要通过分布式事务来保证数据一致性。文章重点介绍了四种成熟的业务级分布式事务模式:本地事务消息通过记录事务状态实现跨服务协调;MQ事务消息利用消息队列实现二阶段提交;TCC采用Try-Confirm-Cancel三阶段控制;SAGA将长事务拆分为可补偿的子事务序列。每种方案各有特点,适用于不同业务场景,开发者需根据系统需求选择合适方案。这些方案为微服务架构提供了可靠的事务保障机制。
2025-08-03 10:04:21
1087
原创 微服务架构技巧篇——接口类设计技巧
微服务架构特点与接口设计技巧 微服务架构通过服务分布式和数据分布式提升灵活性,但也带来接口设计的挑战。针对前端需多次调用微服务的问题,**BFF(Backend For Frontend)**作为聚合层提供优化接口,解决性能、带宽及开发成本问题,其落地可由前端(Node.js)或后端团队负责,需权衡业务复杂度与团队能力。GraphQL则通过动态查询减少数据传输,客户端可精确指定所需数据,降低请求次数。此外,接口循环调用是微服务的潜在风险,易引发资源耗尽或死锁,目前依赖请求标识和调用链梳理等预防措施,但主要依
2025-07-31 23:05:06
1370
原创 架构实战——架构重构内功心法第三式(运筹帷幄)
架构重构需要采取"分段实施"策略,将问题按优先级、重要性和实施难度划分为不同阶段,每个阶段聚焦解决一类问题。具体做法包括:1)优先解决明显紧急事项;2)按问题性质分类处理;3)采取先易后难顺序;4)控制每个阶段耗时在1-3个月。这种做法能快速见效、降低风险,同时保持团队信心。例如X系统重构就分为"救火"、"优化"和"服务化"三个阶段,逐步解决可用性、系统耦合等问题。合理分段实施可确保重构工作有序推进并取得实效。
2025-07-31 22:20:47
582
原创 架构实战——架构重构内功心法第二式(合纵连横)
架构重构需要有效的沟通策略。技术术语如"可扩展性"、"耦合"等难以被非技术人员理解,应转换为具体问题描述,并用数据支撑(如开发效率、故障影响等)。与其他系统协调时,需换位思考,强调双赢和长期收益,避免"对公司有利"等空泛说辞。若对方优先级不同,可灵活调整计划,明确后续启动时间,分阶段推进重构。关键在于用事实说话,找到各方利益结合点,避免技术术语造成的沟通障碍。
2025-07-30 23:35:12
696
原创 架构实战——架构重构内功心法第一式(有的放矢)
这三个系统重构的方案,现在回过头来看,感觉是理所当然的,但实际上当时做分析和决策时,远远没有这么简单。以 M 系统为例,当时我们接手后遇到的问题有很多,例如:数据经常出错。M 系统是单机,单机宕机后所有后台操作就不能进行了。性能比较差,有的操作耗时好久。界面比较丑,操作不人性化。历史上经过几手转接,代码比较混乱。业务数据和游戏数据耦合,开发效率很低。以上这么多问题中识别出重构的目标,并不是一目了然的;而如果想一下全部解决所有这些问题,人力和时间又不够!
2025-07-30 22:48:31
572
原创 架构实战——互联网架构模板(“平台”技术)
本文介绍了运维平台、测试平台、数据平台和管理平台四大技术平台的核心职责与设计要素。运维平台聚焦配置、部署、监控、应急四大功能,强调标准化、平台化、自动化和可视化;测试平台通过用例管理、资源管理、任务管理和数据管理实现测试自动化;数据平台包含数据管理、分析和应用三个层次,构建完整的数据处理体系;管理平台则专注于权限管理,通过身份认证和权限控制保障系统安全。这些平台通过系统化设计,有效提升了技术运维效率、测试质量、数据价值挖掘和安全管理能力,为企业技术架构提供关键支撑。
2025-07-29 23:27:51
1129
原创 架构实战——互联网架构模板(“用户层”和“业务层”技术)
本文总结了互联网架构中的用户层和业务层关键技术。在用户层,主要涉及单点登录(SSO)、授权登录(OAuth 2.0)等用户管理技术,以及消息推送和存储云/图片云解决方案。业务层面临的主要挑战是复杂度管理,通过"拆"(微服务架构)和"合"(虚拟业务域)的方式应对系统膨胀问题。文章以电商系统为例,展示了从单体到微服务,再到业务域的演进过程,体现了分层架构和微服务模式在应对业务复杂度中的重要作用。
2025-07-29 22:41:21
1273
原创 架构实战——互联网架构模板(“网络层”技术)
本文介绍了分布式系统架构中的关键负载均衡技术及应用场景。首先分析了DNS、Nginx、LVS、F5等不同层级的负载均衡方案及其优缺点,指出DNS适合地理级别均衡,而Nginx等更适合机器级别均衡。其次阐述了CDN"以空间换时间"的加速策略,通过内容就近缓存提升访问速度。最后讨论了多机房和多中心架构,比较了同城、跨城、跨国机房的灾备方案,强调多中心在数据一致性和事务性处理上的挑战。文章指出负载均衡、CDN和多中心架构是构建高可用分布式系统的核心技术,需要根据业务特性选择合适方案。
2025-07-29 21:56:53
892
原创 架构实战——互联网架构模板(“开发层”和“服务层”技术)
本文总结了互联网开发中的关键分层技术。在开发层,强调统一开发框架的重要性,建议选择成熟稳定的技术栈;介绍Web服务器选型与容器技术的应用趋势。服务层重点分析配置中心、服务中心和消息队列三大核心组件:配置中心解决多系统配置管理难题;服务中心通过服务名字系统或总线系统实现高效服务调度;消息队列则有效解耦系统,实现异步通信。文章通过架构图展示各组件设计,并指出技术选型需要平衡成熟度与业务需求,合理运用开源方案可大幅提升开发效率。
2025-07-28 22:51:09
907
原创 架构实战——互联网架构模板(“存储层”技术)
本文分析了互联网行业数据存储技术的演进路径。SQL关系型数据库仍是核心,但面临性能瓶颈时需分库分表,大公司会构建统一存储平台;NoSQL作为补充,适合处理非结构化数据,规模化后也需要平台化管理;小文件存储(如图片)通常直接采用开源方案构建统一平台;大文件存储(如视频、日志)则主要依赖Hadoop等成熟生态。随着业务规模扩大,数据存储会经历从单机到集群再到平台化的演进过程,关键在于平衡性能、复杂度和运维成本。不同规模企业可根据需求选择合适的存储方案和演进节奏。
2025-07-28 22:11:15
782
原创 可扩展架构模式——微服务架构最佳实践应该如何去做(方法篇)
本文总结了微服务架构设计的关键要点。在服务粒度方面,建议根据团队规模动态调整,初期可粗放拆分,随团队扩张逐步细化。拆分方法包括:基于业务逻辑划分(需平衡职责范围)、基于可扩展性(区分稳定/变动服务)、基于可靠性(隔离核心/非核心服务)和基于性能(解耦高负载模块)等维度,可组合使用。作者特别强调微服务成功的关键在于自动化基础设施的完善,建议按优先级分阶段建设:先构建服务发现、路由、容错等核心组件,再逐步完善接口框架、API网关、自动化工具链和运维监控体系。对于中小团队,可借助Spring Cloud等开源方案
2025-07-28 21:20:11
786
原创 可扩展架构模式——深入理解微服务架构
微服务与SOA的关系及潜在陷阱分析 本文探讨了微服务与SOA架构的关系与区别,指出两者本质上是不同的架构理念:SOA适用于复杂异构的企业系统,强调ESB和服务兼容性;微服务则更适合轻量级互联网应用,强调细粒度服务和快速交付。文章通过对比表展示了二者在服务粒度、通信方式、交付模式和应用场景上的差异。 同时,文章揭示了微服务架构的潜在陷阱:服务划分过细导致系统复杂度指数级增长;团队效率因服务数量过多而下降;长调用链引发性能问题和故障定位困难;缺乏自动化支撑和服务治理系统会抵消微服务的优势。这些陷阱提醒架构师需谨
2025-07-25 22:52:04
936
原创 可扩展架构模式——传统的可扩展架构模式(分层架构和SOA)
本文介绍了两种常见的系统架构模式:分层架构和SOA架构。分层架构通过将系统划分为不同层级(如C/S、B/S、MVC等)来隔离关注点,核心在于保持各层边界清晰。SOA架构则面向企业级服务整合,通过服务、企业服务总线(ESB)和松耦合三大关键概念,解决企业内部IT系统重复建设和效率低下的问题。文章分析了两种架构的设计原理、典型应用场景以及优缺点,其中特别指出SOA架构中ESB虽然功能强大但也带来了实现复杂性。这些架构模式为不同规模的系统设计提供了重要参考。
2025-07-25 22:07:18
872
原创 可扩展架构模式——可扩展架构的基本思想和模式
本文探讨了可扩展性架构设计的基本思想和常见拆分方式。核心观点是“拆”这一关键思想,即通过将系统拆分为更小部分来降低修改范围和风险。文章介绍了三种主要拆分思路:面向流程拆分(按业务阶段划分)、面向服务拆分(按系统服务划分)和面向功能拆分(按具体功能划分),并通过TCP/IP协议栈和学生信息管理系统两个案例详细说明。每种拆分方式都有其对应的可扩展性优势:流程拆分只需修改特定层级,服务拆分只需变更相关服务,功能拆分只需调整特定功能模块。最后指出这些架构方式可以组合使用,如微服务架构中可同时采用分层和微内核设计。整
2025-07-24 23:08:08
880
原创 高可用架构模式——如何应对接口级的故障
本文摘要: 接口级故障表现为系统响应缓慢、超时或异常,主要由于系统压力过大或外部依赖问题。解决核心在于优先保障核心业务和大多数用户,常用方法包括:1)降级,通过系统后门或独立系统关闭非核心功能;2)熔断,停止故障外部接口调用以避免拖垮自身系统;3)限流,基于请求量(如总量/时间量)或资源使用(如CPU、队列)控制流量,采用时间窗(固定/滑动)或桶算法(漏桶/令牌桶)实现。漏桶算法适合突发流量场景,而令牌桶则允许一定流量波动。这些方法需结合业务特点动态调优阈值。(149字)
2025-07-24 22:21:14
1084
原创 高可用架构模式——异地多活设计步骤
本文介绍了异地多活架构设计的四个关键步骤:业务分级、数据分类、数据同步和异常处理。首先通过访问量、核心性和收入贡献等标准筛选核心业务;然后分析业务数据的数据量、唯一性、实时性、可丢失性和可恢复性等特征;接着根据不同数据特点设计存储系统同步、消息队列同步或重复生成等同步方案;最后采取多通道同步、同步与访问结合、日志记录和用户补偿等措施应对数据异常。文章以用户管理系统为例,详细说明了每个步骤的具体实施方法和设计要点,为构建高可用异地多活系统提供了系统性的解决方案。
2025-07-24 21:34:39
690
原创 高可用架构模式——异地多活设计的技巧
摘要:跨城异地多活架构设计的关键技巧 本文总结了异地多活架构设计的四个核心技巧:1)优先保证核心业务(如登录)的多活,而非所有业务;2)只保证核心数据的最终一致性,而非所有数据实时同步;3)采用消息队列、二次读取、回源获取等多种数据同步方式组合,而非单一依赖存储系统同步;4)接受无法100%可用的事实,保证绝大部分用户的体验即可。文章通过用户子系统案例,详细分析了注册、登录等业务实现多活的具体挑战和解决方案,强调架构设计要聚焦核心业务、容忍部分数据延迟,通过灵活的技术组合实现业务高可用。
2025-07-23 22:46:55
1042
原创 高可用架构模式——业务高可用的保障(异地多活架构)
文章摘要 异地多活架构通过在不同地理位置部署多个业务系统来提高系统可用性。主要分为三种模式:同城异区(同一城市不同区域机房,网络延迟低)、跨城异地(不同城市机房,应对极端灾难但复杂度高)和跨国异地(不同国家机房,适合特定场景)。应用场景取决于业务需求,金融类系统通常仅适用同城异区,而新闻网站等对数据一致性要求不高的业务可采用跨城异地。该架构虽能提升系统可靠性,但会显著增加复杂度和成本,需根据业务特点权衡实施。
2025-07-23 21:53:43
915
原创 高可用架构模式——如何设计计算高可用架构
计算高可用架构设计摘要 计算高可用架构通过服务器冗余实现故障容错,核心设计围绕任务管理展开。主要架构包括: 主备架构:主机执行任务,备机待命,故障时需人工切换至备机。分为冷备(备机未启动)和温备(备机已启动),适合低频后台系统。 主从架构:主机和从机分别执行不同任务,需任务分类器支持。相比主备架构能更好利用硬件资源,但设计复杂度更高。 集群架构: 对称集群(负载均衡):各节点平等,自动分配任务并检测故障 非对称集群(如Master-Slave):角色分工,需复杂选举机制(如ZAB/Raft) 设计关键点在于
2025-07-23 19:10:43
1240
原创 高可用架构模式——数据集群和数据分区
本文介绍了数据集群和数据分区的架构设计。数据集群分为数据集中集群和数据分散集群,前者采用主备/主从模式,后者通过分散数据提升处理能力。数据分区则通过地理分布规避大规模故障,分为集中式、互备式和独立式三种复制规则。两种架构各有复杂度:数据集群需解决复制、状态检测和故障切换问题;数据分区需考虑数据量、分区规则和复制策略。设计选择需权衡业务需求、扩展性和成本,如数据集中集群适合中小规模,数据分散集群适合海量数据场景。
2025-07-22 22:58:51
718
原创 高可用架构模式——高可用存储架构(双机架构)
本文探讨了高可用存储架构中的数据冗余机制,重点分析了三种主流双机高可用方案:主备复制、主从复制和双机切换。主备复制通过数据备份实现简单冗余但不承担业务负载;主从复制扩展了读能力但存在数据一致性问题;双机切换引入自动故障转移机制,细分为互连式、中介式和模拟式三种实现方式,在状态传递、切换决策和数据冲突处理等方面各有优劣。文章指出,实际架构选择需权衡业务特性(读写比例)、复杂度与成本等因素,中介式方案因ZooKeeper等成熟组件的支持而更具实践价值。
2025-07-22 21:56:26
847
原创 高可用架构模式——FMEA方法(排除架构可用性隐患的利器)
FMEA(故障模式与影响分析)是一种广泛应用于各行业的可用性分析方法,通过分析系统潜在故障及其影响程度来评估架构设计的可靠性。在软件架构领域,FMEA从用户功能点出发,分析故障模式、影响范围、严重程度、故障原因及其发生概率,综合评估风险等级。该方法通过量化描述故障现象(如"MySQL响应达3秒")和影响(如"20%用户无法登录"),结合已有措施(检测告警、容错等)和规划改进方案(技术或管理手段),帮助识别架构隐患并制定优化策略。FMEA的核心价值在于提供系统化的分析框
2025-07-22 19:09:45
661
原创 高可用架构模式——CAP 细节
摘要:本文深入解析了CAP理论的关键细节及其在分布式系统中的应用,并与ACID、BASE理论进行了对比分析。CAP理论强调数据粒度的选择(CP或AP),指出正常运行时可以同时满足CA,分区期间需根据场景取舍C或A。文章还探讨了ACID的事务特性与CAP的一致性差异,以及BASE理论如何通过基本可用、软状态和最终一致性来补充CAP的AP方案。通过具体案例(如用户管理系统)说明了不同数据类型应采用不同策略,并指出网络延迟对一致性的实际影响。这些理论为分布式系统设计提供了重要指导框架。
2025-07-21 22:11:05
961
原创 高可用架构模式——CAP 定理
摘要 CAP理论指出分布式系统在读写操作中无法同时满足一致性(C)、可用性(A)和分区容错性(P)。第二版定义更精确,强调互联共享数据的系统,并限定为读写场景。一致性要求客户端读取最新写入结果;可用性要求非故障节点在合理时间内返回合理响应;分区容错性要求网络分区时系统仍能运作。实践中必须选择P,因此系统仅能设计为CP(牺牲可用性,如禁止写入保证一致性)或AP(牺牲一致性,如返回旧数据保证可用性)。典型例子如ZooKeeper(CP)和Eureka(AP)。
2025-07-20 23:13:22
788
原创 高性能架构模式——高性能负载均衡(算法)
本文介绍了四种高性能负载均衡算法:轮询、加权轮询、负载最低优先和性能最优类。轮询算法简单高效但不考虑服务器状态;加权轮询通过权重分配解决服务器性能差异问题;负载最低优先根据服务器实时负载分配任务,复杂度较高;性能最优类以客户端响应时间为标准,同样面临实现复杂度高的问题。此外还介绍了Hash类算法,通过关键信息Hash实现特定业务需求。不同算法各有优缺点,需根据实际业务场景选择合适方案。
2025-07-20 22:07:10
468
原创 高性能架构模式——高性能负载均衡(分类及架构)
本文介绍了负载均衡系统的分类及其典型架构。主要包括DNS负载均衡、硬件负载均衡和软件负载均衡三种类型,各具优缺点:DNS实现简单成本低但扩展性差;硬件负载均衡性能强劲但价格昂贵;软件负载均衡灵活经济但性能有限。在实际应用中,通常组合使用这三种方式,形成地理级别、集群级别和机器级别的三层负载均衡架构,以达到最优的负载分配效果。这种分层架构特别适用于大型业务场景,能够有效提升系统性能和稳定性。
2025-07-20 19:46:35
872
原创 高性能架构模式——单服务器高性能模式(非阻塞同步网络模型Reactor与异步网络模型 Proactor)
本文介绍了两种高性能服务器架构模式:Reactor和Proactor。Reactor模式采用I/O多路复用技术结合线程池,解决了传统PPC/TPC模式无法支撑高并发的问题,主要包括单Reactor单线程、单Reactor多线程和多Reactor多线程三种实现方案,分析了各自的优缺点及应用场景(如Redis采用单Reactor单进程)。Proactor模式则通过异步I/O进一步提升性能,由操作系统内核主动处理I/O事件并回调通知应用程序。文章对比了两种模式的特点,Reactor是"事件通知处理&qu
2025-07-20 18:49:14
978
原创 高性能架构模式——单服务器高性能模式(PPC与TPC)
本文探讨了高性能服务器架构设计的核心要点。单服务器性能优化的关键在于并发模型设计,主要涉及连接管理和请求处理两个维度,与操作系统I/O模型和进程模型密切相关。文章详细分析了PPC(Process Per Connection)和TPC(Thread Per Connection)两种传统模式,分别采用进程和线程处理连接请求,并指出了它们在高并发场景下的局限性。为优化性能,提出了prefork和prethread两种预创建模式,通过预先创建进程/线程来降低连接建立开销。虽然这些模式在早期服务器设计中有效,但面
2025-07-20 18:19:04
752
docker+k8s.txt
2019-06-19
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人