选mongodb还是redis存用户配置，取决于数据结构和访问模式：嵌套查询多选mongodb，高频单键读写选redis；二者可混用，但需解决双写一致性。
微服务里存用户配置，该用MongoDB还是Redis？
看数据读写模式和一致性要求。如果配置项结构多变、偶尔要按嵌套字段查（比如 user.settings.theme），选 MongoDB；如果只是高频读写单个键（如 user:1001:config），且必须毫秒级响应，Redis 更合适。
常见错误是把 MongoDB 当缓存用——它没内置 TTL 自动过期，得靠应用层轮询或用 TTL 索引，但索引只对整个文档生效，无法对子字段设过期时间；而 Redis 的 EXPIRE 直接作用于键，天然适配会话、临时配置类场景。
- 用户偏好、设备绑定等带嵌套结构、查询路径不固定的数据 →
MongoDB - 登录态 token、实时库存锁、计数器 →
Redis - 两者混用也常见：用
Redis做热数据缓存，MongoDB做持久底库，但要注意双写一致性（推荐用变更事件 + 消息队列解耦）
物联网设备上报数据，Cassandra 和 MongoDB 分片策略怎么选？
关键看写入吞吐和时间范围查询频率。Cassandra 的 timeuuid 主键天然支持按时间范围高效 scan；MongoDB 的分片键若选错（比如用 device_id 而非 timestamp），会导致时间范围查询跨所有分片，性能断崖下跌。
实测中，10万设备每秒上报一条含 20 字段的 JSON，在 Cassandra 上写入延迟稳定在 5ms 内；同样负载下，MongoDB 若分片键未包含时间维度，聚合查询耗时可能从 200ms 涨到 2s+。
- Cassandra：适合写远大于读、且查询集中在“最近 N 小时”的场景，用
PRIMARY KEY (device_id, timestamp)建表 - MongoDB：若需频繁按设备 + 时间双向筛选（如查某设备某时段所有异常），用
shard key {device_id: 1, timestamp: -1}，否则别轻易分片 - 注意：Cassandra 不支持二级索引下的高基数字段过滤（如查“温度 > 35”的所有设备），这类需求得靠物化视图或应用层预聚合
Golang 驱动连 MongoDB，为什么 FindOne 总返回空？
八成是 BSON 编解码字段名不匹配。Go struct tag 写成 json:"name"，但 MongoDB 驱动默认用 bson:"name" 解析，字段名对不上就跳过赋值，也不报错。
另一个坑是 context 超时设置不合理：FindOne 默认无超时，但生产环境必须显式传带 timeout 的 context，否则网络卡住会阻塞 goroutine。
- 确保 struct 字段有
bsontag，且值与数据库字段名一致（区分大小写） - 用
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)包裹操作，记得 defer cancel() - 检查
err是否为mongo.ErrNoDocuments，而不是直接判空——这是正常业务逻辑分支，不是错误
微服务间共享图关系，Neo4j 和 MongoDB 图功能能混用吗？
不能。MongoDB 6.0+ 虽加了图查询语法（$graphLookup），但它本质是递归聚合，最多支持 10 层深度，且无法建真正意义上的边索引；Neo4j 的原生图引擎对“朋友的朋友的朋友”这类 3 跳查询，延迟稳定在 10ms 内，而 MongoDB 同样查询可能超时。
更隐蔽的问题是事务：Neo4j 支持节点/关系级别的 ACID，适合风控规则引擎这种强一致图更新；MongoDB 的图操作全在单文档内，跨文档关系变更仍得靠应用层协调。
- 社交关系链、权限继承树、依赖拓扑分析 → 必选 Neo4j 或 JanusGraph
- 只是偶尔查“文章关联标签”这种浅层一对多 →
$graphLookup够用，但别指望性能 - Golang 连 Neo4j 推荐用官方
neo4j-go-driver，别用 HTTP REST client，后者无法复用连接池
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
