当前位置： 首页 > backend >正文

【6.1.0 漫画数据库技术选型】

backend 2025/7/13 6:28:10

漫画数据库技术选型

🎯 学习目标：掌握架构师核心技能——数据库技术选型，针对不同业务场景选择最合适的数据库方案

🏛️ 第一章：关系型数据库对比选型

🤔 MySQL vs PostgreSQL vs TiDB

想象数据库就像不同类型的仓库…

🏪 数据库仓库对比：MySQL (传统超市)：
┌─────────────────┐
│ 🛒 简单易用     │ ← 上手简单，生态丰富
│ 💰 成本低廉     │ ← 开源免费，运维成本低
│ 🚀 读性能优秀   │ ← InnoDB引擎优化好
│ ⚠️ 写入瓶颈     │ ← 单机写入有限制
└─────────────────┘PostgreSQL (精品百货)：
┌─────────────────┐
│ 🎯 功能丰富     │ ← 支持JSON、全文搜索
│ 🔒 ACID强保证   │ ← 事务支持最完善  
│ 📊 复杂查询强   │ ← 支持窗口函数、CTE
│ 🐌 学习成本高   │ ← 配置相对复杂
└─────────────────┘TiDB (现代mall)：
┌─────────────────┐
│ 🌐 分布式架构   │ ← 天然支持水平扩展
│ ⚖️ 强一致性     │ ← 分布式事务ACID
│ 🔧 MySQL兼容    │ ← 无缝迁移MySQL
│ 💸 成本较高     │ ← 需要多节点部署
└─────────────────┘

📊 关系型数据库详细对比

📊 三大关系型数据库技术对比：┌─────────────┬─────────────┬─────────────┬─────────────┐
│    特性     │    MySQL    │ PostgreSQL  │    TiDB     │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ 🏗️ 架构模式 │   单机主从   │   单机主从   │  分布式集群  │
│ 📈 扩展能力 │   垂直扩展   │   垂直扩展   │  水平扩展    │
│ 💾 存储引擎 │InnoDB/MyISAM│   单一引擎   │   TiKV      │
│ 🔒 事务支持 │   ACID      │  完整ACID   │ 分布式ACID   │
│ 📊 复杂查询 │    一般      │     强      │     强      │
│ 🌐 分布式   │     否      │     否      │     是      │
│ 💰 使用成本 │     低      │    中等     │     高      │
│ 🛠️ 运维难度 │     低      │    中等     │     高      │
│ 📚 生态支持 │    最丰富    │    丰富     │   发展中    │
│ 🎯 适用场景 │  中小型应用  │ 复杂业务系统 │ 大型分布式  │
└─────────────┴─────────────┴─────────────┴─────────────┘性能对比 (相对值)：
MySQL     ████████████████████  (单机读写性能)
PostgreSQL ███████████████       (复杂查询性能)  
TiDB      █████████████████████  (分布式性能)学习成本：
MySQL     ████                  (最容易上手)
PostgreSQL ███████               (中等学习成本)
TiDB      ██████████            (需要分布式知识)

🎯 关系型数据库选型决策树

🎯 关系型数据库选型流程：开始选型│┌────▼────┐│数据量大小│└────┬────┘│┌──────────────┼──────────────┐▼              ▼              ▼数据量<100GB    100GB-1TB     数据量>1TB│              │              │┌────▼────┐    ┌────▼────┐    ┌────▼────┐│ 业务复杂度│    │ 扩展需求 │    │ 必须分布式│└────┬────┘    └────┬────┘    └────┬────┘│              │              │┌────▼────┐    ┌────▼────┐         ▼│简单CRUD │    │需要扩展  │      TiDB└────┬────┘    └────┬────┘      (大数据量)│              │▼              ▼MySQL        PostgreSQL(高性价比)      (复杂业务)选型建议：
🎯 初创公司/MVP项目 → MySQL
🎯 企业级应用/复杂业务 → PostgreSQL  
🎯 大型互联网/金融级 → TiDB
🎯 需要强GIS支持 → PostgreSQL
🎯 需要分布式事务 → TiDB

📦 第二章：NoSQL数据库选型

🍃 MongoDB vs Redis vs HBase

🍃 NoSQL数据库仓库对比：MongoDB (文档仓库)：
┌─────────────────┐
│ 📄 文档存储     │ ← JSON格式，schema灵活
│ 🔍 查询丰富     │ ← 支持复杂查询和索引
│ 🌐 分片集群     │ ← 内置分片支持
│ 🎯 适合内容管理 │ ← CMS、用户画像
└─────────────────┘Redis (高速缓存)：
┌─────────────────┐
│ ⚡ 极速响应     │ ← 内存存储，μs级延迟
│ 🔧 数据结构丰富 │ ← String/Hash/Set/ZSet
│ 📊 支持计算     │ ← Lua脚本、Stream
│ 💾 持久化选项   │ ← RDB/AOF持久化
└─────────────────┘HBase (大数据仓库)：
┌─────────────────┐
│ 📈 海量数据     │ ← PB级数据存储
│ 📊 列式存储     │ ← 稀疏数据友好
│ 🔄 实时读写     │ ← 毫秒级随机访问
│ 🌐 Hadoop生态   │ ← 与大数据集成
└─────────────────┘

🔍 NoSQL数据库详细对比

🔍 NoSQL数据库技术对比：┌─────────────┬─────────────┬─────────────┬─────────────┐
│    特性     │  MongoDB    │    Redis    │   HBase     │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ 📊 数据模型 │   文档型     │   键值型     │   列族型    │
│ 🚀 查询语言 │  MongoDB QL │  命令接口    │   Java API  │
│ 🔍 查询能力 │    丰富      │    简单     │    简单     │
│ 📈 扩展模式 │   分片集群   │   集群模式   │  Region分割  │
│ 💾 存储介质 │   磁盘为主   │   内存为主   │   磁盘为主  │
│ ⚡ 访问速度 │    中等      │     快      │    中等     │
│ 📊 数据量   │     TB      │     GB      │     PB      │
│ 🔒 事务支持 │  4.0+支持   │    有限     │    行级     │
│ 🛠️ 运维复杂度│    中等      │     低      │     高      │
│ 🎯 主要场景 │ 内容管理/IoT │ 缓存/会话   │ 大数据/日志 │
└─────────────┴─────────────┴─────────────┴─────────────┘性能特点：
延迟对比 (毫秒级)：
Redis     ■           (0.1ms)
MongoDB   ███         (1-10ms)  
HBase     ████        (1-20ms)吞吐量对比：
Redis     ████████████████  (10万QPS+)
MongoDB   ████████          (1万QPS+)
HBase     ██████████████    (5万QPS+)

🎯 NoSQL选型决策矩阵

🎯 NoSQL数据库选型矩阵：使用场景 vs 数据库选择：📊 缓存场景：
┌─────────────────┐
│ 会话存储        │ → Redis (String)
│ 排行榜          │ → Redis (ZSet)  
│ 计数器          │ → Redis (Hash)
│ 分布式锁        │ → Redis (Set)
│ 消息队列        │ → Redis (Stream)
└─────────────────┘📄 文档场景：
┌─────────────────┐
│ 内容管理系统    │ → MongoDB
│ 用户画像        │ → MongoDB
│ 商品目录        │ → MongoDB  
│ 日志分析        │ → MongoDB (时序)
│ IoT数据存储     │ → MongoDB
└─────────────────┘📈 大数据场景：
┌─────────────────┐
│ 用户行为日志    │ → HBase
│ 时序数据存储    │ → HBase/InfluxDB
│ 搜索索引        │ → Elasticsearch
│ 图关系数据      │ → Neo4j
│ 地理位置数据    │ → PostGIS/MongoDB
└─────────────────┘

🏗️ 第三章：数据库架构模式选择

🔧 单体 vs 分库分表 vs 分布式

🔧 数据库架构演进路径：阶段1: 单体数据库 (0-100万用户)
┌─────────────────────────────────────┐
│              应用服务               │
│                 │                   │
│            ┌────▼────┐              │
│            │  MySQL  │              │
│            │ 单实例   │              │
│            └─────────┘              │
└─────────────────────────────────────┘
优点：简单，事务一致性
缺点：性能瓶颈，单点故障阶段2: 读写分离 (100万-500万用户)  
┌─────────────────────────────────────┐
│              应用服务               │
│            读     │    写           │
│        ┌───▼───┐  │  ┌───▼───┐      │
│        │ Slave │  │  │Master │      │
│        │(只读) │◄─┼──│(读写) │      │
│        └───────┘  │  └───────┘      │
│        └───────────┼─────────────────┘
│               主从同步              │
└─────────────────────────────────────┘
优点：读性能提升，高可用
缺点：写入仍是瓶颈阶段3: 分库分表 (500万-5000万用户)
┌─────────────────────────────────────┐
│             应用服务                │
│              分片路由               │
│    ┌─────────┬─────────┬─────────┐   │
│    ▼         ▼         ▼         │   │
│ ┌─────┐  ┌─────┐  ┌─────┐       │   │
│ │DB1  │  │DB2  │  │DB3  │       │   │
│ │分片1│  │分片2│  │分片3│       │   │
│ └─────┘  └─────┘  └─────┘       │   │
└─────────────────────────────────────┘
优点：线性扩展，性能提升
缺点：分布式事务复杂阶段4: 分布式数据库 (5000万+用户)
┌─────────────────────────────────────┐
│              应用服务               │
│                 │                   │
│            ┌────▼────┐              │
│            │  TiDB   │              │
│            │ 分布式   │              │
│            │ 集群     │              │
│            └─────────┘              │
└─────────────────────────────────────┘
优点：自动分片，强一致性
缺点：成本高，运维复杂

🎯 数据库架构选型策略

🎯 基于业务特征的架构选型：业务类型 vs 推荐架构：📱 初创MVP项目：
┌─────────────────┐
│ 单体MySQL       │ ← 快速上线，成本低
│ + Redis缓存     │ ← 提升性能
│ + 云数据库RDS   │ ← 减少运维
└─────────────────┘🛒 电商平台：
┌─────────────────┐
│ MySQL主库       │ ← 订单、支付核心
│ + 读写分离      │ ← 商品浏览优化
│ + MongoDB       │ ← 商品目录、评论
│ + Redis         │ ← 购物车、库存
│ + ES搜索        │ ← 商品搜索
└─────────────────┘🏦 金融系统：
┌─────────────────┐
│ TiDB分布式      │ ← 交易数据强一致
│ + PostgreSQL    │ ← 风控分析
│ + Redis集群     │ ← 实时计算
│ + InfluxDB      │ ← 监控时序数据
└─────────────────┘📊 大数据平台：
┌─────────────────┐
│ HBase          │ ← 海量日志存储
│ + ClickHouse    │ ← OLAP分析
│ + Redis         │ ← 实时指标
│ + MySQL         │ ← 元数据管理
└─────────────────┘

⚖️ 第四章：数据一致性与性能权衡

🔒 CAP理论实际应用

🔒 CAP理论在数据库选择中的应用：CAP三角形：Consistency (一致性)△╱ ╲╱   ╲╱     ╲╱   CP  ╲╱    区   ╲╱          ╲╱     MySQL  ╲╱   PostgreSQL ╲╱     TiDB      ╲╱                ╲
Availability ●────────● Partition Tolerance╱   AP区   ╲   (分区容错)╱  MongoDB   ╲╱   Redis     ╲╱   Cassandra  ╲不同业务场景的选择：💰 金融交易系统 (选择CP)：
- 强一致性要求 > 可用性
- 推荐：TiDB、PostgreSQL
- 宁可暂停服务也不能数据错误📱 社交媒体平台 (选择AP)：  
- 可用性 > 强一致性
- 推荐：MongoDB、Cassandra
- 允许短期数据不一致🛒 电商系统 (混合策略)：
- 订单系统：CP策略 (MySQL/TiDB)
- 商品浏览：AP策略 (MongoDB/Redis)
- 根据业务重要性分层选择

📊 性能vs一致性权衡矩阵

📊 数据库性能与一致性权衡：性能要求↑高性能│Redis      │   │   │ MemSQL(内存)      │   │   │ (内存分布式)│   │   │────────────────┼───┼───┼─────────────→│   │   │           一致性要求弱一致性       │   │   │         强一致性│   │   │MongoDB       │   │   │  PostgreSQL(最终一致)     │   │   │   (ACID)│   │   ││   │   │   TiDB│   │   │ (分布式ACID)│低性能选型建议：
🔴 高性能+弱一致性 → Redis/MongoDB
🟡 中等性能+强一致性 → MySQL/PostgreSQL  
🟢 低延迟+强一致性 → TiDB/CockroachDB
🔵 超高性能+无一致性要求 → 内存数据库

🎯 第五章：业务场景选型实战

🛒 电商系统数据库架构

// 🛒 电商系统数据库选型实战/*** 电商系统多数据库架构设计*/
@Configuration
public class ECommerceDataSourceConfig {// 1. 核心交易数据 - MySQL集群@Primary@Bean("primaryDataSource")public DataSource primaryDataSource() {// 主数据源：用户、订单、支付HikariConfig config = new HikariConfig();config.setJdbcUrl("jdbc:mysql://mysql-master:3306/ecommerce");config.setUsername("root");config.setPassword("password");config.setMaximumPoolSize(50);return new HikariDataSource(config);}// 2. 商品目录 - MongoDB@Beanpublic MongoTemplate mongoTemplate() {return new MongoTemplate(MongoClients.create("mongodb://mongodb-cluster:27017"), "products");}// 3. 缓存层 - Redis集群@Beanpublic RedisTemplate<String, Object> redisTemplate() {RedisTemplate<String, Object> template = new RedisTemplate<>();template.setConnectionFactory(jedisConnectionFactory());return template;}// 4. 搜索引擎 - Elasticsearch@Beanpublic ElasticsearchTemplate elasticsearchTemplate() {return new ElasticsearchTemplate(client());}
}/*** 不同业务模块的数据访问策略*/
@Service
public class ECommerceDataService {@Autowiredprivate JdbcTemplate jdbcTemplate;        // MySQL - 核心业务@Autowired  private MongoTemplate mongoTemplate;      // MongoDB - 商品目录@Autowiredprivate RedisTemplate redisTemplate;      // Redis - 缓存@Autowiredprivate ElasticsearchTemplate esTemplate; // ES - 搜索/*** 用户信息管理 - MySQL (强一致性)*/public User getUserById(Long userId) {// 先查缓存User user = (User) redisTemplate.opsForValue().get("user:" + userId);if (user != null) {return user;}// 缓存未命中，查询数据库user = jdbcTemplate.queryForObject("SELECT * FROM users WHERE id = ?", new Object[]{userId}, User.class);// 写入缓存，TTL 1小时redisTemplate.opsForValue().set("user:" + userId, user, 3600, TimeUnit.SECONDS);return user;}/*** 商品目录管理 - MongoDB (文档灵活性)*/public Product getProductDetail(String productId) {Query query = new Query(Criteria.where("id").is(productId));Product product = mongoTemplate.findOne(query, Product.class);// 商品浏览量计数 - RedisredisTemplate.opsForValue().increment("product:view:" + productId);return product;}/*** 商品搜索 - Elasticsearch (全文搜索)  */public List<Product> searchProducts(String keyword, int page, int size) {SearchQuery searchQuery = new NativeSearchQueryBuilder().withQuery(multiMatchQuery(keyword, "name", "description", "tags")).withPageable(PageRequest.of(page, size)).build();return esTemplate.queryForList(searchQuery, Product.class);}/*** 购物车管理 - Redis (快速读写)*/public void addToCart(Long userId, String productId, int quantity) {String cartKey = "cart:" + userId;redisTemplate.opsForHash().put(cartKey, productId, quantity);redisTemplate.expire(cartKey, 7, TimeUnit.DAYS); // 7天过期}/*** 订单创建 - MySQL事务 (ACID保证)*/@Transactionalpublic Order createOrder(Long userId, List<OrderItem> items) {// 1. 检查库存 - Redisfor (OrderItem item : items) {Long stock = redisTemplate.opsForValue().increment("stock:" + item.getProductId(), -item.getQuantity());if (stock < 0) {// 库存不足，回滚RedisredisTemplate.opsForValue().increment("stock:" + item.getProductId(), item.getQuantity());throw new InsufficientStockException();}}// 2. 创建订单 - MySQLOrder order = new Order(userId, items);jdbcTemplate.update("INSERT INTO orders (user_id, total_amount, status) VALUES (?, ?, ?)",order.getUserId(), order.getTotalAmount(), order.getStatus());// 3. 清空购物车 - RedisredisTemplate.delete("cart:" + userId);return order;}
}

🏦 金融系统数据库架构

// 🏦 金融系统数据库选型实战/*** 金融系统多数据库架构 - 强一致性优先*/
@Configuration
public class FinancialDataSourceConfig {// 1. 核心账务数据 - TiDB分布式数据库  @Primary@Bean("tidbDataSource")public DataSource tidbDataSource() {HikariConfig config = new HikariConfig();config.setJdbcUrl("jdbc:mysql://tidb-cluster:4000/financial");config.setDriverClassName("com.mysql.cj.jdbc.Driver");config.setMaximumPoolSize(100);config.setConnectionTimeout(30000);return new HikariDataSource(config);}// 2. 风控分析 - PostgreSQL (复杂查询)@Bean("postgresDataSource")  public DataSource postgresDataSource() {HikariConfig config = new HikariConfig();config.setJdbcUrl("jdbc:postgresql://postgres-master:5432/risk_control");config.setMaximumPoolSize(50);return new HikariDataSource(config);}// 3. 实时计算 - Redis集群@Beanpublic RedisClusterConfiguration redisClusterConfig() {RedisClusterConfiguration config = new RedisClusterConfiguration();config.setClusterNodes(Arrays.asList(new RedisNode("redis-1", 6379),new RedisNode("redis-2", 6379),new RedisNode("redis-3", 6379)));return config;}// 4. 时序监控数据 - InfluxDB@Beanpublic InfluxDB influxDB() {return InfluxDBFactory.connect("http://influxdb:8086", "admin", "password");}
}/*** 金融业务数据访问层*/
@Service
public class FinancialDataService {/*** 账户余额操作 - TiDB分布式事务*/@Transactionalpublic TransferResult transferMoney(String fromAccount, String toAccount, BigDecimal amount) {// 分布式事务保证ACID// 1. 检查源账户余额BigDecimal fromBalance = tidbTemplate.queryForObject("SELECT balance FROM accounts WHERE account_no = ? FOR UPDATE",BigDecimal.class, fromAccount);if (fromBalance.compareTo(amount) < 0) {throw new InsufficientBalanceException("余额不足");}// 2. 扣减源账户int fromUpdate = tidbTemplate.update("UPDATE accounts SET balance = balance - ?, updated_at = NOW() WHERE account_no = ?",amount, fromAccount);// 3. 增加目标账户  int toUpdate = tidbTemplate.update("UPDATE accounts SET balance = balance + ?, updated_at = NOW() WHERE account_no = ?",amount, toAccount);// 4. 记录交易流水tidbTemplate.update("INSERT INTO transactions (from_account, to_account, amount, type, status) VALUES (?, ?, ?, ?, ?)",fromAccount, toAccount, amount, "TRANSFER", "SUCCESS");// 5. 实时更新Redis计数器redisTemplate.opsForValue().increment("daily_transfer_count:" + fromAccount);return new TransferResult(true, "转账成功");}/*** 风控分析 - PostgreSQL复杂查询*/public RiskAnalysisResult analyzeTransactionRisk(String accountNo, BigDecimal amount) {// 使用PostgreSQL的窗口函数进行复杂分析String sql = """WITH recent_transactions AS (SELECT amount,created_at,LAG(amount) OVER (ORDER BY created_at) as prev_amount,COUNT(*) OVER (ORDER BY created_at RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW) as hour_countFROM transactions WHERE account_no = ? AND created_at >= NOW() - INTERVAL '24 hours')SELECT MAX(amount) as max_amount,AVG(amount) as avg_amount,MAX(hour_count) as max_hourly_count,COUNT(*) as daily_countFROM recent_transactions""";return postgresTemplate.queryForObject(sql, RiskAnalysisResult.class, accountNo);}/*** 实时风控检查 - Redis计算*/public boolean checkRealTimeRisk(String accountNo, BigDecimal amount) {String dayKey = "risk:daily:" + accountNo + ":" + LocalDate.now();String hourKey = "risk:hourly:" + accountNo + ":" + LocalDateTime.now().getHour();// 检查日累计限额BigDecimal dailyTotal = new BigDecimal(redisTemplate.opsForValue().get(dayKey, "0"));if (dailyTotal.add(amount).compareTo(DAILY_LIMIT) > 0) {return false; // 超过日限额}// 检查小时交易频次Long hourlyCount = redisTemplate.opsForValue().increment(hourKey);redisTemplate.expire(hourKey, 1, TimeUnit.HOURS);if (hourlyCount > HOURLY_FREQUENCY_LIMIT) {return false; // 超过频次限制}return true;}/*** 系统监控指标 - InfluxDB时序存储*/public void recordMetrics(String metric, double value, Map<String, String> tags) {Point point = Point.measurement(metric).time(System.currentTimeMillis(), TimeUnit.MILLISECONDS).addField("value", value).tag(tags).build();influxDB.write("financial_metrics", "autogen", point);}
}

🎯 面试重点总结

💡 架构师级别面试题

1. 技术选型决策能力

Q: 如何为一个千万级用户的电商平台选择数据库架构？
A:

  • 分析业务特点：读多写少、数据模型复杂、一致性要求不同
  • 分层设计：核心交易用MySQL/TiDB，商品目录用MongoDB，缓存用Redis
  • 扩展策略：读写分离→分库分表→分布式数据库的演进路径
  • 监控保障：全链路监控，性能指标，故障预案
2. CAP理论实际应用

Q: 在设计分布式系统时如何在CAP之间做权衡？
A:

  • 业务优先级：金融系统选CP(一致性)，社交媒体选AP(可用性)
  • 分层策略：核心业务强一致性，边缘业务最终一致性
  • 技术实现：通过不同数据库组合实现不同一致性级别
  • 降级方案：异常情况下的服务降级策略
3. 性能优化策略

Q: 数据库性能出现瓶颈时的优化思路？
A:

  • 定位问题：慢查询分析、监控指标、系统资源
  • 优化层次：SQL优化→索引优化→架构优化→硬件优化
  • 缓存策略：多级缓存、缓存预热、缓存更新策略
  • 架构演进：垂直扩展→水平扩展→分布式架构

🎖️ 架构师核心能力

  1. 技术选型能力：基于业务特点选择最合适的技术方案
  2. 性能权衡能力：在性能、一致性、成本间找到最佳平衡点
  3. 演进设计能力：设计可演进的架构，支持业务发展
  4. 风险控制能力：识别技术风险，制定应对策略

🚀 进阶学习路径

📚 推荐资源

  • 经典书籍：《数据密集型应用系统设计》、《架构师修炼之道》
  • 实战案例：大厂技术博客、开源项目架构分析
  • 前沿技术：NewSQL数据库、云原生数据库、多模数据库
  • 工具实践：数据库压测、监控平台、自动化运维

🎯 能力进阶

  • 初级：掌握单一数据库使用，了解基本概念
  • 中级：理解不同数据库特点，能进行简单选型
  • 高级：精通多种数据库，能设计复杂的数据架构
  • 专家：具备架构师思维，能制定企业级数据战略

🎯 数据库选型是架构师的核心技能！掌握选型方法论，成为技术决策的领导者！

📌 行动指南

  1. 点赞 → 让更多Java开发者掌握数据库技术
  2. 评论 → 留言"数据库技术"领取[MySQL性能优化指南]
  3. 关注 → 追踪更新《更多Java技术精彩内容》（已写完待发布）
  4. 赞赏 → 解锁完整源码+专属技术咨询

🚀 下期预告
《更多Java技术精彩内容》关注可抢先看

📚 相关推荐：

  • 漫画Java基础
  • 漫画Spring全家桶
  • 漫画JVM调优

让我们一起在Java的世界里探索更多精彩内容！ 🚀

http://www.xdnf.cn/news/15243.html

相关文章：

  • 建造者模式（Builder）
  • 【Datawhale AI 夏令营】 用AI做带货视频评论分析（二）
  • 微服务环境下的灰度发布与金丝雀发布实战经验分享
  • 【电脑】硬盘驱动器（HDD）的基础知识
  • 消息认证码（message authentication code）MAC
  • skywalking镜像应用springboot的例子
  • 【设计模式】单例模式 饿汉式单例与懒汉式单例
  • jenkins自动化部署前端vue+docker项目
  • 并发--Callable vs Runnable
  • 代码随想录算法训练营第三十二天|LeetCode 509 斐波那契数，LeetCode 70 爬楼梯，LeetCode 746 使用最小花费爬楼梯
  • 笔记-分布式计算基础
  • 云计算三大服务模式深度解析：IaaS、PaaS、SaaS
  • zynq-PS篇——bperez77中DMA驱动注意事项
  • 飞算 JavaAI 智能编程助手：颠覆编程旧模式，重构新生态
  • 深入解析Java的G1收集器：原理、实战与优缺点
  • Umi-OCR 的 Docker安装（win制作镜像，Linux（Ubuntu Server 22.04）离线部署）
  • 企业采购成本越来越贵？根源在哪，数据怎么分析？
  • 奇哥面试记：SpringBoot整合RabbitMQ与高级特性，一不小心吊打面试官
  • 供应链管理-计划：产能策略
  • Java 并发AQS为什么是双向链表
  • [面试] 手写题-选择排序
  • 学习C++、QT---20（C++的常用的4种信号与槽、自定义信号与槽的讲解）
  • JavaAI时代：重塑企业级智能开发新范式
  • 秋招小白学数据结构-1-数据结构前置知识
  • 面向构件的编程（COP）深度解析：构建模块化系统的工程范式
  • Linux_3：进程间通信
  • （六）复习（OutBox Message）
  • 游戏的程序员会不会偷偷改自己账号的数据？
  • C++迭代器失效
  • 数据结构 顺序表(3)---顺序表的应用