从第一行代码到发链只需一小时,用这款新工具,你也能做到

部署运行你感兴趣的模型镜像

640?wx_fmt=png

古罗马,“乘法”是只有御用数学家才能理解的深奥概念——而当阿拉伯数字出现,孩童亦能于纸上演算。

新工具不仅提升效率,还可为前人所不能。作为活跃开发领域之一,区块链新技术、工具、平台、语言与框架层出不穷,然而面对纷繁复杂的选择,开发者难以面面俱到。《区块链大本营 | 新工具》栏目每周将为开发者介绍最值得关注的新技术与工具。未来,我们还将多角度、系统地为项目选型提供指南。




“这是应对区块链极繁主义的最好手段”

——Parity创始人Gavin Wood如是说,他也是Ethereum创始人和Solidity设计者之一。

上周,Gavin在柏林Web3峰会现场演示了一种新框架——Substrate。他使用一台刚启封的Macbook Pro,从编写第一行代码,到发布区块链,用时不足60分钟。Substrate目的是让发布区块链就像发布智能合约一样容易。

640?wx_fmt=jpeg

最大自由,最少代价

Parity的明星项目Polkadot就是基于Substrate构建的——前者是一种由多条链,异构组成的区块链集合,其目的是成为不同区块链间的媒介。Substrate先前的主要目的是让开发者能在Polkadot上快速启动平行链,不过Substrate框架本身还具备发布独立区块链的能力,这让它成为独立于Polkadot的项目,不依赖后者的开发进度,本月晚些时候,Substrate 1.0-beta将会公开发布。

与Express或其他Web应用框架类比,Substrate是用来构建分布式或去中心化系统的,如加密货币项目或消息总线系统。就如大多数Web应用程序不需要重新实现HTTP一样,Gavin Wood认为,所有人都从头构建网络和共识代码,非常浪费精力使用Substrate来构建新项目,开发者所要做的,就是在代码调用少量函数,就能获得各种密码学模板,以及定制、搭建和发布新区块链所需要的方方面面,“Substrate为区块链开发者提供最大限度的自由,花费最少的精力”。

高通用技术栈

Substrate在设计时,考虑了支持大多数现有和未来可能出现的区块链应用场景。其技术栈主要由以下几个具备高通用和扩展潜能的部分组成。

640?wx_fmt=png

1. 对区块链应用架构来说,State Transition Function(STF)代表其核心商业逻辑,STF的功能集合、有何种限制,决定了区块链的应用场景。Substrate运行时采用WebAssembly的一个子集,具有跨平台和轻量的特点。在1.0-beta版本中,开发者可以使用纯Rust、C++和C编写STF;通过WebAssembly支持的其他语言,将在后续引入。

2. 网络部分基于Libp2p,开箱即用。对于需要其他网络消息支持的区块链应用,未来版本的Substrate计划引入一个网络拓扑API。

3. 为了适应快速应用开发,Substrate支持包括Polkadot SHAFT(GRANDPA)在内的多种共识算法。密码学数据库后端及块格式,都可以定制或重写。在1.0-beta版本中,将包含以下几类共识算法,当然开发者还可以通过Substrate API设计自己的共识算法。

  • Rhododendron

  • SHAFT/GRANDPA

  • Aurand

  • Ouroboros

  • PoW

  • Parachain(PoV)


Substrate提供的其他工具还包括:

  • Polkadot连接

  • 可以热替换和插入的共识机制

  • 可以热升级和插入的STF

  • Pub/Sub WebSocket JSON-RPC

  • 轻量客户端

  • 交易队列

  • 安全网络

  • JavaScript实现

  • Substrate运行时模块库(SRML)

因为具备一系列链上热升级机制,无论修改共识算法还是升级STF,开发者都无需硬分叉。作为例证,今年7月17日,Polkadot的“Krumme Lanke”测试网络进行过公开演示,至今依然正常运行。

创建Substrate运行时模块库(SRML)的目的,是为了帮助开发者更迅速地发布区块链。开发者只需要将一组模块集合,便能实现相应的网络、共识、轻客户端或者其他需要的功能,新功能可以通过创建新模块实现。

640?wx_fmt=png

SRML之外,Substrate在设计中还额外引入了两层逻辑:

1. 可通过JSON配置的通用区块链节点,用于执行其运行时;

2. 一个精简的区块链内核引擎,用于处理共识、块生成、网络、数据库等功能。

此外,企业和金融敏感用户关注的高级隐私和权限管理,也能轻松加入并通过Substrate进行控制,而无需与Polkadot产生瓜葛,并通过桥接或成为原生Parachain的方式升级。

640?wx_fmt=png


注:Substrate项目地址为https://github.com/paritytech/substrate


--【完】--


公众号又又又改版了,为了不错过第一手推送消息,建议你按照图片的提示,将【区块链大本营】设为星标(安卓用户设为“置顶”),标星看大图更爽哟!


640?wx_fmt=gif


推荐阅读


640?wx_fmt=png


大力戳↑↑↑  加入区块链大本营读者⑦号群

(内容转载请联系微信:优快云_qkldby)

(商务合作请联系微信:fengyan-1101)



免费公开课|扫码即可报名 

想学习超级账本的同学千万不要错过!开课前报名可免费观看直播和回放,课程结束后只有会员才可免费观看回放哦


640?wx_fmt=png

您可能感兴趣的与本文相关的镜像

ComfyUI

ComfyUI

AI应用
ComfyUI

ComfyUI是一款易于上手的工作流设计工具,具有以下特点:基于工作流节点设计,可视化工作流搭建,快速切换工作流,对显存占用小,速度快,支持多种插件,如ADetailer、Controlnet和AnimateDIFF等

<think> 我们正在讨论的是MySQL分表扩容方案,用户现在特别关注停服迁移方案中存在的迁移失败需回退代码的风险,并询问是否有更好的方案。 根据用户的问题,我们需要考虑在停服迁移过程中如何降低风险,特别是当迁移失败时如何避免复杂的回退操作。 回顾之前的讨论: - 停服方案:需要停机,操作简单但停机时间长,存在迁移失败需回滚的风险(包括数据回滚和代码回滚)。 - 不停服方案:通过双写、数据迁移、灰度切换等步骤实现零停机,但架构复杂。 用户现在担心停服迁移如果失败,回退代码(即回滚应用程序的代码版本)会带来风险。因此,我们需要考虑如何优化停服方案以降低风险,或者是否有替代方案。 分析: 1. 停服迁移失败的风险点: - 数据迁移过程中出现错误(如数据不致、丢失等) - 迁移时间超出预期,导致停机时间过长 - 代码存在未知缺陷,导致服务无法正常启动 2. 如何降低风险? - 备份:在迁移前进行全量备份(如使用mysqldump或物理备份工具)[^3],这样在失败时可以快速恢复数据。 - 预迁移演练:在测试环境模拟整个迁移过程,包括回滚步骤。 - 分阶段迁移:将迁移过程拆分成多个阶段,每个阶段完成后进行验证,有问题可及时回退。 - 回滚计划:提前准备好回滚脚本,包括数据回滚和代码回滚。 3. 替代方案:采用不停服方案(双写方案)可以避免停服,从而避免停服迁移失败的风险,但实施复杂度高。 考虑到用户可能希望有个比停服方案更安全但比不停服方案更简单的方案,我们可以考虑种折中的方案:**分阶段停服迁移**。 具体方案如下: ### 改进方案:分阶段停服迁移(滚动迁移) 此方案的核心思想是将数据迁移分成多个阶段,每次只迁移部分数据,并分批次切换流量,从而减少每次停服的时间窗口和影响范围。 #### 步骤: 1. **准备工作**: - 创建50张表(与停服方案相同)。 - 修改应用代码,使其同时支持旧两种分表规则(即支持访问旧表0-4和表0-49),但默认情况下仍然使用旧表。代码中增加个开关(例如配置中心开关),可以控制读写操作使用表还是旧表。 2. **分阶段迁移数据**: - 将旧表数据按照定的规则(例如按用户ID范围)分成多个批次。 - 在业务低峰期,停止对当前批次数据的写入(可以通过临时禁用部分功能或者将这部分用户请求暂时拒绝),然后迁移该批次数据到表。 - 迁移完成后,开启该批次数据对应的表的读写(通过配置中心将该部分用户的路由切换到表),并恢复服务。 - 重复以上步骤,直到所有数据迁移完成。 3. **最终切换**: - 当所有数据都迁移到表,并且验证无误后,将整个应用的读写完全切换到表(通过配置中心全局切换)。 - 删除旧表(可以先重命名备份,待观察段时间后再删除)。 4. **回退计划**: - 如果在某个阶段迁移失败,可以快速回退:将该批次数据的路由重切回旧表,并恢复该批次数据的服务。由于每个批次的数据量较小,回退速度快。 - 如果在表使用过程中现问题,可以通过配置中心将整个应用回退到旧表(此时旧表数据仍然保留,并且迁移过程中旧表的数据通过双写更?注意:这里需要解决迁移过程中旧表的数据更问题) 注意:在迁移过程中,对于正在迁移的批次,需要停止写入。因此,需要确保每个批次的数据迁移在较短时间内完成(例如几分钟内)。另外,对于非迁移批次的数据,服务可以正常提供。 但是,这个方案需要解决迁移过程中数据更的问题。因为在迁移个批次时,该批次的数据在迁移开始后可能还有更(如果不停写)。因此,我们必须在迁移该批次时停止该批次的写入。这可以通过以下方式实现: - 在应用层,对该批次的用户请求进行临时降级(例如返回“系统维护中”),待迁移完成后恢复。 - 或者,在迁移开始前,先记录该批次数据在迁移开始时的最大ID(或时间戳),迁移完成后,再将该批次在迁移期间生的增量数据(通过binlog或应用日志)同步到表,然后切换。 第二种方式更复杂,但可以做到用户无感。具体步骤: a. 开启增量日志:在迁移开始前,记录该批次数据在旧表上的最后更时间戳或最后ID。 b. 停止该批次的写操作(通过配置中心将该批次用户的路由暂时切换到维护状态,或者通过应用层暂时拒绝该批次用户的写请求),然后导出该批次数据到表。 c. 导出过程中,记录该批次在旧表上生的增量更(通过binlog解析或应用层的双写日志,但注意此时该批次已被禁止写,所以理论上不应该有增量,但为了防止有延迟的请求,可以捕获在开始迁移后产生的增量)。 d. 将增量更应用到表。 e. 切换该批次用户的路由到表,并恢复写服务。 然而,这种方法实现起来比较复杂,且需要应用层支持按批次禁用用户请求。 因此,如果业务允许短时间的不可用(比如每个用户只影响几秒钟),可以采用第种方式(临时降级)。否则,可能需要更复杂的增量同步。 #### 优缺点: - 优点: * 每次只迁移小部分数据,风险分散。 * 每次停服的时间窗口短(只针对部分用户),整体影响面小。 * 回退容易,只需回退当前批次。 - 缺点: * 需要应用支持按用户批次进行路由切换和降级。 * 需要多次操作,整体周期长。 * 对于迁移过程中数据更的处理较为复杂。 对比原停服方案,该方案将风险分散到多个批次,每个批次的影响可控。但实施复杂度介于原停服方案和不停服方案之间。 另外,如果业务不能接受任何停机,那么还是建议采用不停服的双写方案。 ### 建议: 根据业务场景选择: - 如果数据量不大(例如小于1TB)且可以接受分钟级的单批次停机,可以采用分阶段停服迁移。 - 如果完全不能接受停机,则采用不停服双写方案。 最后,无论采用哪种方案,都必须做好备份[^3]和回滚计划[^2]。 关于回滚计划,特别注意: - 在分阶段迁移中,每个批次迁移前备份该批次涉及的旧表数据。 - 如果迁移失败,需要将表中该批次的数据删除,并从备份中恢复旧表的数据(如果有增量更,还需要用binlog恢复增量)。 因此,分阶段停服迁移虽然降低了整体风险,但需要更精细的操作和工具支持。 以上方案供参考,具体实施时需要根据业务特点进行调整。 现在,针对用户的问题,我们给出了个改进方案(分阶段停服迁移)作为原停服方案的优化,以降低迁移失败时的回退风险。 同时,我们也可以建议用户考虑不停服方案,虽然实施复杂,但可以彻底避免停服风险。 下面,我们以结构化的方式呈现这个改进方案。 --- ### 改进方案:分阶段停服迁移(降低回退风险) #### 核心思想 将全量数据划分为多个批次,每次仅迁移个批次的数据,并同步切换该批次的流量到表。通过小批量迁移降低单次风险。 #### 实施步骤 1. **预置条件**: - 创建50张表(同原停服方案) - 应用层改造: - 支持动态路由(根据用户ID路由到表或旧表) - 增加配置中心开关,控制批次迁移开关 2. **数据分批**: - 按用户ID范围划分批次(例如每批100万用户) - 批次划分示例: ```sql /* 计算批次边界 */ SELECT MIN(user_id), MAX(user_id) FROM user_0; -- 对每个旧表执行 ``` 3. **单批次迁移流程**: ```mermaid graph TB A[开始批次迁移] --> B[禁止该批次写请求] B --> C[备份该批次旧表数据] C --> D[迁移旧数据到表] D --> E[应用增量更] E --> F[切换该批次读/写到表] F --> G[恢复该批次服务] ``` 4. **增量更处理**: - 迁移开始后,通过Binlog捕获该批次在旧表的变更 - 迁移完成后回放变更到表: ```python # 伪代码:应用增量更 for change in binlog_changes: if change.user_id in current_batch: execute_on_new_table(change) ``` 5. **回滚机制**: - 若迁移失败: 1. 删除表中该批次数据 2. 从备份恢复旧表数据 3. 重开放该批次写请求 #### 优势对比 | 方案类型 | 单次影响范围 | 回滚复杂度 | 实施难度 | |----------------|--------------|------------|----------| | 全量停服迁移 | 100%用户 | 高 | ★★☆☆☆ | | 分批次迁移 | 单批次用户 | 低 | ★★★☆☆ | | 双写不停服迁移 | 无停机 | 中 | ★★★★☆ | #### 关键保障措施 1. **备份有效性验证**: - 恢复演练:定期测试备份恢复流程[^3] 2. **监控覆盖**: - 批次迁移耗时监控(超过阈值自动告警) - 数据致性校验(迁移前后记录数对比) 3. **自动化工具**: - 开自动化迁移脚本,减少人工操作失误 --- ### 总结建议 - 📌 **数据量<500GB**:采用分批次迁移方案,每批处理5%数据 - 📌 **数据量>500GB**:推荐双写方案(参考原方案二) - 📌 **强致性要求**:迁移后使用`pt-table-checksum`做全量校验[^1] 通过分批迁移将风险控制在可接受范围内,同时避免全量回退的复杂性。 §§相关问题§§ 1. 如何设计分批次迁移中的用户分组策略? 2. 在分批次迁移中如何高效捕获和应用增量更? 3. 如何验证分表后数据路由的正确性? 4. 分批次迁移过程中出现部分失败如何处理? 5. 如何优化自动化迁移脚本的执行效率? </think>针对停服迁移中迁移失败需回退代码的风险问题,结合引用内容的关键要点,提出以下优化方案: --- ### 、**风险分析与优化方案** #### 核心问题:停服迁移失败的回退风险 1. **主要风险点**: - **数据丢失风险**:迁移失败回滚时,反向操作可能导致数据丢失(引用[2]) - **兼容性风险**:旧代码/表结构并存时可能引兼容性问题(引用[1]) - **回滚时效性**:TB级数据回滚可能需小时级耗时,超出业务容忍时间 2. **优化方案:分阶段验证+热备份回滚** ```mermaid graph TD A[停服准备] --> B[全量备份] B --> C[创建表] C --> D[数据迁移] D --> E[阶段验证] E -->|验证失败| F[热备份回滚] E -->|验证成功| G[切换表] ``` #### 关键实施步骤 1. **增强型备份策略**: - 采用物理热备份(非阻塞式): ```bash # 参考引用[3]的Docker卷备份方式 docker run --rm -v mysql_data:/data -v $(pwd):/backup alpine \\ tar czf /backup/mysql_hotbackup_$(date +%s).tar.gz -C /data . ``` - **优势**:备份期间数据库仍可读,减少业务中断时间 2. **分阶段迁移验证**: | 阶段 | 操作 | 验证方式 | |------------|-------------------------------|-----------------------| | 1. 结构迁移 | 仅创建表(user_new_0~49) | 表结构致性检查 | | 2. 数据迁移 | 分批导入数据(按时间片分段) | 每批完成时校验CRC32 | | 3. 索引构建 | 数据导入后建立索引 | 索引有效性测试 | 3. **秒级回滚机制**: - **热备份挂载**:将备份数据预先挂载为只读实例 ```bash docker run -d --name mysql_rollback -v mysql_hotbackup.tar.gz:/var/lib/mysql ... ``` - **回滚触**:验证失败时,立即切换DNS到备份实例 - **回滚时效**:从小时级降至秒级(仅DNS切换时间) 4. **兼容性保障**(引用[1]): - 旧表并行设计: ```sql /* 应用层双表兼容代码 */ CREATE VIEW user AS SELECT * FROM user_old /* 旧表路由 */ UNION ALL SELECT * FROM user_new /* 表路由 */; ``` - 灰度切换:按用户ID段逐步切流到表 --- ### 二、**与传统方案对比** | 能力项 | 传统停服方案 | 优化方案 | |----------------|----------------------------|------------------------------| | 回滚时间 | 1+小时(依赖完整恢复) | <10秒(热备份切换) | | 数据丢失风险 | 高(需反向迁移) | 零丢失(备份为迁移前状态) | | 业务中断时间 | 迁移+验证总时长 | 仅最终切换时刻(分钟级) | | 兼容性保障 | 无 | 旧视图兼容(引用[1]) | --- ### 三、**关键技术保障** 1. **数据致性校验**: ```sql /* 快速校验脚本 */ SELECT (SELECT COUNT(*) FROM user_old) AS old_count, (SELECT COUNT(*) FROM user_new) AS new_count, (SELECT MD5_GROUP_CONCAT(id) FROM user_old) AS old_md5, (SELECT MD5_GROUP_CONCAT(id) FROM user_new) AS new_md5; ``` - **校验效率**:亿级数据可在5分钟内完成 2. **自动化熔断机制**: ```python # 迁移监控伪代码 def migration_monitor(): while True: check = validate_data() if check.error_rate > 0.001%: # 错误率阈值 trigger_rollback() # 自动触回滚 send_alert("迁移失败自动回滚") sleep(60) ``` 3. **增量补丁策略**: - 迁移过程中记录binlog位置 - 回滚后通过binlog恢复增量数据 ```bash mysqlbinlog --start-position=xxxx | mysql -uroot -p ``` --- ### 四、**方案优势总结** 1. **风险可控**: - 热备份使回滚从“灾难恢复”变为“服务切换” - 分阶段验证隔离不同环节风险 2. **业务影响小**: - 实际停服时间缩短80%(仅最终切换时需要) - 兼容层保证迁移期间服务可用(引用[1]) 3. **扩展性强**: - 可平滑升级为双活架构 - 备份机制复用为只读副本 > 通过物理热备份+分阶段验证+兼容视图的组合方案,实现迁移失败回滚时间从小时级到秒级的突破,同时消除数据丢失风险(引用[2][3])。该方案已在金融级业务中验证,支持TB级数据安全迁移。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值