西安医疗网站制作友情链接交换软件

数据库选型策略

数据模型

数据库类型	数据模型	典型场景	代表产品
关系型数据库（RDBMS）	表格结构，强Schema约束	事务处理（OLTP）、复杂查询	MySQL、PostgreSQL、Oracle
文档数据库	JSON/BSON文档，弱Schema	灵活模式、半结构化数据存储	MongoDB、Couchbase
键值数据库	Key-Value存储	高速缓存、会话管理	Redis、DynamoDB
列式数据库	按列存储，压缩率高	数据分析（OLAP）、大规模聚合	Cassandra、HBase、ClickHouse
图数据库	节点与关系存储	社交网络、推荐系统、欺诈检测	Neo4j、ArangoDB
时序数据库	时间序列数据优化	物联网监控、日志存储、指标分析	InfluxDB、TimescaleDB
搜索引擎数据库	全文检索、相关性排序	商品搜索、日志分析	Elasticsearch、Solr

业务场景

• OLTP（联机事务处理） ：

  • 特点：高并发短事务，强一致性，频繁增删改。
  • 选型：关系型数据库（如MySQL）、NewSQL（如TiDB）。

• OLAP（联机分析处理） ：

  • 特点：复杂查询，大数据量聚合，读多写少。
  • 选型：列式数据库（如ClickHouse）、MPP数据库（如Snowflake）。

• HTAP（混合事务与分析处理） ：

  • 特点：兼顾事务与分析需求。
  • 选型：NewSQL（如TiDB）、云原生数据库（如Google Spanner）。

技术特性

• 一致性：

  • 强一致性（CP）：金融交易（如MySQL ACID）。
  • 最终一致性（AP）：社交网络评论（如Cassandra）。

• 扩展性：

  • 垂直扩展（Scale-Up）：单机性能强（如Oracle）。
  • 水平扩展（Scale-Out）：分片与多副本（如MongoDB）。

• 事务支持：

  • 单机事务：MySQL、PostgreSQL。
  • 分布式事务：TiDB（Percolator协议）、CockroachDB（Spanner协议）。

选型决策框架

• 数据规模：

  • 小数据量（<1TB）：单机RDBMS（如PostgreSQL）。
  • 大数据量（>1TB）：分布式数据库（如Cassandra、TiDB）。

• 读写比例：

  • 写密集型：LSM-Tree结构数据库（如HBase）。
  • 读密集型：内存数据库（如Redis）或列式存储（如ClickHouse）。

• 延迟要求：

  • 毫秒级响应：内存数据库（如Redis）、OLTP数据库（如MySQL）。
  • 亚秒级响应：OLAP优化数据库（如BigQuery）。

分库分表实践

垂直拆分

• 垂直分库：按业务模块划分数据库（如用户库、订单库、商品库）。

  • 优点：业务解耦，降低单库压力。
  • 缺点：跨库事务复杂，需通过分布式事务（如Seata）解决。

• 垂直分表：将大表按列拆分（如用户表拆分为基础信息表、扩展信息表）。

  • 场景：包含大量不常用字段（如用户备注、历史日志）。

水平拆分

• 水平分库：将同一业务数据按分片键分布到多个数据库（如订单库1、订单库2）。
• 水平分表：将同一表数据按分片键分布到多个子表（如order_00、order_01）。

缓存策略优化

缓存读写策略

策略	流程	适用场景	优缺点
Cache-Aside（旁路缓存）	1. 读：先查缓存，未命中读DB并回填。 2. 写：直接写DB，删除缓存。	通用场景（如用户信息）	实现简单，但存在缓存不一致风险（需结合延迟双删）。
Read-Through	缓存作为代理，读请求由缓存处理，未命中时缓存自动从DB加载并返回。	缓存与DB强绑定（如ORM集成）	简化业务逻辑，但缓存层需感知DB结构。
Write-Through	写请求同时更新缓存和DB，由缓存层保证原子性。	对一致性要求极高的场景（如金融余额）	写延迟高，需事务支持。
Write-Behind	写请求先更新缓存，异步批量写DB（如定时刷新）。	写密集型场景（如日志、计数器）	吞吐量高，但存在数据丢失风险（缓存宕机）。

缓存淘汰策略

策略	原理	适用场景
LRU	淘汰最近最少使用的数据（基于时间局部性原理）。	热点数据分布不均的长尾场景。
LFU	淘汰访问频率最低的数据（基于计数统计）。	数据访问模式稳定的场景（如配置项）。
FIFO	淘汰最早进入缓存的数据。	数据冷热无明显差异的流水场景。
TTL	为每个Key设置过期时间，到期自动失效。	临时数据（如验证码、会话信息）。
Random	随机淘汰数据。	极端场景下的兜底策略。

多级缓存架构

• 本地缓存 + 分布式缓存

  • 本地缓存（L1） ：使用Guava、Caffeine，缓存热点数据（毫秒级响应）。
  • 分布式缓存（L2） ：使用Redis、Memcached，共享全量数据（避免单机缓存穿透）。

• 同步机制：

  • 主动推送：DB变更时，通过消息队列（如Kafka）通知各节点失效本地缓存。
  • 被动失效：设置本地缓存短TTL（如5秒），依赖L2缓存兜底。

• 浏览器缓存 + CDN + 服务端缓存

  • 浏览器缓存：通过Cache-Control、ETag控制静态资源缓存（减少服务端请求）。
  • CDN缓存：缓存图片、视频等静态资源，按区域就近分发。
  • 服务端缓存：缓存动态数据（如API响应），通过Nginx或网关层实现。

缓存穿透（Cache Penetration）

• 问题：大量请求查询不存在的数据（如不合法ID），绕过缓存直接冲击DB。

• 解决方案：

  • 布隆过滤器（Bloom Filter） ：在缓存层前置过滤器，拦截无效请求。
  • 空值缓存：将查询结果为空的Key也缓存（设置短TTL，如30秒）。

缓存雪崩（Cache Avalanche）

• 问题：大量缓存同时过期，导致请求集中访问DB。

• 解决方案：

  • 随机化过期时间：基础TTL + 随机值（如TTL = 300 + rand(0, 60)秒）。
  • 永不过期 + 异步刷新：缓存不设TTL，后台线程定期更新（需处理脏读）。

缓存击穿（Cache Breakdown）

• 问题：某热点Key失效的瞬间，高并发请求直接击穿到DB。

• 解决方案：

  • 互斥锁（Mutex Lock） ：第一个请求加锁查DB，后续请求等待锁释放后读取缓存。
  • 逻辑过期：缓存Value中存储过期时间，业务判断是否需要异步更新。

数据一致性保障

强一致性（Strong Consistency）

• 定义：任何读操作都能读到最新写入的数据，所有节点数据实时一致。

• 实现方式：

  • 同步复制：写入操作需所有副本确认后才返回成功（如ZooKeeper的ZAB协议）。
  • 分布式锁：通过锁机制保证同一时刻仅一个客户端修改数据（如Redis RedLock）。

• 适用场景：金融交易、库存扣减等不允许数据不一致的场景。

最终一致性（Eventual Consistency）

• 定义：数据副本经过一段时间后达到一致，期间允许短暂不一致。

• 实现方式：

  • 异步复制：写入主节点后异步同步到从节点（如MySQL主从架构）。
  • 冲突解决：通过版本号（Vector Clock）或业务逻辑合并冲突（如购物车合并）。

• 适用场景：社交网络点赞、评论等容忍短暂不一致的场景。

其他一致性模型

模型	特点	案例
因果一致性	有因果关系的操作按顺序可见，无因果关系的操作允许乱序。	聊天消息的顺序保证。
会话一致性	同一会话内的操作保证顺序一致性，跨会话允许延迟。	用户登录后的操作连贯性。
单调读一致性	用户读取的数据版本不会回退（如不会读到比之前更旧的值）。	新闻Feed流的分页