- 博客(8066)
- 资源 (9)
- 收藏
- 关注
RSS订阅原创 ES 核心原理与架构
在一次大促活动中，运营人员进行了一个非常复杂的聚合查询（统计所有订单的销售额并按地区分组），导致 ES 集群 CPU 飙升，甚至影响了正常的搜索服务。简单来说，传统数据库（如 MySQL）是‘文档 -> 关键词’的映射，查找时需要全表扫描或模糊匹配（like ‘%abc%’），效率极低。在商旅系统中，用户搜索‘北京 机票’，ES 会分别找到包含‘北京’和‘机票’的文档 ID 集合，取交集后瞬间返回结果。：用户需要根据“价格区间”、“起飞时间”、“航司”、“经停次数”进行多维度筛选和排序。
2026-03-31 16:10:52
364
原创 MQ 核心难题与解决方案
面试官：你刚才提到了用 MQ 解耦，那如果 MQ 挂了或者消息丢了怎么办？你的回答“这是一个非常好的问题。针对商旅业务防止消息丢失发送端：开启 Confirm 机制或事务消息，确保消息真正到达 Broker。存储端：RocketMQ 配置同步刷盘（Sync Flush）和同步复制（Sync Replication），虽然牺牲一点性能，但保证数据不丢。消费端：手动 ACK。只有业务逻辑完全执行成功后，才返回，否则返回让 MQ 稍后重试。应对消息堆积。
2026-03-31 09:25:51
325
原创 Redis 的核心机制
核心机制关键原理业务决策点避坑指南缓存问题穿透(布隆)、击穿(锁)、雪崩(随机TTL)热点数据：必须加互斥锁。恶意攻击：必须加布隆过滤器。避免所有缓存同一时间过期。布隆过滤器有误判率，不能用于精确判断。持久化RDB(快照) + AOF(日志)数据安全：开启 AOF，。备份：定时 RDB。不要只依赖 RDB，否则可能丢失大量数据。分布式锁Redisson (看门狗)业务时长不确定：必须用 Redisson。强一致性：考虑 ZooKeeper。不要自己实现复杂的锁逻辑，直接用 Redisson。
2026-03-27 15:56:31
347
原创 mysql 架构与存储结构：B+ 树的智慧
Redo Log：物理日志，记录“在某个数据页上做了什么修改”。采用循环写入（WAL 技术），保证事务持久性。Checkpoint (检查点)问题：内存中的脏页（修改过的数据页）不能无限期存在，Redo Log 写满后也不能直接覆盖（否则崩溃无法恢复）。机制：Checkpoint 机制会将内存中的脏页异步刷新到磁盘，并记录当前的 LSN（日志序列号）。恢复：数据库崩溃重启时，只需重放 Checkpoint 之后的 Redo Log，无需全量重放。核心机制关键原理业务决策点避坑指南存储结构。
2026-03-27 13:46:36
369
原创 在构建高并发、海量数据的分布式系统时，数据存储与治理是核心挑战。单机数据库的性能瓶颈、ID 冲突、历史数据膨胀等问题，都需要通过架构层面的设计来解决
领域核心问题解决方案避坑指南分布式 ID唯一性、递增性、高可用雪花算法(高性能)号段模式(严格递增)雪花算法必须处理时钟回拨；号段模式需设置双 Buffer防阻塞。分库分表单机性能瓶颈、存储上限ShardingSphere****垂直拆分(业务解耦)水平拆分(数据分散)避免笛卡尔积（使用绑定表）；分片键选择要慎重（避免数据倾斜）；非分片键查询是噩梦（需异构索引）。数据迁移业务不停机、数据一致性双写 + 增量同步****灰度切流必须进行数据校验；双写期间要保证旧库为主，防止数据覆盖；切流要循序渐进。
2026-03-27 10:38:40
259
原创 解析 Spring Framework、Spring Boot 和 MyBatis 的核心机制
Spring 生态是 Java 后端开发的“基础设施”，从底层的 Bean 管理到上层的微服务架构，形成了一套完整的技术栈。理解其核心原理，不仅能让你在面试中对答如流，更能帮助你在实际开发中解决复杂的架构问题。以下结合，深度解析 Spring Framework、Spring Boot 和 MyBatis 的核心机制。
2026-03-26 17:47:56
174
原创 SOLID 原则与核心设计模式的内部机制及设计哲学
维度初级开发高级开发/架构师关注点功能实现，代码能跑就行。可维护性、扩展性、复用性。代码风格大量if-else，大类大方法，逻辑耦合。大量使用多态、接口、抽象类，职责单一。应对变化修改现有代码，容易引入 Bug。新增代码扩展功能（开闭原则）。设计模式死记硬背，生搬硬套。心中有模式，手中无模式。根据业务痛点自然演化出结构。核心心法设计模式不是银弹，不要为了用模式而用模式（过度设计）。最好的设计，往往是符合直觉的简单设计（KISS 原则），但在简单中蕴含着对 SOLID 原则的深刻理解和灵活运用。
2026-03-26 17:23:17
180
原创 在构建高可用、低延迟的 Java 应用（尤其是微服务、大数据处理、高频交易系统）时，JVM 内部机制是决定系统稳定性的“黑盒”。理解类加载、内存模型和垃圾回收（GC），不仅能帮助我们避免 OutOfM
关注点核心机制业务决策关键点避坑指南类加载双亲委派 / 自定义 Loader是否需要隔离(多租户/Tomcat)？是否需要SPI(插件化)？不要随意打破双亲委派，除非清楚后果；注意 Metaspace 泄漏。内存模型堆 (对象) / 栈 (帧) / 元空间 (类)大对象放哪？递归深度多少？动态类有多少？避免深递归 (StackOverflow)；静态集合防泄漏；容器环境需感知内存限制。GC 算法复制 (新生代) / 整理 (老年代)对象存活率高还是低？新生代过小会导致频繁晋升；
2026-03-26 15:23:41
338
原创 在构建高并发、低延迟的分布式系统时，Java 并发编程是核心中的核心。从线程的生命周期管理到锁的底层优化，再到线程池的精细调优，每一个环节都直接关系到系统的吞吐量（TPS）和稳定性。
双组件state: 同步状态。例如：锁的重入次数、信号量的剩余 permits、倒计时器的剩余 count。FIFO 等待队列 (CLH 变体): 存储因获取资源失败而阻塞的线程。工作流程线程尝试 CAS 修改state。成功 -> 获取资源，执行逻辑。失败 -> 封装成 Node 加入队列尾部，调用挂起。前驱节点释放资源 -> 唤醒后继节点 (unpark组件核心机制适用场景避坑指南锁(JVM 升级)(AQS)一般同步用syn；需超时/公平/条件变量用Lock。
2026-03-26 14:23:49
503
原创 在构建高性能、高可用的软件系统时，数据结构与算法是代码的“骨架”，而操作系统原理则是运行环境的“地基”。只有深刻理解这两者，才能在面对海量数据、高并发请求和复杂资源调度时，做出最优的技术选型和架构设计
领域核心概念业务决策关键点避坑指南数据结构B+ 树(DB 索引)堆(Top K)哈希表(缓存)数据在哪里？(内存 vs 磁盘)怎么查？(精确 vs 范围 vs 排序)别在需要范围查询时用 HashMap；别在大数据量排序时用冒泡；注意哈希冲突导致的性能退化。算法DP(最优解)贪心(近似解)二分(快速查找)数据规模 N 是多少？N105→ONlogNN105→ONlogN可行N109→需O1N=10^9 \rightarrow 需 O(1)N。
2026-03-26 13:45:58
318
原创 高可用、高性能的分布式系统时，网络协议是底层的“血管”。理解 TCP/IP 模型、TCP 的状态机机制以及 UDP 的适用场景
特性TCPUDP (及基于 UDP 的 QUIC)连接性面向连接 (三次握手)无连接可靠性高 (确认、重传、排序)低 (尽最大努力交付)速度/延迟较慢 (拥塞控制、队头阻塞)极快(无重传、无拥塞控制)头部开销大 (20 字节+)小 (8 字节)数据边界流式 (需应用层解决粘包)数据报 (保留消息边界)典型场景文件传输、网页浏览 (HTTP)、数据库连接、邮件、支付交易*(要求数据绝对准确，不能丢)*直播、视频会议、实时游戏、语音通话、DNS 查询、物联网遥测*(要求低延迟，可容忍少量丢包)*
2026-03-26 10:57:33
786
原创 序列化、反射/动态代理、以及IO模型
维度推荐方案核心理由避坑指南序列化RPC 内部对外 API/缓存: JSON二进制协议体积小、速度快；JSON 通用性好。严禁在生产环境核心链路使用 JDK 原生序列化（慢、大、不安全）。反射/代理框架底层: 字节码生成 (CGLIB/ASM)业务代码: 避免运行时反射启动时生成代码，运行时零反射开销。避免在高频循环中使用或。必须用时，缓存Method对象或使用。IO 模型高并发网络简单文件/低并发: BIOReactor 模式 + 多路复用，单线程处理万连接。
2026-03-26 10:32:05
542
原创 在 Java 并发编程和高性能数据处理中，HashMap 和 ConcurrentHashMap 是两大核心容器。它们在 JDK 8+ 中的演进（链表转红黑树、锁机制优化）直接解决了特定业务场景下的性
JDK 7：分段锁 (Segment)。问题：如果哈希函数设计不佳，或者攻击者构造大量哈希冲突的 SKU ID（例如利用 String.hashCode() 的碰撞特性），导致某个 Bucket 下的链表长度达到几千。未优化前 (JDK 7)：每次 get() 商品都要遍历几千个节点，O(n) 复杂度导致 CPU 飙升，接口响应从 2ms 变 2s，甚至线程阻塞，引发雪崩。在无法完全避免哈希冲突（如依赖用户输入的 Key）的场景下，保证系统在最坏情况下的性能下限，防止因个别热点数据冲突拖垮整个服务。
2026-03-26 10:07:22
261
原创 - 当数据遇上AI，Twitter的数据挖掘实战（二）
你好，我是程序员贵哥。在上节课里，我们一起了解了Twitter整体搭建数据系统的经验。不过，那一篇论文的主要内容还是在方法论上，一旦我们想要把这个方法论利用到我们当下就在搭建的数据系统里，就有些无从下手的感觉。不过，好在Twitter还发表了很多有着具体实战经验的论文。那么，今天我就请你一起来学习下《》这篇论文。在这篇论文里，Twitter一点儿都没有藏私，而是给出了大量具体的实践技巧，你完全可以用“抄作业”的方式，把里面的做法用到自己的系统里。
2026-03-24 13:51:56
351
原创 - 从Omega到Kubernetes：哺育云原生的开源项目
你好，我是程序员贵哥。在前面两节课里，我们一起看过在2015年发表的Borg的论文。不过，Borg这个系统的开发与使用，其实要远远早于2015年。事实上，在2004年Google发表的MapReduce的论文里，我们就已经隐隐约约可以看到Borg的存在了。而在2015年，Borg也早就已经进行了很多次的进化。
2026-03-23 16:12:01
343
原创 Raft（二）：服务器增减的“自举”实现
你好，我是程序员贵哥。在上节课里，我们了解了Raft算法，知道了它是怎么把“状态机复制”这样一个问题，拆解成了Leader选举、日志同步以及安全性三个子问题。那么，今天这节课，我们会进一步深入来了解Raft算法的另外几个问题。这些问题，虽然在实践中我们必然会遇到，但是之前讲解各类分布式系统的时候，我们很少提到。正好，趁此机会，我们可以对在Raft集群中如何动态增减服务器，以及如何为Raft的状态机创建快照加以学习，并予以掌握。
2026-03-23 15:32:42
369
原创 - Raft（一）：不会背叛的信使
你好，我是程序员贵哥。在前面课程中，我们了解过的这些大数据处理系统，其实都属于分布式系统。所以，它们也都需要解决分布式一致性，或者说分布式共识的问题。我们之前已经介绍过Chubby，这个Google开发的分布式锁。正是通过Chubby这样的系统，使得我们可以确保系统里始终只有一个Master，以及所有的数据分区在一个时间点只有一个所有者。而Chubby的底层，就是这样的分布式共识（Distributed Consensus）算法。
2026-03-23 13:33:22
346
原创 Dataflow（三）：一个统一的编程模型
你好，我是程序员贵哥。在过去的几讲里，我们看到了大数据的流式处理系统是如何一步一步进化的。从最早出现的S4，到能够做到“至少一次”处理的Storm，最后是能够做到“正好一次”数据处理的MillWheel。你应该能发现，这些流式处理框架，每一个都很相似，它们都采用了有向无环图一样的设计。但是在实现和具体接口上又很不一样，每一个框架都定义了一个属于自己的逻辑。S4是无中心的架构，一切都是PE；Storm是中心化的架构，定义了发送数据的Spout和处理数据的Bolt；
2026-03-23 10:35:22
395
原创 - Dataflow（一）：正确性、容错和时间窗口
你好，我是程序员贵哥。在里，我们看到Storm巧妙地利用了异或操作，能够追踪消息是否在整个Topology中被处理完了，做到了“至少一次（At Least Once）”的消息处理机制。然后，在里，我们又看到了，Kafka通过将消息处理进度的偏移量记录在ZooKeeper中的方法，使得整个消息队列非常容易重放。Kafka的消息重放机制和Storm组合，就使得At Least Once的消息处理机制不再是纸上谈兵。然而，我们并不会满足于“至少一次”的消息处理机制，而是希望能够做到“”的消息处理机制。
2026-03-20 10:59:38
352
原创 Kafka（二）：从Lambda到Kappa，流批一体计算的起源
也就是我们无法保障，先从应用服务器发送出来的消息，会先被处理。因为下游是一个分布式的集群，所以先发送的消息X可能被负载均衡发送到Broker A，后发送的消息反而被负载均衡发送到Broker B。但是Broker B里的数据，可能会被下游的Consumer先处理，而Broker A里的数据后被处理。不过，对于快速统计实时的搜索点击率这样的统计分析类的需求来说，这些问题都不是问题。而Kafka的应用场景也主要在这里，而不是用来作为传统的消息队列，完成业务系统之间的异步通信。
2026-03-20 10:53:39
286
原创 - 从S4到Storm（二）：位运算是个好东西
你好，我是程序员贵哥。上节课里，我们看到了随着时代的变迁，人们已经不满足于通过MapReduce这样批处理的方式进行数据分析了。于是，Yahoo推出了S4，不过S4并没有在历史舞台上站稳脚跟。在S4的论文发表的同一年，我们今天的主角，也就是Storm走上了历史舞台。在接下来的几年里，Storm一度成为业界进行实时数据处理的标准解决方案。令人惊叹的是，Storm并不是来自哪一个业界的大公司。
2026-03-20 10:06:03
376
原创 从S4到Storm（一）：当分布式遇上实时计算
你好，我是程序员贵哥。到Spanner为止，我们已经把大数据里，关于数据存储和在线服务的重要论文解读完了。从这一讲开始，我们就要开始讲解另一个重要的主题，也就是大数据的流式处理。今天我们解读的第一篇论文，来自一个曾经辉煌但是今天已经逐渐销声匿迹的公司Yahoo。这篇论文就是《S4:Distributed Stream Computing Platform》，伴随着这篇论文的，同样是一个开源系统Apache S4。
2026-03-20 09:47:43
392
原创 Spanner（三）：严格串行化的分布式系统
你好，我是程序员贵哥。Spanner在设计时候的目标之一，就是需要保障外部一致性（external consistency）。而这个外部一致性，其实也就是我们之前说过的可线性化（Linearizability）。通过上节课的学习，现在我们已经知道了，这是一个非常有挑战的目标。其中Spanner采用了两个主要的策略来解决这个问题，第一个是通过原子钟和GPS时钟，尽可能地缩短服务器之间的时钟差异。
2026-03-20 09:14:27
333
原创 MySQL 架构 : Server 层 + Engine 层。InnoDB 引擎 存储结构 : 聚簇索引 vs 非聚簇索引。B+ 树。 事务与锁 : ACID, Undo/Redo Log, MVCC
特点：插件式存储引擎架构，使得 MySQL 可以灵活切换引擎（如 MyISAM, Memory, Archive 等），但 Server 层与 Engine 层之间通过 API 交互，存在一定性能损耗。Server 层：负责连接器、分析器、优化器、执行器等通用功能，处理 SQL 解析、权限校验、查询缓存（8.0 已移除）等。最左前缀法则：联合索引 (a, b, c)，查询跳过 a 直接用 b，或 a 用范围查询导致 b, c 失效。先写日志再写磁盘（WAL 技术），崩溃后可重放日志恢复。
2026-03-11 10:19:46
203
原创 Megastore（三）：让Paxos跨越“国界”
你好，我是程序员贵哥。过去的两讲，我们分别了解了Megastore的整体架构设计，以及它对应的数据模型是怎么样的。Megastore在这两点的设计上都非常注重实用性。，它把一个大数据库分区，拆分成了很多小数据库，互相之间相互独立。这样可以并行通过多组Paxos来复制每一个分区的事务日志，来解决单个Paxos集群的性能瓶颈问题。，Megastore更是进一步地引入了“实体组”这个概念，Megastore的一阶段事务，只发生在单个实体组这样一个“迷你”数据库里。
2026-03-09 10:44:03
416
原创 什么是B+树（B+ Tree）
优势：这使得B+树非常擅长范围查询（Range Query，例如 SELECT * FROM table WHERE id > 10 AND id , (L2)(L3) <-- 叶子节点 (存实际数据 + 链表指针)B+树（B+ Tree）是一种自平衡的多路搜索树，它是B树（B-Tree）的一种变体。非叶子节点（内部节点）仅存储键值（Key）和指向子节点的指针。B+树是严格平衡的，所有叶子节点都在树的同一层级。在B+树中，只有叶子节点存储实际的数据记录（或指向数据的指针）。
2026-03-06 17:00:37
247
原创 Megastore（一）：全国各地都能写入的数据库
你好，我是程序员贵哥。大数据技术一开始，更像一个专有系统。但是随着时间的推移，工程师们越来越多地让这些大数据系统支持上了SQL的特性。于是我们看到了Hive让大家可以用SQL来执行MapReduce任务，Dremel这样的系统更是一开始就支持了SQL。对于OLAP的分析类系统来说，支持Schema定义、支持字段类型、支持直接用类SQL的语言进行数据分析，很快就成为了新一代大数据分析系统的标准。所以，Google想要在Bigtable这样的OLTP数据库上支持SQL，也不会让我们意外了。
2026-03-05 16:03:18
390
原创 Spark：别忘了内存比磁盘快多少
你好，我是程序员贵哥。过去几讲里，无论是Hive这样基于MapReduce的系统，还是Dremel这样抛开MapReduce的系统，其实都已经反映了MapReduce这个大数据处理的计算模型，在2010年这个时间节点已经有一些“落后”了。来自Facebook的Hive选择了在MapReduce上优化改良，仍然基于MapReduce的模型。而Google自家的Dremel则是另起炉灶，用一个新的底层架构来支持OLAP的数据分析。不过，在工业界之外，学术界一样不会在整个大数据飞速发展的时代里缺席。
2026-03-05 15:06:20
381
原创 从Dremel到Parquet（二）：他山之石的MPP数据库
你好，我是程序员贵哥。在上节课里，我们看到了Dremel这个系统的数据存储是怎么回事儿的。不过，只是一个支持复杂嵌套结构的列存储，还没有发挥Dremel百分之百的威力。像Hive也在2011年推出了自己的列存储方案RCFile，并在后续不断改进提出了ORC File的格式。列存储可以让一般的MapReduce任务少扫描很多数据，让很多MapReduce任务执行的时间从十几分钟乃至几个小时，下降到了几分钟。
2026-03-04 10:57:54
396
原创 从Dremel到Parquet（一）：深入剖析列式存储
你好，我是程序员贵哥。在解读Hive论文的过程中，我们看到Hive已经通过分区（Partition）和分桶（Bucket）的方式，减少了MapReduce程序需要扫描的数据，但是这还远远不够。的确，MapReduce有着非常强的伸缩性，架起一个1000个节点的服务器毫无压力。可MapReduce的缺陷也很明显，那就是要知道，通常来说，我们的Hive表也好，或者以Thrift序列化后存放到HDFS上的日志也好，采用的都是“宽表”，也就是我们会把上百个字段都直接存放在一张表里。
2026-03-04 10:01:22
413
原创 分布式锁Chubby（三） ：移形换影保障高可用
你好，我是程序员贵哥。过去的两讲里，我们都在尝试做一件事情，就是在Master和Backup Master之间保持数据的同步复制。无论是通过分布式事务的两阶段提交算法，还是通过分布式共识的Paxos算法，都是为了做到这一点。而我们要去保障Master和Backup Master之间的同步复制，也是为了一个小小的目标，那就是。因为系统中只有一个Master节点，我们希望能够在Master节点挂掉的时候，快速切换到另外一个节点，所以我们需要这两个节点的数据是完全同步的。不然的话，我们就可能会丢失一部分数据。
2026-03-02 15:50:24
537
原创 分布式锁Chubby（二） ：众口铄金的真相
你好，我是程序员贵哥。上一讲里，我为你解析了两阶段提交和三阶段提交是怎么回事儿。相信你和我一样，对这两种解决方案都不太满意。虽然它们可以帮助我们实现一个分布式的事务，但同时也有着很明显的缺陷：这两个都是一个“单点”特别明显的系统，一旦作为单点的“协调者”出现网络问题或者硬件故障，整个系统就没法运行了。另一方面，如果你为了一致性，选择了两阶段提交，那么整个系统就是“同步阻塞”的，意味着整个系统的性能也会受到很大的影响。单点故障和同步阻塞，使得所谓的“分布式”系统的优势完全没有发挥出来。
2026-03-02 14:17:30
554
原创 分布式锁Chubby（一） ：交易之前先签合同
你好，我是程序员贵哥。在过去的十几讲课程里，我带你一起学习完了GFS、MapReduce，以及Bigtable这三篇被称之为Google的“三驾马车”的论文。不知道你有没有发现，这三篇论文有一个共同点，那就是这三个系统。而这就带来了一个问题，就是这个Master会成为整个系统的单点，一旦Master出现硬件故障，或者遇到Master网络不通的情况，整个集群就不能提供完整的服务了。
2026-03-02 11:19:12
894
原创 Bigtable（三）：SSTable存储引擎详解
你好，我是程序员贵哥。在上一讲里，我们已经了解了Bigtable的整体架构，知道作为一个分布式数据系统，里面“分布式”的部分是怎么设计的了。那么，今天我就带你一起来详细深入到Bigtable的“数据”部分里，去看看它是怎么回事儿。而且今天的这一讲，我们会“超越”Bigtable的论文，深入到MemTable和SSTable的具体实现。搞清楚这些问题，不仅对你学懂Bigtable不可或缺，也对你深入理解计算机底层原理有所帮助。
2026-03-02 09:58:35
908
原创 Bigtable（二）：不认识“主人”的分布式架构
你好，我是程序员贵哥。上一讲里我们一起分析了如何对一个MySQL集群进行扩容，来支撑更高的随机读写请求。而在扩容过程中遇到的种种不便，也让我们深入理解了Bigtable的设计中需要重点解决的问题。第一个问题，自然还是如何支撑好每秒十万、乃至百万级别的随机读写请求。第二个问题，则是如何解决好“可伸缩性”和“可运维性”的问题。在一个上千台服务器的集群上，Bigtable怎么能够做到自动分片和灾难恢复。今天我们就先来看看第二个问题，其实也是Bigtable的整体架构。
2026-03-02 09:26:18
625
原创 - Bigtable（一）：错失百亿的Friendster
你好，我是程序贵哥。过去两周，我们一起看完了GFS和MapReduce的论文。相信这个时候的你一定自信满满，有一种“我上我也行”的感觉。的确，GFS和MapReduce通过非常简单的设计，帮助我们解决了海量数据的存储、顺序写入，以及分布式批量处理的问题。不过我们也要看到，GFS和MapReduce的局限性也很大。在GFS里，数据写入只对顺序写入有比较弱的一致性保障。而对于数据读取，虽然GFS支持随机读取，但是考虑到当时Google用的是孱弱的5400转的机械硬盘，实际上是支撑不了真正的高并发地读取的。
2026-02-27 10:42:20
429
原创 - MapReduce（二）：不怕失败的计算框架
你好，我是程序员贵哥。通过上节课的学习，现在你已经知道MapReduce的编程模型是怎么回事儿了。对于开发者来说，你只需要写一个Map函数和一个Reduce函数，就能完成数据处理过程。具体这些任务用了多少服务器，遇到了失败是怎么解决的，你并不需要关心。不过，要想学习如何搭建和改进分布式系统，了解MapReduce的底层原理必不可少。今天，我们就一起来看看MapReduce的框架干了什么。MapReduce这个“保姆”，为什么可以让你不需要处理复杂的分布式架构的问题。
2026-02-26 17:16:22
296
原创 MapReduce（一）：源起Unix的设计思想
你好，我是程序员贵哥。在解读完GFS的论文之后，相信你现在对“分布式系统”已经有了初步的了解。本质上，GFS是对上千台服务器、上万块硬盘的硬件做了一个封装，让GFS的使用者可以把GFS当成一块硬盘来使用。通过GFS客户端，无论你是要读还是写海量的数据，你都不需要去操心这些数据最终要存储到哪一台服务器或者哪一块硬盘上。你也不需要担心哪一台服务器的网线可能松了，哪一块硬盘可能坏了，这些问题都由GFS这个“分布式系统”去考虑解决了。不过，GFS仅仅是解决了数据存储和读写的问题。
2026-02-26 14:54:47
286
原创 The Google File System （三）： 多写几次也没关系
你好，我是程序员贵哥。在前面的两讲中，我们一起探讨了GFS系统设计中秉持的两个原则，分别是“保持简单”和“根据硬件特性设计系统”，而今天我们要讨论的GFS的最后一个设计特点，是“分布式系统的一致性要求是一个很有挑战的话题。如果说分布式系统天生通过更多的服务器提升了性能，是一个天然的优点，那么在这些通过网络连起来的服务器之间保持数据一致，就是一个巨大的挑战。毕竟网络传输总有延时，硬件总会有故障，你的程序稍有不慎，就会遇到甲服务器觉得你的钱转账失败，而乙服务器却觉得钱已经转走了的情况。可以说，。
2026-02-26 14:27:15
373
Linux系统技术可以学习一下
2024-01-26
播为主播提供一站式直播必备工具 包含弹幕助手、屏幕美化、语音播报、弹幕点歌等主播必备核心功能,目前已支持虎牙、斗鱼,抖音等、平台
2023-10-13
TestSyncMethods.java
2021-07-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人