分类：数据库 - LT技术站|纸上得来终觉浅，绝知此事要躬行！

数据库引擎与设计速查：ClickHouse、ES、建模工具

OLAP引擎推荐ClickHouse（海量事件处理、列式存储、MergeTree架构）、Elasticsearch（倒排索引）和Supabase（集成PostgreSQL服务）。设计遵循业务实体优先原则，避免冗余范式，推荐Using standby key解决并发访问，高频操作需场景适配。PDMan适合中小团队轻量化建模，PowerDesigner功能全面但依赖Windows环境。ACID事务需匹配业务强一致性需求，分布式场景需取舍最终一致性。数据库迁移应分阶段验证，备份策略涵盖物理快照、逻辑日志和定期红蓝演练，重点监测数据延迟与一致性，避免RPO/RTO盲区。

数据库

Redis 客户端与分布式锁：Jedis、Lettuce 与 Redlock 的取舍

选择 Redis 客户端需权衡命令可预测性（Jedis）与线程安全（Lettuce）：Jedis适用于维持原生态调试和单项目维护，但需严格区分线程使用与连接池管理，避免跨线程操作同一实例及误用移除命令。Lettuce基于 Netty 实现连接复用和异步支持，适配多线程场景但需注意连接独占与网络拓扑配置，不可与 Redisson 锁服务共用通道。分布式锁设计存在清晰场景边界：Redlock仅适用于多 Redis 实例且接受极低重复风险的场景（ thời lượng< Vocaliser> 简单更新逻辑，禁用单机存储自以为强一靶机锁，而账务库存等关键业务需回归数据库约束或 ZooKeeper/etcd 等可靠分布式协调方案。任务去重可采用单机 Redis 锁（要求加随机值并使用 Lua 释放命令）。核心收益在于明确各工具适用边界，避免因技术选型不当导致性能问题或锁失效风险。

Redis

数据库与分布式存储：从单库到多引擎的选型与落地

本文系统梳理高并发场景下数据存储方案的设计逻辑与实践要点，建议优先基于业务查询路径进行架构决策。针对单表容量瓶颈，核心需解决跨库事务、全局唯一ID和动态扩容问题，切分键应与高频WHERE条件对齐而非盲目追求字段全面性。宽表适合稳定查询模式下的读多场景，需重点关注字段裁剪策略、增量更新地和数据漂移检测；HTAP架构需权衡事务一致性要求与实时分析粒度，避免在OLTP库直接部署重报表。数据库引擎选型方面，PostgreSQL适用于复杂类型和小规模高稳定场景，Firebird适合嵌入式及单机场景，Neo4j专攻多跳关系查询，三者避免功能间错位应用。运维层需强化binlog审计机制（控制事务碎片化）、构建三维监控体系（路由均衡性/语句执行性存储负载）、规划多数据源路由的租户隔离策略。重点收益包括：架构设计从业务用例反推技术选型路径，存储形态选择需评估延迟/容量/一致性三要素权重，数据库选型应匹配具体业务特征而非盲目跟风。

数据库

Redis 与 MySQL 缓存一致性：从 Cache Aside 到 Outbox 与 CDC

MySQL与Redis不能形成原子事务，导致缓存一致性问题。标准实践采用Cache Aside模式：业务操作先提交MySQL，再删除Redis缓存并设置TTL。需防范删除失败导致的脏数据残留，通过异步重试队列、死信处理和实时监控缓解。热点Key需额外控制并发回源，如使用Singleflight限流、版本号校验或Lease令牌机制。多级缓存场景需广播失效事件并设置本地缓存短期TTL。最终一致性依赖严格流程：事务提交后删除缓存，同时结合业务级别控制（基础级：TTL+删除失败告警；可靠级：异步重试+补偿任务；平台级：Outbox+CDC+失效广播）。核心风险需通过版本化、延迟双删和合理SLO监控平衡。

Redis