☰

企业官网建设流程全解析

首页 / 建站日记 / 企业官网建设流程全解析
OceanBase学习
2026/4/25 10:24:18 网站建设 项目流程

OceanBase（OB）是蚂蚁集团完全自研的原生分布式关系型数据库，2010年诞生，支撑支付宝/双11核心交易，金融级高可用，同时兼容 MySQL 与 Oracle 两种模式，是国产分布式数据库的标杆。

一、核心定位（一句话懂差异）

  • Oracle：集中式商用数据库，闭源，高端硬件，强事务，金融传统核心。
  • 达梦DM8：集中式（可选共享存储集群），Oracle 高度兼容，政务/国企信创首选。
  • OceanBase：原生分布式，MySQL/Oracle 双兼容，普通x86服务器，水平扩展，金融互联网核心/海量数据。

二、架构与核心特性（重点）

1. 原生分布式（和达梦/Oracle 最大区别）
  • 无共享（Shared-Nothing）：数据打散到多节点，无需分库分表中间件，应用透明。
  • Paxos 多副本强一致：默认3副本，自动选主，故障秒级切换，数据零丢失。
  • 三地五中心容灾：城市级故障无损恢复，金融级高可用。
  • 水平扩展：加机器即加算力，单集群可超1500节点。
2. 双兼容模式（MySQL + Oracle）
  • MySQL 模式：完全兼容 MySQL 5.7/8.0 协议与语法，迁移成本极低。
  • Oracle 模式：高度兼容 Oracle 11g/12c，支持 PL/SQL、存储过程、序列、rownum 分页、函数等，达梦有的 Oracle 兼容 OB 基本都有，且分布式能力更强。
3. 性能与存储
  • TPC-C 世界纪录：7.07亿 tpmC，远超传统集中式库。
  • LSM-Tree 存储引擎：高压缩比（5:1~10:1），存储成本低，读写性能优。
  • HTAP 混合负载：一套引擎同时跑交易（OLTP）+ 分析（OLAP）。
4. 多租户（云原生）
  • 单集群划多个租户，资源隔离，天然支持 DBaaS，适合政务云/金融云。

三、OceanBase vs 达梦 DM8（信创选型关键）

1. 架构
  • 达梦：集中式（单节点/共享存储集群DMDSC），类似 Oracle RAC。
  • OceanBase：原生分布式（无共享），水平扩展，数据量/并发远超达梦。
2. 兼容性
  • 达梦：Oracle 兼容度更高（约95%），PL/SQL、存储过程、触发器几乎无缝迁移，政务Oracle迁移首选。
  • OceanBase：Oracle 兼容度约85%~90%，核心SQL/函数/对象兼容，复杂包/高级PL/SQL需微调；同时支持MySQL模式，双生态更灵活。
3. 适用场景
  • 达梦：政务、国企、能源、军工，中小规模核心系统（≤10TB），Oracle迁移，信创合规优先。
  • OceanBase：银行/保险核心、互联网高并发、海量数据（≥10TB）、异地多活/城市级容灾、MySQL/Oracle混合迁移。
4. 生态与成本
  • 达梦：国产CPU（飞腾/龙芯）+ 麒麟OS 适配深，政务工具链完善，** license+服务成本适中**。
  • OceanBase：x86/鲲鹏为主，社区版免费，企业版按集群授权，硬件成本低（普通x86），金融/互联网生态强。

四、OceanBase vs Oracle（迁移要点）

相同点
  • 完全 ACID，强事务，高可用。
  • 支持复杂SQL、存储过程、函数、触发器、视图、序列。
  • 支持行级锁、事务隔离级别、物化视图。
不同点（迁移必改）
  1. 架构：Oracle 集中式/共享存储RAC；OB 分布式无共享，应用无需改分库分表。
  2. 语法差异（高频）
    • Oracle：wm_concat→ OB：listagg（同达梦）。
    • Oracle：dbms_job→ OB：用内置定时或业务层Quartz。
    • Oracle：connect by层级查询 → OB：支持但需微调。
  3. 驱动与连接串
    • Oracle：ojdbc，jdbc:oracle:thin:@ip:1521:orcl。
    • OB：oceanbase-jdbc，jdbc:oceanbase://ip:2881/库名（Oracle模式）。
  4. 高级特性：Oracle 独有dbms_java、部分高级dbms_*包、RAC 专属管理视图 → OB 需替换或用业务代码实现。

五、信创组合建议（直接抄）

1. 金融核心（高可用+分布式）
  • CPU：海光 C86 / 鲲鹏 920
  • OS：欧拉 openEuler / 麒麟 V11
  • 数据库：OceanBase 企业版（Oracle模式）
  • 中间件：宝兰德 BES / 东方通 TongWeb
2. 政务大规模数据（Oracle迁移+分布式）
  • CPU：飞腾 FT-2000+
  • OS：银河麒麟 V10
  • 数据库：OceanBase（Oracle模式）或 达梦 DM8（中小数据）
  • 中间件：东方通 TongWeb

六、总结

  • 达梦：Oracle 最佳集中式平替，政务信创首选，中小规模、Oracle 语法无缝迁移。
  • OceanBase：原生分布式+双兼容，金融级高可用，海量数据/高并发/异地容灾首选，MySQL/Oracle 混合场景迁移成本低。

下面我用最直白、一步到位的方式讲清楚：OceanBase 怎么装、怎么连、怎么建库建表、怎么用 Oracle/MySQL 模式、常用命令和迁移要点。你照着做就能跑通。

一、核心概念（先懂再用）

  • OceanBase（OB）：蚂蚁集团自研原生分布式数据库，支持MySQL 模式 + Oracle 模式。
  • 端口：默认2881（数据库）、2882（内部通信）。
  • 租户：OB 是多租户架构，sys 租户=管理集群，业务要建独立租户（如 tenant1）。
  • 模式：
    • MySQL 模式：兼容 MySQL 5.7/8.0，语法基本一样。
    • Oracle 模式：高度兼容 Oracle 11g/12c，支持 PL/SQL、存储过程、序列、rownum 等。

二、快速安装（3种方式，选一种）

方式1：Docker 1分钟体验（推荐新手）

# 拉镜像并启动（mini模式，资源占用小）dockerrun-p2881:2881--nameob-eMODE=MINI-eOB_TENANT_PASSWORD=123456-dquay.io/oceanbase/oceanbase-ce# 连接（密码123456）mysql-h127.0.0.1-P2881-uroot@sys-p123456

方式2：OBD 单机部署（官方工具，生产/测试都可用）

# 1. 安装 OBD（CentOS）sudoyuminstall-yyum-utilssudoyum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.reposudoyuminstall-yob-deploy# 2. 一键部署 demo（3节点集群，本地模拟）obd demo# 3. 连接obclient -uroot@sys-h127.0.0.1-P2881-p

方式3：物理机/服务器生产部署

  • 系统：CentOS 7.9+/Ubuntu 20.04+
  • 最低配置：2核4G + 20G SSD
  • 关闭防火墙/SELinux，配置 NTP 时钟同步
  • 用 OBD 或 图形化界面部署（参考官方文档）

三、连接数据库（2种客户端）

1）用 MySQL 客户端（最方便）

# 连接 sys 租户（管理）mysql-h127.0.0.1-P2881-uroot@sys-p# 连接业务租户（如 tenant1）mysql-h127.0.0.1-P2881-uroot@tenant1-p

2）用 OB 专用客户端 obclient

obclient -uroot@sys-h127.0.0.1-P2881-p

连接成功提示符：

Welcome to the OceanBase. Commands end with ; or \g. mysql>

四、基础操作（建租户→建库→建表→读写）

1）创建业务租户（关键！不能用 sys 跑业务）

-- 登录 sys 租户执行CREATETENANTIFNOTEXISTStenant1 PRIMARY_ZONE='zone1'REPLICA_NUM=3CHARSET=utf8mb4COLLATE=utf8mb4_unicode_ci;-- 设置租户密码（Oracle/MySQL 模式通用）ALTERUSERroot@tenant1IDENTIFIEDBY'123456';

2）切换到租户，创建数据库

-- 连接 tenant1 后CREATEDATABASEtestdb;USEtestdb;

3）建表（MySQL 模式）

CREATETABLEuser(idINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(50)NOTNULL,ageINT);INSERTINTOuser(name,age)VALUES('张三',20);SELECT*FROMuser;

4）Oracle 模式使用（重点）

-- 1. 租户设置为 Oracle 模式（sys 租户执行）ALTERTENANT tenant1SETob_compatibility_mode=oracle;-- 2. 连接 tenant1，语法和 Oracle 几乎一样CREATETABLEemp(empno NUMBER(4)PRIMARYKEY,ename VARCHAR2(10),sal NUMBER(7,2));INSERTINTOempVALUES(1,'李四',5000);SELECT*FROMempWHERErownum<=1;-- Oracle 分页

五、常用管理命令（必记）

集群状态

SELECT*FROMoceanbase.__all_server;-- 查看节点SELECT*FROMoceanbase.__all_tenant;-- 查看租户

租户管理

ALTERTENANT tenant1SETob_compatibility_mode=mysql;-- 切回MySQL模式DROPTENANT tenant1;-- 删除租户

用户权限

CREATEUSERappuser@tenant1IDENTIFIEDBY'123456';GRANTALLONtestdb.*TOappuser@tenant1;

六、应用连接（Java/Go/Python）

Java（JDBC）

# MySQL 模式 url=jdbc:mysql://127.0.0.1:2881/testdb?useSSL=false driver=com.mysql.cj.jdbc.Driver # Oracle 模式 url=jdbc:oceanbase://127.0.0.1:2881/testdb?useSSL=false driver=com.oceanbase.jdbc.Driver

Python

importmysql.connector conn=mysql.connector.connect(host='127.0.0.1',port=2881,user='root@tenant1',password='123456',database='testdb')

七、Oracle 迁移 OB 要点（高频差异）

  1. 驱动：ojdbc → oceanbase-jdbc（Oracle模式）
  2. 语法兼容：
    • wm_concat→listagg
    • connect by→ 支持但需微调
    • dbms_job→ 用内置定时或业务层Quartz
  3. 对象迁移：表、视图、存储过程、函数、序列大部分直接可用，复杂包需少量修改。

八、什么时候用 OB？

  • ✅ 替代 Oracle（金融/政务核心，分布式+双兼容）
  • ✅ MySQL 业务数据超10TB/高并发，不想分库分表
  • ✅ 需要异地多活/三地五中心容灾
  • ✅ 信创国产化（适配海光/鲲鹏/麒麟OS）

OceanBase 怎么处理「分库分表」？

核心一句话：
OceanBase 原生内置分布式分片，业务层完全不需要 MyCat、Sharding-JDBC 做分库分表，天然自动分片。

一、传统 MySQL 痛点（你原来的做法）

MySQL 单机容量/性能上限低，海量数据必须：

  • 中间件：Sharding-JDBC、MyCat、ShardingSphere
  • 手动：水平分表、垂直分库、按月分表
  • 痛点：代码侵入、改造大、跨库联表、分布式事务坑多

二、OceanBase 核心：原生分布式、自动分片

OB 架构：

  • 集群多节点
  • 数据按分区键自动打散到不同节点
  • 上层业务单库单表写法，不用改分片代码

关键概念

  1. 分区（Partition）
    OB 底层把一张大表自动拆成很多小分区，分散在不同服务器。
  2. 副本
    默认3副本，高可用、故障自动转移。
  3. 分区方式（就是分库分表的替代品）

三、OceanBase 三种分片方式（对标分库分表）

1. 哈希分区 → 对标【水平分表/用户ID分片】

最常用，替代user_id % 16这种分片

-- Oracle 模式 / MySQL 模式通用CREATETABLEorder_info(order_id NUMBER,user_id NUMBER,create_timeDATE)PARTITIONBYHASH(user_id)PARTITIONS32;-- 拆32个分区，均匀打散多节点

效果：

  • 相同 user_id 落在同一个分区
  • 多节点并行写入，解决大并发
  • 业务select * from order_info where user_id=1001自动路由到对应节点

2. 范围分区 → 对标【按时间分表、按月分表】

完美替代 每月一张表、历史归档

CREATETABLEorder_info(order_id NUMBER,create_timeDATE)PARTITIONBYRANGE(create_time)(PARTITIONp202601VALUESLESS THAN(TO_DATE('2026-02-01','YYYY-MM-DD')),PARTITIONp202602VALUESLESS THAN(TO_DATE('2026-03-01')),PARTITIONpmaxVALUESLESS THAN(MAXVALUE));

优势：

  • 删历史数据：直接drop partition秒级删除
  • 按时间查询只扫描对应分区，性能极高

3. 列表分区 → 对标【按地区/渠道分片】

按城市、渠道、业务线打散数据

四、对比：Sharding-JDBC vs OceanBase

项目传统MySQL+ShardingOceanBase 原生
分片代码侵入业务、需改代码零代码、单表写法
跨分区join极难、坑多原生支持分布式Join
分布式事务弱一致、容易出问题全局强一致
扩容需手动迁移分片加机器自动均衡数据
运维复杂、分片规则难维护库内统一管理

五、OB 特殊能力：全局索引

普通分库分表：
跨分片字段查询非常慢（比如按手机号查订单）

OceanBase 支持：

  • 本地索引（分区内）
  • 全局索引（跨分区全局查询）
    不用冗余、不用中间件，原生解决。

六、什么时候完全抛弃分库分表？

只要你用 OceanBase：

  1. 单表数据亿级、十亿级不用分表
  2. 高并发订单、流水、日志表 直接单表跑
  3. 定时按月分表、归档 用「范围分区」替代
  4. 用户维度海量数据 用「哈希分区」

七、极简总结

  1. OceanBase 自带分库分表能力，不需要 Sharding 中间件
  2. 底层通过哈希/范围/列表分区自动拆分数据
  3. 业务层还是单库单表写法，无侵入
  4. 分布式事务、跨节点查询、扩容迁移全部数据库层搞定
  5. 是替代 MySQL 分库分表架构的国产分布式数据库最优解

OceanBase 分库分表（分区）+ 跨分区查询 完整实操

先定核心结论：
OB 不用 Sharding-JDBC/MyCat 中间件
底层靠「分区 = 原生分表」实现，业务还是单表SQL，自动路由、跨分区直接查。

一、OB 里的「分库分表」对应关系

  • 传统MySQL：
    分库 + 分表 + 分片中间件
  • OceanBase：
    租户=大库→Database=业务库→表分区=自动分表
    ✅ 只需要做表分区，就是原生分库分表

三种主流分区（对应业务场景）

  1. HASH分区：用户ID、商户ID → 水平分片
  2. RANGE范围分区：时间、月份 → 按月/按天分表
  3. LIST列表分区：地区、渠道、业务线

二、场景1：HASH分片（用户ID分表）+ 查询

1.建表（按user_id哈希分片，等效分成32张子表）

-- Oracle模式 语法CREATETABLEtb_order(order_id NUMBER,user_id NUMBER,amount NUMBER(10,2),create_timeDATE)-- 按user_id哈希分片PARTITIONBYHASH(user_id)PARTITIONS32;

2.单分区精准查询（自动路由，只查单个分片）

-- 条件带分区键 user_id，OB自动定位到对应分区，性能最高SELECT*FROMtb_orderWHEREuser_id=10086;

3.跨分区批量查询（直接写SQL，不用改）

-- 跨多个哈希分区，OB底层自动聚合SELECT*FROMtb_orderWHEREuser_idIN(10086,10087,10088);

三、场景2：RANGE时间分片（按月分表）+ 查询

最常用：订单、日志、流水按月分表

1.建表按月分区

CREATETABLEtb_order(order_id NUMBER,user_id NUMBER,create_timeDATE)PARTITIONBYRANGE(create_time)(PARTITIONp202601VALUESLESS THAN(TO_DATE('2026-02-01','YYYY-MM-DD')),PARTITIONp202602VALUESLESS THAN(TO_DATE('2026-03-01','YYYY-MM-DD')),PARTITIONp202603VALUESLESS THAN(TO_DATE('2026-04-01','YYYY-MM-DD')),PARTITIONp_maxVALUESLESS THAN(MAXVALUE));

2.查单个月（只扫描一个分区，极快）

SELECT*FROMtb_orderWHEREcreate_time>=TO_DATE('2026-03-01','YYYY-MM-DD')ANDcreate_time<TO_DATE('2026-04-01','YYYY-MM-DD');

3.跨月份查询（自动跨分区合并结果）

-- 跨2、3月，业务SQL完全不变SELECT*FROMtb_orderWHEREcreate_time>=TO_DATE('2026-02-01','YYYY-MM-DD');

4.直接指定分区查询（运维/统计用）

-- 强制只查202603分区SELECT*FROMtb_orderPARTITION(p202603);

四、关键：非分区键查询怎么办？

比如：

  • 按order_id、手机号、订单号 查询（不是分区键）

两种方案

  1. 本地索引
    会扫描全部分区，数据量大较慢
  2. OB全局索引（推荐）
    给非分区键建全局索引，跨分区也能秒查
-- 建立全局索引，非分区键快速查询CREATEGLOBALINDEXidx_order_idONtb_order(order_id);

建好后：

-- 非分区键，依然高性能SELECT*FROMtb_orderWHEREorder_id=9999;

五、跨分区 JOIN、聚合（原生支持）

1.跨分片联表查询

SELECTa.*,b.nameFROMtb_order aLEFTJOINtb_user bONa.user_id=b.user_idWHEREa.create_time>=SYSDATE-3;

✅ 不用中间件、不用手动关联子表，OB 自动跨节点计算

2.跨分区分组/统计

SELECTuser_id,COUNT(*)FROMtb_orderWHEREcreate_time>=SYSDATE-7GROUPBYuser_id;

六、和Sharding-JDBC 最大区别

操作Sharding+MySQLOceanBase
分片规则代码/配置文件写死数据库建表时定义
单表查询路由复杂自动路由
跨分片查询坑多、限制多原生支持
跨库Join基本不推荐原生支持
扩容手动迁移数据加节点自动均衡
业务代码大量改造零改造，单表写法

七、开发使用规范（必记）

  1. 核心大表必须指定分区（HASH/RANGE）
  2. 查询尽量带上分区键，走分区裁剪，性能最高
  3. 非分区键高频查询，建立全局索引
  4. 禁止无脑select * 不带条件，会扫描全部分区
  5. 历史数据清理：ALTER TABLE xxx DROP PARTITION 分区名秒级删除

八、一句话总结

  1. OB 的分区 = 替代传统分库分表
  2. 业务永远写单表SQL，不需要感知分片
  3. 带分区键：精准单分区查询
  4. 不带分区键：自动跨分区聚合
  5. 非分区键慢查询 → 加全局索引解决

OceanBase 分布式事务 完整原理+实操（分库分表场景）

先给核心结论：

  1. OceanBase 不需要 Sharding-JDBC、不需要Seata
  2. 底层原生支持分布式事务、跨分区事务、跨节点事务
  3. 基于两阶段提交+Paxos强一致，默认ACID，数据不丢、不脏写
  4. 你眼里的「分库分表」，在OB里就是分区，跨分区=天然分布式事务

一、先搞懂：OB 哪些场景会触发分布式事务

OB 一张大表拆成几十个分区，分散在不同机器：

  1. 同一张表、跨分区修改（比如user_id=1 和 user_id=100 在不同分区）
  2. 多张表、不同分区/不同节点同时增删改
  3. 跨租户、跨库操作
    以上全部自动进入OB 分布式事务

👉 传统MySQL+Sharding：
需要手动引入Seata/TCC/XA，代码埋点、补偿、回滚特别麻烦。

👉 OceanBase：
完全无感，业务代码还是普通begin/commit/rollback。

二、OB 分布式事务底层机制（极简大白话）

1. 核心协议

  • 采用自研2PC（两阶段提交）+ Paxos 多副本
  • 全局事务号、全局快照、分布式MVCC

2. 两阶段流程

  1. 阶段1 Prepare
    所有涉及的分区/节点 预提交、锁资源、日志落地
  2. 阶段2 Commit/Rollback
    • 全部Prepare成功 → 统一提交
    • 任意一个失败 → 全体自动回滚

3. 隔离级别

支持：

  • Read Committed
  • Repeatable Read（默认）
    完全满足金融、政务核心业务。

三、三种「分库分表」事务场景 实操演示

下面语法Oracle/MySQL模式通用，直接能用

场景1：同一张表 跨分区事务（最常见）

订单表按 user_id HASH分区，两个用户在不同分片：

-- 开启事务BEGIN;-- 操作分区AUPDATEtb_orderSETamount=100WHEREuser_id=1001;-- 操作分区B（跨分区，自动触发分布式事务）UPDATEtb_orderSETamount=200WHEREuser_id=2002;-- 统一提交COMMIT;
  • 两条SQL落在不同节点
  • OB自动2PC，要么全部成功，要么全部回滚
  • 业务代码零改动

场景2：两张不同大表 跨表事务

订单表 + 账户表，都是分区表、分散节点：

BEGIN;-- 扣余额UPDATEtb_accountSETbalance=balance-100WHEREuser_id=1001;-- 生成订单INSERTINTOtb_order(...)VALUES(...);COMMIT;

✅ 跨表+跨节点，原生分布式事务保证原子性

场景3：异常自动回滚

BEGIN;UPDATEtb_accountSETbalance=balance-100WHEREuser_id=1001;-- 故意写一条报错SQLINSERTINTOtb_orderVALUES(null);COMMIT;

👉 报错后：
OB 自动触发全局回滚，上一步扣钱全部撤销，不会超卖、不会脏数据。

四、对比：Sharding-JDBC + Seata VS OceanBase

能力MySQL+Sharding+SeataOceanBase 原生
跨分片事务弱一致、TCC硬编码、补偿复杂强一致、原生2PC
代码侵入高、需注解、undo日志0侵入，原生SQL
事务成功率依赖框架+人工编码数据库内核保障
性能损耗高优化版2PC，损耗极低
死锁/锁超时问题多分布式锁机制成熟
适配分表中间件配置分片规则建表分区即可

五、OceanBase 分布式事务 开发规范（避坑）

1. 最佳实践（性能最好）

  • 同一业务尽量分区键一致
  • 比如：订单、账单、流水 都用user_id作为分区键
  • 同用户操作落在同一个分区，走本地事务，性能最高

2. 避免大跨度分布式事务

  • 不要在一个事务里操作几十上百个分区
  • 批量拆分、控制事务粒度

3. 锁与超时

OB 自带：

  • 分布式行锁
  • 事务超时自动回滚参数
# 可调整事务超时时间 ob_trx_timeout = 600000

4. 不推荐

不用手写XA、不用TCC、不用本地消息表，完全没必要。

六、极端故障场景（生产放心）

  1. 提交中某节点宕机
    剩余节点等待恢复后，自动补齐提交/回滚，数据一致
  2. 机房断电、网络分裂
    Paxos多数派机制，保证数据不分裂、不脏写
  3. 长期未提交事务
    自动超时回滚，避免死锁和资源堆积

七、一句话终极总结

  1. OceanBase 的分区 = 替代传统分库分表
  2. 跨分区、跨节点、跨表 修改，自动走原生分布式事务
  3. 不需要 Sharding、不需要 Seata、不需要TCC、不需要补偿
  4. 业务只需要正常写begin / commit / rollback
  5. 金融级强一致，是国产分布式里事务最强的数据库之一
标签： 网站建设 企业官网 项目流程 UI设计 前端开发

热门文章

文章分类

标签云

网站建设 响应式设计 用户体验 SEO优化 前端开发 小程序 电商平台 性能优化

相关文章

您可能感兴趣的其他内容

Diablo Edit2：如何让暗黑破坏神2的角色养成不再成为你的时间负担？
2026/4/25 10:22:52 网站建设

Diablo Edit2：如何让暗黑破坏神2的角色养成不再成为你的时间负担？

Diablo Edit2&#xff1a;如何让暗黑破坏神2的角色养成不再成为你的时间负担&#xff1f; 【免费下载链接】diablo_edit Diablo II Character editor. 项目地址: https://gitcode.com/gh_mirrors/di/diablo_edit 你是否曾经在暗黑破坏神2中为刷不到理想的装备而沮丧&…...

阅读更多 →
茉莉花插件：让Zotero中文文献管理变得简单高效
2026/4/25 10:22:19 网站建设

茉莉花插件：让Zotero中文文献管理变得简单高效

茉莉花插件&#xff1a;让Zotero中文文献管理变得简单高效 【免费下载链接】jasminum A Zotero add-on to retrive CNKI meta data. 一个简单的Zotero 插件&#xff0c;用于识别中文元数据 项目地址: https://gitcode.com/gh_mirrors/ja/jasminum 如果你在学术研究中经常…...

阅读更多 →
Qwen3.5-2B实战案例：本地部署实现竞品App界面截图→功能逆向分析
2026/4/25 10:19:20 网站建设

Qwen3.5-2B实战案例：本地部署实现竞品App界面截图→功能逆向分析

Qwen3.5-2B实战案例&#xff1a;本地部署实现竞品App界面截图→功能逆向分析 1. 项目概述 Qwen3.5-2B是一款20亿参数规模的轻量级多模态大语言模型&#xff0c;特别适合在本地环境中部署运行。相比大型模型&#xff0c;它在保持良好性能的同时&#xff0c;对硬件资源要求更低…...

阅读更多 →

需要专业的网站建设服务？

联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标

立即咨询