实战从零开始实现Raft｜得物技术

原创 于 2024-08-08 10:00:00 发布 · 2.7k 阅读 · 20 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#分布式

一、前言

Raft算法是一种分布式一致性算法，由Diego Ongaro和John Ousterhout在2013年提出。它主要用于分布式系统中，保证系统中的数据在多个节点间保持一致性。

Raft算法被广泛应用于众多分布式系统中，尤其是在需要强一致性保证的场景中，例如：

  • 分布式存储系统：如ETCD、Consul等键值存储系统，它们利用Raft算法来保证数据的强一致性和高可用性。

  • 分布式数据库：一些分布式数据库管理系统（DBMS），如CockroachDB等。

  • 分布式锁服务：例如Google的Chubby以及微软的Azure Service Bus等。

得物的多个内部中间件也是使用Raft算法作为多分片一致性的保证。

长期以来，大部分开发者都是将Raft作为一个黑盒使用，只知道它能保证多分片的一致性，对其运行原理也停留在纸面。当面临Raft性能调优或者奇怪的Raft问题排障的时候则束手无策。

费曼说过：“What I cannot create, I do not understand。” 我们中国先贤也强调“知行合一，以致良知”。如果我们不能亲手编写一次Raft算法，对这个东西就不能算作理解。

二、核心概念

在着手开始写之前，我们先介绍几个Raft算法中的核心概念。

日志复制状态机

如果说什么是分布式系统理论的基石，那一定“日志”。此处的日志与我们平时在应用中打印的给人阅读的信息不同，它是最简单的存储抽象，是按时间排序的append-only的、有序的记录序列。

01.jpg

“日志”揭示了系统当下正在发生的事实。

关于日志的更深入理解，可以参考博客The Log: What every software engineer should know about real-time data’s unifying abstraction，非常全面深刻。

当进入分布式的领域，日志就需要“状态机”的辅助：

  • 如果两个相同的确定性过程以相同的状态开始并以相同的顺序获得相同的输入，它们将产生相同的输出并以相同的状态结束。

  • 确定性意味着处理不依赖于时间，并且不会让任何其他输入影响其结果。例如，一个程序的输出受到线程特定执行顺序或调用gettimeofday或其他一些不可重复的东西的影响，通常最好被认为是非确定性的。

  • 进程的状态是在处理结束时保留在机器上的任何数据，无论是在内存中还是在磁盘上。

关于以相同的顺序获得相同的输入的一点应该会引起人们的注意——这就是日志的用武之地。这是一个非常直观的概念：如果你将两段确定性代码提供给相同的输入日志，它们将产生相同的输出。

所以Raft最重要的任务就是解决如何在分布式系统中使多个副本的日志数据达成一致的问题。

Leader、Follower、Candidate

为了实现上述目标，Raft使用强领导模型，即要求集群中的一个副本充当Leader，其他副本充当Follower。

Leader负责根据客户端请求采取行动生成命令，将命令复制给Follower，并将响应返回给客户端。

多个副本根据选举算法推选合法的Leader。

02.jpg

这个方案解决了分布式系统中的以下问题：

  • 容错性（Fault Tolerance）：分布式系统中可能会出现节点故障，包括宕机、网络分区等问题。通过这些角色的分工和协作，系统可以在一定数量的节点出现故障时仍然正常运行。

  • 领导者选举（Leader Election）：在分布式系统中，通常需要一个节点（Leader）来协调其他节点（Followers）的工作，以确保一致性和效率。Leader负责管理日志复制、决策提议等任务。当Leader失效时，系统需要能够选举出新的Leader。

  • 一致性（Consensus）：为了保证系统状态的一致性，需要所有节点就某个值或状态达成共识。这通常通过一系列的投票和通信过程来实现，其中Candidate角色在选举过程中起到关键作用。

  • 去中心化（Decentralization）：在去中心化的系统中，没有中央权威来决定系统状态。这些角色的引入有助于在没有中心节点的情况下实现一致性和决策。

这种模型有其优点和缺点：

  • 显著的优点是简单。数据总是从领导者流向Leader，只有Leader响应客户端请求(工程实践中有例外)。这使得Raft集群更容易分析、测试和调试。

  • 缺点是性能——因为集群中只有一台服务器与客户端通信，这在客户端活动激增的情况下可能成为瓶颈。当然这个可以通过一些工程手段在一致性和吞吐性能中做出平衡，例如我们可以放弃强一致的要求，从Follower中读取数据，减轻Leader的负担，关于一致性的部分，可以参考文章《共识、线性一致性、顺序一致性、最终一致性、强一致性概念区分》。

三、Why Elixir

本系列中介绍的Raft实现是用Elixir编写的。在笔者看来，Elixir具有三个优势，使其成为本系列和网络服务的有前途的实现语言：

  • Raft框架需要大量的网络编程，而Elixir基于Erlang在网络编程方面体验一骑绝尘，甚至自带RPC实现；

  • Elixir自带一个功能强大的Shell，开发调试的难度大大降低；

  • Raft这类算法需要大量的并发编程，而并发编程在Elixir中就像呼吸一样简单；

  • Erlang语言的OTP框架大大降低的服务器编程的心智负担，常见的服务端编程场景都有合适的解决方案。

这个项目的开发中，笔者借鉴了这个生产级别的开源Raft库——龙舟的实现细节，如果对生产级的Raft实现感兴趣，可以阅读龙舟的代码。

我们的实现大致代码结构如下：

.                                                                                                                                                                                                                                                    
├── README.md                                                                                                                                                                                                                                        
├── Taskfile.yaml                                                                                                                                                                                                                                    
├── lib                                                                                                                                                                                                                                              
│   └── ex_raft                                                                                                                                                                                                                                      
│       ├── config.ex                                                                                                                                                                                                                                
│       ├── core               # 各个状态下的处理逻辑                                                                                                                                                                                                                      
│       │   ├── candidate.ex                                                                                                                                                                                                                         
│       │   ├── common.ex                                                                                                                                                                                                                            
│       │   ├── follower.ex                                                                                                                                                                                                                          
│       │   ├── free.ex                                                                                                                                                                                                                              
│       │   ├── leader.ex                                                                                                                                                                                                                            
│       │   └── prevote.ex                                                                                                                                                                                                                           
│       ├── debug.ex                                                                                                                                                                                                                                 
│       ├── exception.ex                                                                                                                                                                                                                             
│       ├── guards.ex                                                                                                                                                                                                                                
│       ├── log_store        # 日志存储，本节暂时不用                                                                                                                                                                                                                 
│       │   ├── cub.ex                                                                                                                                                                                                                               
│       │   └── inmem.ex                                                                                                                                                                                                                             
│       ├── log_store.ex
最低0.47元/天 解锁文章
得物技术
关注
博客
从数字到版面：得物数据产品里数字格式化的那些事
11-25 385
本文探讨了数字格式化在前端开发中的重要性，指出规范的数字排版是数据展示系统的"地基"。文章分析了数字格式化的复杂性，包括不同文化背景下的小数分隔符差异（如英美使用小数点，欧洲使用逗号）以及数字语义表达（如百分比、缩写等）。作者指出传统手动拼接字符串或正则处理方式的弊端，如视觉混乱、国际化障碍等，并推荐使用现代浏览器提供的Intl.NumberFormat API进行标准化处理。文中以电商平台为例，展示了缺乏统一格式化方案导致的排版问题，强调建立数字格式化基础设施对提升系统专业度和维护性的
博客
一文解析得物自建 Redis 最新技术演进
11-20 979
本文介绍了自建Redis的技术演进历程，重点阐述了接入方式、同城双活就近读、Redis-server版本升级等关键优化。自建Redis目前已管理1000+集群，内存总规格160T，支持千万级QPS。技术方面，从LB接入演进为自研DRedis SDK直连proxy，解决了LB瓶颈问题并提升性能30%；通过SDK实现同城双活就近读，降低业务RT；Redis-server升级至6.2版本并移植多线程等特性，使读写性能提升50%。同时构建了完善的自动化运维平台，支持集群全生命周期管理。这些优化显著提升了Redis服
博客
Golang HTTP请求超时与重试：构建高可靠网络请求｜得物技术
11-18 1000
本文探讨分布式系统中HTTP客户端的可靠性优化策略。重点分析了超时控制的必要性，指出78%服务中断与不合理超时配置相关，并给出Golang标准库的防御性配置方案。通过context实现请求级超时传递，结合指数退避和随机抖动设计智能重试机制，强调幂等性保证对数据一致性的重要性。最后提出连接池优化和内存复用等性能提升手段，建议合理配置MaxIdleConnsPerHost等参数可显著降低延迟。文章强调超时和重试是分布式系统的生存必需，需在可靠性、性能和控制策略间取得平衡。
博客
得物TiDB升级实践
11-11 1521
得物DBA团队完成了TiDB数据库从5.3.3到7.5.x版本的大版本升级。本次升级采用迁移升级方案，通过搭建新集群并同步数据，最小化业务影响。新版本在查询性能、TiCDC同步稳定性、备份效率等方面均有显著提升，整体性能提升40%，备份时间缩短50%。升级过程中遇到优化器执行计划不准确等问题，通过参数调整和SPM绑定解决。7.5.x版本还引入高压缩存储引擎和更完善的运维工具，有效降低了存储成本和运维复杂度。此次升级为公司业务发展提供了更稳定高效的数据库支撑。
博客
得物管理类目配置线上化：从业务痛点到技术实现
11-06 1537
本文针对电商管理类目规则调整效率低下的问题，提出了"管理类目配置线上化"的技术解决方案。通过分层架构设计实现业务与数据链路解耦，采用规则生命周期管理和状态机驱动机制，结合多级类目查询、树形结构构建和规则填充等技术模块，解决传统手工流程效率低、规则校验能力不足、系统耦合严重等痛点。方案设计了超时机制防止流程阻塞，实现类目状态变化的级联传播，并建立完善的规则变更校验逻辑。通过线上化改造，将规则迭代周期从3-4周缩短至1-2天，显著提升业务响应速度和管理效率。
博客
大模型如何革新搜索相关性？智能升级让搜索更 “懂你”｜得物技术
11-04 1187
摘要：得物技术团队针对传统搜索相关性模型存在的标注成本高、扩展性差、泛化能力弱等问题，基于大语言模型进行了技术升级。通过知识蒸馏和二阶段推理流程优化，将大盘准确率提升至86.67%，中长尾场景准确率提升6.78%。新方案通过大模型标注+数据蒸馏策略，累计节约百万级标注成本，线上相关性badcase率显著下降。未来将继续探索生成式强化学习等方向，持续提升搜索体验。（149字）
博客
RAG—Chunking策略实战｜得物技术
10-30 623
摘要：本文探讨了RAG系统中文档分块（chunking）对问答性能的关键影响。不当的分块会导致语义断裂和信息缺失，而高质量分块应尊重文档结构（标题、段落等），并保持适度重叠以确保上下文连贯。文章详细介绍了多种分块策略，包括基础分块（固定长度、句子级）、结构感知分块（利用标题、表格等）、语义分块（基于内容相似度）以及混合分块方法，并提供了参数调优建议和代码示例。最后强调分块质量决定了RAG的性能上限，是优化检索与生成效果的首要环节。
博客
从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术
10-23 1252
本文分析了Spring框架中循环依赖问题的产生原因及解决方案。文章通过一个后台服务启动失败的案例，深入探讨了Spring三级缓存机制如何解决循环依赖，并指出在AOP代理场景下可能出现的"半成品"注入问题。作者详细解读了@Transactional和@Validated注解在循环依赖处理中的差异，解释了为何后者更容易导致启动失败。最后提出了短期解决方案（移除@Validated注解或使用@Lazy）和长期优化建议（遵循DDD规范、使用循环依赖检测工具）。文章强调循环依赖暴露了代码设计缺陷，
博客
Apex AI辅助编码助手的设计和实践｜得物技术
10-21 1778
Apex是一款基于VSCode的AI辅助开发插件，通过SSO认证、知识库集成、远程Webview等技术实现无感安装和智能体使用。其核心架构分为插件层、Webview UI层和服务层，支持版本编排解耦、安全鉴权和工程化落地。功能模块包括：1）激活装配流程采用按需加载避免冷启动问题；2）SSO认证实现安全闭环；3）GitLab维护的规则知识库支持多仓同步；4）远程Webview实现无感更新；5）Monorepo识别与智能体模板管理；6）埋点系统记录用户行为。Apex通过工程化手段将AI能力融入开发流程，提升编码
博客
从 JSON 字符串到 Java 对象：Fastjson 1.2.83 全程解析｜得物技术
10-16 1544
Fastjson核心特性在于高速序列化/反序列化，利用ASM在运行时生成字节码动态创建解析器，减少反射；AutoType字段支持多态，却带来反序列化RCE风险，建议关闭AutoType，开启safeMode。选型建议：在选择JSON序列化框架时对于非极端性能要求推荐Jackson，或者使用Fastjson2，其改用LambdaMetafactory替换ASM，性能再提升30%，默认关闭AutoType安全性有保证。
博客
线程池ThreadPoolExecutor源码深度解析｜得物技术
10-14 1494
本文深入解析了Java线程池的核心原理与实践要点。首先阐述了线程池的必要性，包括避免频繁创建销毁线程的资源开销、提升系统吞吐量等优势。接着详细剖析了ThreadPoolExecutor的架构设计、参数配置（核心线程数、最大线程数、阻塞队列等）和运行机制，通过源码分析其任务调度流程和生命周期管理。针对常见问题，文章指出invokeAll超时失效、submit异常消失等陷阱，并给出解决方案。
博客
基于浏览器扩展 API Mock 工具开发探索｜得物技术
09-23 1495
本文介绍了一款基于浏览器插件的Mock工具开发实践。该工具通过重写fetch和XMLHttpRequest实现API请求拦截，支持多种Mock规则创建方式（包括API管理平台导入和手动配置），并提供了页面白名单管理、请求日志记录等功能。文章详细阐述了Manifest V3架构下的技术实现方案，包括请求拦截原理、脚本注入策略和整体架构设计。该工具旨在帮助开发者在接口未完成或需要问题复现时提升开发效率，同时探索了AI在浏览器插件开发中的辅助作用。未来计划扩展功能包括历史请求快速Mock和结合AI生成Mock数据
博客
破解gh-ost变更导致MySQL表膨胀之谜｜得物技术
09-18 1501
MySQL DDL变更导致表空间膨胀问题分析 本文分析了MySQL在进行DDL变更时导致表空间膨胀的案例。通过复现问题发现，当单行记录过大（5k左右）时，结合变更工具的特殊机制（先写入大主键记录），会触发MySQL的页分裂缺陷，导致一个16k的页仅存储1条记录，浪费2/3空间，最终使表空间膨胀近100%。同时，这种异常页分裂还会导致统计信息严重偏差，进而引发部分SQL出现慢查询。文章详细介绍了InnoDB索引结构、页分裂机制和当前DDL变更流程，并提出了临时解决方案（原生alter table）和长期优化方
博客
MySQL单表为何别超2000万行？揭秘B+树与16KB页的生死博弈｜得物技术
09-16 1395
MySQL单表数据量建议控制在2000万以内的核心原因在于B+树索引结构的设计。InnoDB存储引擎采用16KB数据页存储数据，通过B+树组织索引，非叶子节点存储主键和指针，叶子节点存储完整行数据。三层B+树可支撑约2.5千万数据，查询最多只需3次磁盘IO；当数据量超过临界值，树高增至4层，IO次数增加将导致查询性能显著下降。该限制值受行大小影响，若单行数据更小（如250字节），三层B+树可支撑上亿数据。相比B树，B+树的高扇出特性使其更适合作为数据库索引。优化建议包括控制单行大小、分库分表等，在磁盘I/O
博客
前端日志回捞系统的性能优化实践｜得物技术
09-09 1521
本文介绍了现代前端日志回捞系统的性能优化实践，重点解决存储膨胀、包体积过大和性能影响三大问题。通过智能清理策略（时间/数量双重清理）、异步加载上传模块（CDN动态加载）和日志队列优化（限流+空闲执行），显著提升了系统性能。同时分享了打包构建中的技术难点（如UMD动态导入、process对象注入等）及其解决方案。这些优化不仅使日志系统更轻量高效，也为前端工程化提供了宝贵经验。
博客
得物灵犀搜索推荐词分发平台演进3.0
09-04 1479
《电商导购系统中的词分发平台架构演进》摘要：本文系统介绍了电商导购场景中词分发平台的技术架构演进。该平台通过集成下拉词、热搜榜单等智能推荐功能，显著提升用户购物效率。平台采用模块化设计，实现脚本热部署、图化DAG引擎等创新架构，支持30+导购场景。核心创新包括：1）主工程+脚本工程的分离架构；2）基于算子抽象的图化编排框架；3）配套灰度发布、DIFF评估等工具链。未来规划重点在于平台功能扩展、性能优化及算法链路打通，持续提升导购精准度和系统扩展性。
博客
R8疑难杂症分析实战：外联优化设计缺陷引起的崩溃｜得物技术
09-02 1552
在Android开发中，即使是AGP、R8这样的官方工具链升级，也要保持足够的警惕。毕竟Android生态太过复杂，再加上开发者们千奇百怪的代码写法，不论多么完善的测试流程都无法规避这类特定场景的bug。这次的ApiModel外联优化问题就是一个很好的例子——它只在特定条件下才会暴露，但一旦出现就是必现的native崩溃。所以对于这种影响面无法评估的重大升级，还是需要经过足够长时间的独立灰度验证，才能合入主干分支。往期回顾1. 可扩展系统设计的黄金法则与Go语言实践｜得物技术。
博客
可扩展系统设计的黄金法则与Go语言实践｜得物技术
08-28 1790
本文系统讲解了如何利用Go语言设计可扩展的系统。首先分析了可扩展系统的必要性，指出其核心目标是让系统能以最小修改成本适应未来变化。随后从架构设计原则、编码实践、实现模式、验证指标到演进路线展开详细阐述，重点介绍了开闭原则、模块化设计、策略模式、中间件链、插件化架构等关键技术在Go语言中的实现方式。文章强调扩展性设计要在当前需求和未来变化间找到平衡，建议定期进行架构评审，通过压力测试和代码分析评估系统健康度。最后指出优秀的系统不是完美的，而是能够持续进化的，保持开放心态才能应对技术领域的快速发展。
博客
营销会场预览直通车实践｜得物技术
08-21 1892
摘要：得物电商平台针对营销会场配置痛点的创新解决方案，通过"时间穿越"技术实现全链路预验证。该方案支持模拟未来时间、指定用户人群和AB实验命中，在配置阶段提前校验活动效果，有效解决多目标耦合、验证滞后和跨团队协作三大挑战。实施后使配置工作量减少50%，走查覆盖率提升至80%以上，并规避了资损风险。未来计划将穿越能力扩展至频道、商详页等更多场景，持续优化电商营销配置效率与风险管理。（149字）
博客
基于TinyMce富文本编辑器的客服自研知识库的技术探索和实践｜得物技术
08-19 1514
得物自研客服知识库系统，解决了第三方知识库在业务快速发展下面临的维护体量增大、系统协作效率低等问题。系统采用TinyMCE富文本编辑器，支持表格编辑和格式兼容，并通过结构化段落设计实现细粒度知识管理。针对图片迁移问题，系统自动替换旧链接；通过懒加载技术优化大量图片导致的页面卡顿；利用截图生成模板缩略图提升用户体验；扩展编辑器API实现全局查找替换功能。此外，系统结合ES检索和大模型能力，提供智能问答、答案推荐和联网搜索等场景支持，显著提升了客服工作效率和知识管理能力。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值