- 博客(1517)
- 资源 (6)
- 收藏
- 关注
RSS订阅
原创 合格程序员每天每周每月每年应该做的事
程序员每天该做的事 1、总结自己一天任务的完成情况 最好的方式是写工作日志，把自己今天完成了什么事情，遇见了什么问题都记录下来，日后翻看好处多多 2、考虑自己明天应该做的主要工作 把明天要做的事情列出来，并按照优先级排列，第二天应该把自己效率最高的时间分配给最重要的工作 3、考虑自己一天工作中失误的地方，并想出避免下一次再犯的方法 出错不要紧，最重要的是不要重复犯相同的错误，那是愚蠢 4、考虑自
2009-11-18 12:45:00
2198
7
原创 科普文：软件架构网络系列之【如何选择BGP机房《BGP机房选择指南》】
《BGP机房选择指南》是一篇系统介绍BGP机房选型要点的技术文章。文章首先强调BGP机房作为互联网核心枢纽的重要性，其通过BGP协议实现跨运营商高效路由交换。在选型方法上，提出"业务需求→测试网络→验证运维→成本优化"的核心逻辑，并针对不同业务类型给出配置建议。详细阐述了网络质量、运营商覆盖、路由优化、基础设施等10大评估维度，包括多线接入、延迟测试、路由策略等具体指标。最后提供了主流服务商推荐、成本分析及避坑指南，为企业在BGP机房选型时提供全面的决策参考。
2025-08-17 01:04:41
133
原创 科普文：软件架构网络系列之【BGP（Border Gateway Protocol，边界网关协议）机房概叙】
本文系统介绍了BGP机房的核心价值与技术原理。BGP机房通过边界网关协议实现多运营商智能互联，具备自动选路、IP广播、高可用等核心功能，相比传统单/双线机房在访问速度、稳定性和跨网互通方面具有显著优势。文章详细解析了BGP协议特性、机房工作流程、典型应用场景（如云计算、游戏服务器等），以及与普通机房的对比差异，并指出其高成本主要源于多线带宽和专用设备。随着SDN和边缘计算发展，BGP技术将持续演进，为互联网基础设施提供更高效的骨干网络支持。
2025-08-17 00:34:47
1326
原创 科普文：软件架构网络系列之【为什么需要BGP机房】
BGP机房是一种专门用于托管Internet边界路由器的高性能数据中心，通过高速互联网络连接不同运营商、地区和国家的网络，提供高质量、高可靠、低延迟的互联网接入服务。BGP是边界网关协议（Border Gateway Protocol）的简称，它是一种用于在自治系统（Autonomous System，AS）之间交换路由信息的协议。BGP机房托管了大量的边界路由器，这些路由器通过BGP协议与其他AS的路由器交换路由信息，帮助互联网信息从源站点到目标站点进行传输。BGP机房还提供路由优化、防御DD
2025-08-17 00:21:20
348
原创 科普文：软件架构网络系列之【NAT网络地址转换协议】
简单来说：NAT的核心是网络层协议，但实际应用中离不开传输层的端口支持。NAT（网络地址转换）工作在 网络层（OSI模型第三层）与传输层（第四层）之间，但更准确地说，它主要基于 网络层（IP层） 实现，同时涉及 传输层（端口信息）。NAT（网络地址转换）NAT（网络地址转换，Network Address Translation）是一种用于 解决IP地址短缺问题并增强内网安全 的关键技术，其核心功能是在 网络层（IP层） 对IP地址（及传输层的端口号）进行转换，使多个局域网（LAN）内的私有IP设
2025-08-16 19:05:08
768
原创 科普文：软件架构网络系列之【传输层协议：TCP、UDP概叙】
本文系统介绍了TCP和UDP两种核心传输层协议的对比。TCP是面向连接的可靠协议，通过三次握手建立连接、四次挥手终止连接，提供序列号、确认应答、重传、流量控制和拥塞控制等机制确保可靠传输，适用于Web、邮件等场景。UDP是无连接的高效协议，仅8字节头部，无连接管理、确认重传等机制，适合音视频、游戏等实时应用。文章详细解析了TCP报文格式、状态转换、连接管理流程，以及UDP的数据报结构，为理解网络传输层提供了全面参考。
2025-08-16 17:55:41
741
原创 科普文：软件架构网络系列之【网络层协议：IP、ICMP（错误控制）、IGMP（组播）、ARP（地址解析）概叙】
本文介绍了TCP/IP协议族中的关键网络层协议：IP、ICMP、IGMP和ARP。IP协议是网络层的核心，负责数据包格式定义和跨网络寻址；ICMP用于网络诊断和错误报告；IGMP管理组播通信；ARP则在局域网内实现IP到MAC地址的转换。这些协议协同工作，构成了互联网通信的基础架构，分别承担着数据寻址、网络诊断、组播管理和地址解析等重要功能。文章详细解析了各协议的工作原理、数据包格式及典型应用场景，帮助读者深入理解网络层协议的核心作用。
2025-08-16 16:53:05
755
原创 科普文：软件架构网络系列之【网络传输协议：TCP/IP协议族概叙】
本文系统介绍了计算机网络中的TCP/IP四层模型及其与OSI七层模型的对应关系。TCP/IP协议簇包含应用层、传输层、网络层和网络接口层，每层通过特定协议（如HTTP、TCP/IP、UDP等）实现数据封装与传输。相比OSI理论模型，TCP/IP更精简高效，将OSI的高层功能合并到应用层，底层合并为网络接口层，广泛应用于互联网通信。文章详细阐述了各层的核心功能、关键协议及数据封装流程，通过HTTP请求示例展示了数据从应用层到物理层的完整传输过程，体现了分层架构在实现可靠、高效网络通信中的重要性。
2025-08-16 16:22:38
384
原创 科普文：软件架构网络系列之【网络传输设备：路由器（Router）】
关键特性多端口类型：常见WAN口（连接外网，如光纤/宽带猫）、LAN口（连接内网设备，如电脑/交换机）。无线功能（Wi-Fi路由器）：集成无线接入点（AP），提供2.4GHz/5GHz频段Wi-Fi信号。QoS（服务质量）：优先处理视频、游戏等关键流量，保障网络体验。总结：路由器是互联网的“交通枢纽”，通过IP地址智能选路，连接不同网络并保障全球通信，是家庭、企业及运营商网络的核心设备。
2025-08-16 12:40:38
244
原创 科普文：软件架构网络系列之【网络传输设备：交换机（Switch）】
本文介绍了计算机网络中交换机的核心功能、工作原理及关键技术。交换机作为数据链路层（L2）或网络层（L3）设备，通过MAC地址学习和转发机制实现高效数据传输，相比集线器具有冲突域隔离、全双工通信等优势。文章详细解析了交换机的三种工作模式（存储转发、直通交换、无碎片）、MAC地址表维护机制，以及VLAN、STP等关键技术。同时对比了交换机与集线器、路由器的区别，并提供了交换机组网示例和基本配置指南。最后探讨了交换机的常见问题及解决方案，为理解网络架构提供了实用参考。
2025-08-15 20:54:47
428
原创 科普文：软件架构网络系列之【网络传输：传输介质和字节码】
本文系统介绍了计算机网络传输中的关键概念，包括传输介质和字节码两大核心要素。传输介质作为物理层载体，涵盖双绞线、光纤等有线介质和无线电波等无线介质；字节码则涉及数据表示层的字符编码、序列化和字节序等问题。文章详细解析了OSI七层模型中各层功能，对比了TCP/IP四层模型协议，并通过数据传输示例说明数据从应用层到物理层的封装过程。同时，针对网络编程中的常见问题如乱码、字节序不一致等提供了解决方案，为理解网络通信原理和Java网络编程实践奠定了基础。
2025-08-15 19:36:40
347
原创 科普文：软件架构网络系列之【OSI七层计算机网络参考模型预览】
本文系统介绍了计算机网络体系结构，重点解析了OSI七层模型和TCP/IP协议栈的对应关系。OSI模型由国际标准化组织提出，包含物理层、数据链路层、网络层、传输层、会话层、表示层和应用层，每层具有特定功能协议。TCP/IP协议栈则包含应用层、传输层、网络层和网络接口层，其协议如HTTP、FTP、TCP/UDP等在实际网络通信中广泛应用。文章详细阐述了各层功能、协议特点及数据传输时的封装/解封装过程，同时对比了OSI模型的理论价值与TCP/IP协议栈的实用优势，为理解现代网络通信架构提供了系统性的知识框架。
2025-08-15 18:43:44
594
原创 科普文：软件架构数据库系列之【undo日志、版本链、Read View之间的关联：MySQL MVCC实现原理】
undo日志和版本链并不直接构成Read View，但它们共同在InnoDB的MVCC机制中实现了数据的版本管理和可见性判断。undo日志和版本链共同记录了数据的历史版本，并通过roll_pointer指针将这些版本连接起来。而Read View则用于在执行查询操作时判断数据版本的可见性。这三者协同工作，实现了InnoDB的MVCC机制，从而提高了数据库的并发性能和一致性。
2025-08-15 14:42:01
1002
原创 科普文：软件架构数据库系列之【MVCC：MySQL数据库，单独一个session中的select语句是否会开启事务？】
MySQL中单独SELECT语句的事务行为与MVCC机制解析 在MySQL中，SELECT语句的事务行为取决于是否开启显式事务和隔离级别设置。默认自动提交模式下，单独SELECT不会开启显式事务，也不分配事务ID，通常直接读取最新数据；而在显式事务中，SELECT会共享当前事务ID，MVCC通过事务ID、undo日志链和ReadView机制实现数据隔离。不同版本MySQL的事务ID分配规则存在差异：5.1-5.5版本仅写操作分配事务ID，5.7+版本所有显式事务（包括SELECT）都会分配ID。MVCC通过
2025-08-15 00:03:17
500
原创 科普文：软件架构数据库系列之【可见性判断函数 changes_visible：源码解读MySQL MVCC实现原理】
本文分析了MySQL InnoDB引擎中MVCC机制的核心函数changes_visible的实现原理，涵盖5.7、8.0和8.4三个版本。该函数通过比较数据行的事务ID与当前事务的ReadView（包含活跃事务ID集合、上下限事务ID）来判断数据可见性。关键判断逻辑包括：当事务ID小于ReadView上限或为创建者ID时可见；大于等于下限时不可见；处于中间范围时需检查活跃事务列表。各版本实现位置不同但逻辑一致，8.4版本通过布隆过滤器等优化提升了高并发下的性能。该函数是MVCC实现读写并发的核心技术，直接
2025-08-14 22:11:53
507
原创 科普文：软件架构数据库系列之【五大 MVCC 核心组件总览：MySQL MVCC实现原理】
MySQL的MVCC机制通过隐藏字段(DB_TRX_ID、DB_ROLL_PTR)、Undo日志、ReadView、事务系统和Purge线程五大核心组件协同工作，实现高效的多版本并发控制。其中隐藏字段记录事务信息和版本链指针，Undo日志存储历史版本，ReadView定义事务可见范围，事务系统管理事务生命周期，Purge线程负责垃圾回收。这种机制使MySQL能够支持高并发事务，实现不同隔离级别下的一致性读，同时避免数据冲突和存储膨胀问题，是数据库事务处理的核心基础。
2025-08-14 21:40:18
1000
原创 科普文：软件架构数据库系列之【MySQL MVCC实现原理】作者|得物 Eric
MVCC（多版本并发控制）是InnoDB实现高并发的核心技术，通过维护数据行的多个版本来实现读-写操作的非阻塞执行。其核心机制包括： 版本链：通过隐藏字段trx_id和roll_pointer构建数据修改历史链 ReadView：事务快照，包含creator_trx_id、活跃事务列表等，用于判断版本可见性 两种读操作：快照读（不加锁，读取历史版本）和当前读（加锁，读取最新版本） 在不同隔离级别下： READ COMMITTED：每次查询生成新ReadView，可能读到其他事务已提交的修改 REPEATAB
2025-08-11 22:25:07
1073
原创 科普文：软件架构方法论【第一性原理（First Principles）在软件开发团队管理中的应用】
本文探讨了第一性原理在软件开发团队管理中的应用，主张通过追问底层需求重构管理策略。文章从五个维度提出创新方案：1）按业务需求域重组跨职能团队，取代传统职能分工；2）基于能力-需求匹配动态分配任务，打破均摊工作量的惯例；3）以可衡量的用户价值替代KPI指标；4）建立信息透明的共识决策机制；5）设计基于成就感、技术成长等内在动机的激励机制。这些方法通过消除经验惯性，有效提升了团队协作效率和交付质量，如某案例显示需求周期从2周缩短至5天。实施时需注意平衡专业深度与协作灵活性，建立清晰的能力评估体系，并针对个体差异
2025-08-04 20:30:56
1083
原创 科普文：软件架构方法论【第一性原理（First Principles）在软件行业的解析】
本文系统梳理了软件架构中的第一性原理思维方法，指出其通过原子性分解、跨学科溯源和重构创新三个核心特征推动根本性创新。文章详细阐述了该原理在分布式系统、React框架等领域的应用案例，并提出了五层追问法、验证矩阵等实践工具。同时强调需防范过度理论化风险，建议设定3-5层合理分解层级，并建立ROI评估机制。最后给出开发者思维训练方法，包括每日一题练习和架构审查四问，帮助工程师突破行业惯例束缚，从基础原理层面重构系统设计。研究表明，掌握该方法可使系统设计效率提升40%以上。
2025-08-04 20:26:17
884
原创 科普文：软件架构方法论【软件行业的定理/定律梳理：第一性原理（First Principles）】
摘要：第一性原理是一种从基本公理出发推导复杂问题的思维方法，强调剥离经验假设、回归底层逻辑。其核心步骤包括质疑传统假设、拆解本质要素和逻辑重构方案，在科技（如SpaceX火箭设计）、商业（特斯拉电池优化）和密码学等领域具有广泛应用。实施时需平衡原理推导与工程落地，要求深厚的领域知识，并警惕过度解构风险。该方法能突破思维定式，但需注意在常规决策中合理使用，避免认知过载。第一性原理作为对抗思维熵增的工具，帮助从业者在复杂系统中重建创新秩序。
2025-08-04 20:18:52
1149
原创 科普文：软件架构方法论【软件行业的定理/定律梳理】补充
本文梳理了软件行业25个重要定理、定律和原则，涵盖开发效率、系统设计、软件质量等六大领域。包括利特尔定律（系统吞吐量优化）、布鲁克斯法则（项目延期风险）、CAP定理（分布式系统设计）等经典理论，以及尼尔森可用性原则（用户体验）、MVP原则（产品验证）等实践指导。这些规律揭示了软件开发的本质特征：任务预估偏差、技术债务累积、系统复杂度增长等固有现象，为架构设计、团队协作和项目管理提供了科学依据，帮助开发者规避常见陷阱，优化技术决策。
2025-08-04 11:36:29
961
原创 科普文：软件架构方法论【软件行业的定理/定律梳理】
开发效率 KISS + YAGNI 代码复杂度分析工具（SonarQube）架构演进 康威定律 + 冰山谬论 架构决策记录（ADR）模板团队协作 彼得原则 + DRY 跨职能评审会（RFC机制）风险控制 墨菲定律 + 侯世达定律 故障演练平台（Chaos Mesh）
2025-08-04 11:29:28
1225
原创 科普文：【支持信创、宣传国产】国密SM之2024-12-27国家密码管理局公告（第50号）
截至2025年7月，我国现行主要密码国家标准和行业标准如下：密码国家标准 GB/T 33133.1—2016 ： 祖冲之序列密码算法 第1部分：算法描述。 GB/T 32907—2016 ： SM4分组密码算法。 GB/T 32918.1—2016 ： SM2椭圆曲线公钥密码算法 第1部分：总则。密码行业标准（截至2025年7月） GM/T 0001.4—2024 ：祖冲之序列密码算法第4部分：鉴别式加密机制。 GM/T 0133—2024 ：关键信息基础设施密码应用要求
2025-08-02 07:30:57
1402
原创 科普文：【支持信创、宣传国产】国密SM之国家标准、行业标准一览表
我国密码国家标准、行业标准一览表。如：SM系列 密码，SM 代表 商密，即商业密码，是指用于商业的、不涉及国家秘密的密码技术。SM1、SM4、SM7、祖冲之密码（ZUC）属于对称算法；备注：SM1、SM7算法不公开，调用该算法时，需要通过加密芯片的接口进行调用。SM2、SM9属于非对称算法；SM3属于哈希算法。
2025-08-02 07:25:51
427
原创 科普文：软件架构方法论【实战“首页≤10屏、门户≤10屏、官网≤3屏、电商≤6屏”】
【摘要】本文系统阐述了前端设计中"屏"的概念及谷歌建议的屏数规范。不同类型网站有不同屏数限制：门户网站≤10屏、企业官网≤3屏、电商网站≤6屏。文章详细解析了各类型网站的典型屏数结构，并提供了技术实现方法（如动态检测、CSS视口单位控制）。研究数据表明，屏数与页面性能指标（加载时间、留存率等）密切相关。最后针对特殊场景（如长表单、无限滚动）提出优化建议，强调通过量化控制实现用户体验与技术性能的最佳平衡。（148字）
2025-08-01 13:48:05
935
2
原创 科普文：软件架构方法论【前端设计：为何谷歌说“首页≤10屏、门户≤10屏、官网≤3屏、电商≤6屏”？】
本文探讨了网页设计中"屏数"规范的科学依据，指出谷歌建议的屏数限制（首页≤10屏、门户≤10屏、官网≤3屏、电商≤6屏）是基于用户行为、认知规律和商业目标的综合考量。核心发现包括：1）用户注意力集中在首3屏，认知负荷遵循"3-5-7"原则；2）不同类型网站需差异化设计，如官网需3屏内完成品牌传达，电商需6屏内平衡商品展示与转化效率；3）移动端主导环境下，超长页面会加剧加载延迟和操作疲劳；4）每增加1屏可能导致转化率下降5-10%。研究强调屏数规范本质是优化用户体验与商
2025-08-01 10:41:42
1261
原创 科普文：软件架构方法论【前端设计：什么是屏/屏数？】
本文围绕"屏数"概念展开技术解析，首先阐明其作为衡量网页内容纵向长度的核心定义，指出1屏代表用户不滚动时的完整可视区域。通过官网（≤3屏）、电商（≤6屏）、门户（≤10屏）三类典型场景示例，说明如何根据业务目标规划屏数布局。文章详细介绍了屏数的测量方法、响应式适配原理及商业价值，强调关键信息需集中在前3屏以优化转化率。最后提出技术实现要点，包括懒加载优化和内容密度控制，为前端工程提供实用指导规范。
2025-08-01 09:39:10
945
原创 科普文：软件架构方法论【K8s 网关选型初判：Nginx 还是 Envoy？】作者|张添翼(澄潭)
K8s网关选型分析：Nginx Ingress与MSE云原生网关对比 本文从性能、可靠性和安全性三方面对比了K8s网关的两大实现方案：基于Nginx的Ingress Controller和基于Envoy的MSE云原生网关。性能测试显示，MS云原生网关吞吐量达Nginx的2倍，且TLS硬件加速使HTTPS性能提升80%。可靠性方面，MSE采用控制面/数据面分离架构，避免了Nginx高负载时的pod重启问题。安全性上，MSE一次性修复所有CVE漏洞并内置WAF防护。结论表明，MSE云原生网关在保持50%成本优势
2025-08-01 00:00:00
1683
原创 科普文：软件架构方法论【又拍云叶靖：基于 ngx_lua 的动态服务路由方案】PPT版
基于 ngx_lua 的动态服务路由，是整个容器化过程中的一个组件。容器化在服务路由这一块有很大的挑战，又拍云通过自己的一些方案去解决它，而且这个方案也会开源出来，如果大家以后也碰到这样的问题，可以直接用这个方案。
2025-08-01 00:00:00
26
原创 科普文：软件架构方法论【基于 ngx_lua 的动态服务路由方案】作者|又拍云叶靖
摘要：本文介绍了实现服务零宕机更新的关键技术方案。重点阐述了基于Consul的服务注册发现机制与Nginx负载均衡的整合方法，分析了传统reload和DNS方案的局限性，并提出了自主开发的动态upstream管理方案lua_resty_checkups。该方案通过Lua实现动态服务路由、主动健康检查等核心功能，相比C模块具有更高开发效率和灵活性。最后探讨了该方案在微服务架构中的应用场景，展示了如何通过服务拆分实现按需扩容。方案采用纯Lua实现，兼容现有Nginx生态，解决了服务动态更新过程中的关键痛点。
2025-08-01 00:00:00
168
原创 科普文：软件架构方法论【Dubbo 路由及负载均衡性能优化】作者：vivo 互联网中间件团队- Wang Xiaochuang
vivo针对Dubbo框架在大型微服务集群中的性能瓶颈进行了优化，重点关注路由模块和负载均衡机制。通过火焰图分析发现当服务提供方数量超过100时，这两个模块的CPU消耗高达30%。优化方案包括：1）关闭无效路由逻辑；2）引入路由结果缓存机制和BitMap加速计算；3）优化权重计算逻辑；4）新增分组路由策略减少负载均衡计算量。测试表明，在2000个以上服务节点场景下，优化后TPS提升超100%，CPU使用率下降约27%。未来计划引入自适应负载均衡算法，进一步提升不同性能机器间的资源利用率。
2025-08-01 00:00:00
33
原创 科普文：软件架构方法论【不同规格的云主机性能梳理】
本文分析了不同配置云服务器的性能与成本对比，从2核4G到8核64G共9种规格。关键发现：1. 性能方面，4核16G配置性价比最优，QPS可达15k-40k，支持10k-20k并发；2. 成本方面，3年合约平均节省40%，5年节省55%以上；3. 2核4G服务器适合轻量应用（50-200人并发），4核16G性能约为其2.5-3倍而非4倍。文章提供了详细的性能参数表、成本分析和场景化推荐，并强调实际性能受应用架构、缓存使用等因素影响，建议通过压测工具验证真实性能。
2025-07-31 10:46:22
1343
原创 科普文：软件架构方法论【4 vCPU 实例达成 100 万 JSON API 请求/秒的优化实践】作者|费良宏
【性能工程探索：从Linux优化到百万级QPS突破】 本文通过12个Web框架在AWS EC2上的性能测试实践，系统性地探讨了服务器性能优化的方法论。实验环境采用c6in.xlarge和c6gn.xlarge两种实例，涵盖C、Rust、Go等6种语言的框架，通过9轮优化实现从76万到120万QPS的突破。关键发现包括：禁用CPU安全缓解措施可提升6-10%性能；SCHED_FIFO调度策略使Node.js性能提升16%；网络驱动优化带来最高59.99%的性能飞跃；定制Linux内核配合系统调优最终使libr
2025-07-29 15:18:32
979
原创 科普文：软件架构方法论【2核4g服务器能支持多少人访问？4核16g服务器是否是2核4g服务器性能的4倍？】
摘要：本文介绍了2核4G和4核16G服务器的性能评估方法，基于Little定律（L=λ×W）进行并发数、响应时间和QPS的估算。2核4G服务器适合日均UV1-5万的轻量应用，支持20-150人并发，具体取决于应用类型（静态网页可达150人，动态电商约50人）。4核16G服务器性能提升2-3倍而非4倍，支持500-2500 QPS。性能评估需考虑CPU、内存、带宽等核心指标，以及应用架构优化（如缓存、CDN）。实际QPS可通过Little定律估算或压测工具实测，不同业务场景（静态网站、API服务等）的承载能力
2025-07-29 09:52:39
1453
原创 科普文：软件架构方法论【Little定律（Little‘s Law）：L = λ × W 估算服务器性能和硬件资源】
摘要：Little定律（L=λ×W）是排队论中的核心公式，揭示了系统并发数（L）、请求到达率（QPS/λ）与响应时间（W/RT）的定量关系，为服务器性能分析提供理论基础。通过该定律可计算线程池规模、数据库连接数等关键参数，指导CPU核数、内存等硬件资源配置。实际应用中需注意单位统一（毫秒转秒）、稳态系统假设及突发流量缓冲（建议20%-50%冗余）。结合QPS与RT的相互制约关系，可优化系统吞吐与延迟，实现资源成本与性能的平衡。该定律适用于Web性能分析、容量规划、队列优化等场景，需配合监控工具动态调整，是高
2025-07-29 00:56:25
1122
原创 科普文：软件架构Nginx系列之【Nginx生产环境https/tls 的详细配置】
本文提供了Nginx HTTPS/TLS生产环境优化配置指南，包含安全加固与性能调优方案。核心内容包括：1）仅启用TLS 1.2/1.3协议，配置高强度加密套件；2）通过会话缓存和OCSP Stapling提升性能；3）添加HSTS等安全头部防护攻击；4）详细参数说明及最佳实践建议。配置模板支持HTTP/2，兼顾安全性与兼容性，适用于现代Web应用部署。
2025-07-28 10:30:21
641
原创 科普文：软件架构数据库系列之【为什么 Uber 从 Postgres 迁移到 MySQL：Why Uber Engineering Switched from Postgres to MySQL】
Uber工程团队2016年从PostgreSQL迁移到MySQL的核心原因包括：PostgreSQL在写入操作、数据复制和版本升级方面存在显著瓶颈。其基于CTID指针的存储架构导致写入放大效应，次要索引更新产生冗余磁盘操作；物理复制机制造成跨数据中心带宽压力；MVCC实现限制副本读取性能；版本升级需停机数小时。相比之下，MySQL的InnoDB引擎通过主键引用次要索引，显著减少写入放大；逻辑复制更节省带宽；连接线程模型优于PostgreSQL的进程模型；支持在线版本升级。这些特性使MySQL更适合Uber快
2025-07-28 00:15:00
790
原创 科普文：软件架构数据库系列之【我们最讨厌的 PostgreSQL 部分：The Part of PostgreSQL We Hate the Most】
摘要： 卡耐基梅隆大学的研究团队在OtterTune博客中指出，PostgreSQL的多版本并发控制(MVCC)实现存在严重缺陷，是其最糟糕的设计部分。PostgreSQL采用追加式存储方式，每次更新都复制整行数据而非仅存储变更部分，导致存储膨胀和性能下降。此外，其版本链采用旧到新(O2N)顺序，需要遍历长链或维护冗余索引条目，而自动清理机制(autovacuum)难以有效回收空间，常因长事务阻塞形成恶性循环。相比Oracle、MySQL等使用增量存储的数据库，PostgreSQL的MVCC设计增加了I/O
2025-07-28 00:15:00
1747
原创 科普文：软件架构数据库系列之【解读：The Part of PostgreSQL We Hate the Most】
PostgreSQL的MVCC实现存在严重设计缺陷：采用追加式存储导致存储膨胀，每次更新都复制整行数据而非增量变更；版本链采用旧到新顺序需要遍历长链；自动清理机制效率低下，常因长事务阻塞形成恶性循环。这些问题导致I/O开销增加、性能下降和云成本上升，尤其在高写入负载下表现更差。相比Oracle、MySQL等使用增量存储的数据库，PostgreSQL的MVCC设计在二级索引维护和存储空间回收方面存在明显劣势。尽管存在这些缺陷，PostgreSQL仍是功能丰富的可靠数据库，但需精细调优来缓解问题。
2025-07-28 00:15:00
649
原创 科普文：软件架构数据库系列之【解读：Why Uber Engineering Switched from Postgres to MySQL】
Uber技术团队从PostgreSQL迁移到MySQL的技术分析显示：PostgreSQL在写入效率（不可变行设计导致写入放大）、复制带宽需求（WAL日志冗长）和版本升级（需长时间停机）方面存在明显不足。相比之下，MySQL的二级索引指向主键设计、逻辑复制机制和线程每连接模型在写入性能、复制效率和并发处理上更具优势。最终Uber将大部分数据库迁移至基于MySQL的Schemaless层，仅保留少量PostgreSQL实例。这一决策显著提升了系统的写入效率、复制可靠性和运维便利性。
2025-07-28 00:15:00
768
El caso de las hojas de ruta seguras para la memoria
2024-11-03
jsp+servlet+javabean.ppt
2010-04-02
Devexpress学习篇（请大家多多指教）
2009-07-28
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人