Redis可作为主存储替代MySQL，适用于高并发、数据模型简单、可接受分级持久化的场景，通过主从复制与热冷分层保障安全与性能。
微服务架构下，分布式存储不是“选一个数据库就行”，而是要按数据类型、一致性要求、读写特征和运维能力分层决策。硬套单一方案，后期大概率要推倒重来。
什么时候该用 Redis 而不是 MySQL 做主存储
Redis 不是 MySQL 的替代品，而是互补角色。它适合存那些“临时性、高频读、结构简单、允许丢失”的数据。
- 用户登录态（
session_id→user_info），设 TTL 自动过期，避免手动清理 - 秒杀库存的原子扣减（用
DECR或EVAL脚本），靠单线程+原子指令保操作安全 - 热点文章阅读数（
INCR article:123:views），不强求 100% 准确，但要快 - 不要存订单详情、用户档案、交易流水——这些字段多、关联强、必须 ACID，MySQL/PostgreSQL 才是正解
踩坑点：把 Redis 当主库用，结果某次主从切换丢了几百条支付状态；或者用 KEYS * 清缓存，拖垮整个集群。
etcd 和 Consul 在微服务中到底存什么
它们不是通用 KV 存储，而是专为元数据设计的强一致协调服务。存错东西，性能和可靠性都会打折。
立即学习“go语言免费学习笔记（深入）”；
- 只存服务注册信息（如
/services/order/v1/10.0.1.5:8080）、配置项（/config/payment/timeout_ms）、分布式锁 Lease ID - 不存业务数据（比如用户地址列表、商品 SKU 映射表）——这些应走专用数据库或本地缓存
- etcd 写入吞吐低但一致性严格，适合配置变更频率低、必须精确同步的场景；Consul 读性能略好，自带 DNS 接口，适合服务发现为主、配置为辅的系统
常见误用：把 etcd 当成轻量级 Redis 用，存大量 cache:user:* 类键，导致 Raft 日志膨胀、leader 切换频繁。
对象存储（MinIO/S3）和块存储（Ceph）怎么分工
微服务里文件类数据越来越多，但不是所有文件都该进同一个存储池。
- 用户上传头像、合同 PDF、日志归档包 → 用 MinIO（兼容 S3 协议）：HTTP 直传、权限细粒度（
bucket/policy）、天然适合多服务共享 - 数据库备份镜像、Kubernetes PV 底层存储 → 用 Ceph RBD：提供块设备接口、支持快照与克隆、IO 延迟更低，但接入复杂，需专用客户端
- 别把小文件（
关键细节：MinIO 默认不开启纠删码，生产环境务必配 erasure coding；Ceph 的 crush map 设计不合理会导致热点 OSD，上线前必须压测。
本地缓存 + 分布式缓存混合时最易漏掉的并发点
「先查本地，未命中再查 Redis 回填」这个模式本身就有竞态，不是加个 sync.Once 就能解决。
- 两个 goroutine 同时发现本地无缓存，都去 Redis 加载，然后都往本地写 —— 造成冗余计算和内存浪费
- 解决方案不是锁整个 key，而是用
singleflight.Group包裹 Redis 查询逻辑，让相同 key 的并发请求合并为一次后端调用 - 回填本地缓存前，检查是否已存在（避免覆盖新值），推荐用
atomic.Value或带 CAS 的 map 实现 - 注意 TTL 同步：Redis 过期时间 ≠ 本地缓存过期时间，本地应设更短 TTL（如 Redis 30min，本地 25min），防止脏读
真正难的不是代码怎么写，而是想清楚哪一层该承担什么责任——本地缓存管速度，Redis 管共享，etcd 管一致，S3 管容量。混用可以，但边界必须划清。
