一、NoSQL操作题实战解析

1.1 基础CRUD操作题

以MongoDB为例，典型操作题包括：

// 插入文档
db.users.insertOne({
  name: "Alice",
  age: 28,
  tags: ["developer", "mongodb"]
});
// 条件查询（年龄大于25且标签包含developer）
db.users.find({
  $and: [
    { age: { $gt: 25 } },
    { tags: "developer" }
  ]
});
// 原子更新（年龄加1）
db.users.updateOne(
  { name: "Alice" },
  { $inc: { age: 1 } }
);

操作要点：

• 插入时需注意文档结构一致性（如嵌套文档深度）
• 查询条件需合理设计索引（如复合索引{age:1, tags:1}）
• 更新操作需考虑并发控制（MongoDB默认使用文档级锁）

1.2 分布式场景操作题

Redis集群操作示例：

# 集群节点添加（生产环境需3主3从配置）
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000
# 哈希槽迁移
redis-cli --cluster reshard 127.0.0.1:7000

关键指标：

• 集群规模：建议至少6节点（3主3从）
• 哈希槽分配：默认16384个槽位，需均匀分布
• 故障转移：配置min-slaves-to-write 2防止脑裂

1.3 性能优化操作题

Cassandra调优案例：

-- 创建表时指定压缩算法
CREATE TABLE user_data (
  user_id uuid,
  event_time timestamp,
  data text,
  PRIMARY KEY (user_id, event_time)
) WITH compression = {
  'sstable_compression': 'LZ4Compressor'
};
-- 调整读修复频率
ALTER TABLE user_data WITH read_repair_chance = 0.1;

优化维度：

• 压缩算法选择：LZ4（CPU友好） vs Snappy（吞吐优先）
• 读修复策略：根据一致性要求调整（0-1之间）
• 缓存配置：key_cache_size_in_mb设置需结合可用内存

二、NoSQL核心原理剖析

2.1 CAP理论实现机制

数据库类型	一致性(C)	可用性(A)	分区容忍性(P)
MongoDB	强一致性	可配置	优秀
Cassandra	最终一致	高	优秀
Redis	强一致性	高	中等

实现差异：

• MongoDB通过副本集选举（多数节点确认）保证强一致
• Cassandra采用Quorum协议（R+W>N）实现可调一致性
• Redis主从复制默认异步，可通过WAIT命令实现同步复制

2.2 数据模型设计原则

2.2.1 文档型设计范式

反模式案例：

// 不良设计：频繁更新嵌套数组
{
  order_id: "ORD123",
  items: [
    { product_id: "P1", quantity: 2 },
    { product_id: "P2", quantity: 1 } // 后续可能频繁增删
  ]
}

优化方案：

• 采用引用式设计：items: ["P1", "P2"]配合单独集合
• 对于高频更新字段，考虑拆分为独立文档

2.2.2 宽表设计策略

Cassandra宽表示例：

CREATE TABLE sensor_readings (
  sensor_id text,
  reading_time timestamp,
  value double,
  unit text,
  status text,
  PRIMARY KEY ((sensor_id), reading_time)
) WITH CLUSTERING ORDER BY (reading_time DESC);

设计要点：

• 主键设计需支持时间范围查询
• 列族数量建议控制在100以内（避免SSTable膨胀）
• 静态列（如unit）适合不常变更的元数据

2.3 分布式架构解析

2.3.1 分片策略对比

策略	适用场景	代表数据库
范围分片	时间序列数据	Cassandra
哈希分片	均匀分布的键值数据	Redis集群
目录分片	多租户场景	MongoDB

实现细节：

• MongoDB分片键选择：避免使用递增ID（导致热点）
• Cassandra虚拟节点：默认256个vnode平衡负载
• Redis集群哈希槽：16384个固定槽位简化路由

2.3.2 一致性协议实现

Raft协议在TiKV中的实现：

1. Leader选举：随机超时机制避免脑裂
2. 日志复制：两阶段提交（PreVote+Vote）
3. 状态机安全：确保日志顺序一致性

性能影响：

• 选举超时时间（通常150-300ms）影响故障恢复速度
• 日志批处理大小（默认64KB）影响吞吐量
• 同步复制模式（Sync=true）增加延迟但保证持久性

三、进阶实践建议

3.1 混合架构设计

典型方案：

• Redis缓存层 + MongoDB主存 + Elasticsearch搜索层
• Cassandra时序数据 + HBase元数据存储

数据同步策略：

• 变更数据捕获（CDC）：Debezium+Kafka方案
• 双写模式：需处理冲突（版本号或时间戳）
• 批量导入：适合初始数据加载

3.2 监控体系构建

关键指标：

• 延迟：P99延迟需控制在10ms以内（关键业务）
• 吞吐量：QPS/TPS基准测试
• 错误率：写超时、读失败等异常

工具链：

• Prometheus + Grafana监控面板
• MongoDB Atlas内置监控
• Cassandra JMX指标采集

3.3 故障演练方案

演练场景：

1. 网络分区测试：使用iptables模拟分区
2. 节点宕机测试：kill -9进程后观察自动恢复
3. 磁盘故障测试：卸载数据目录后观察重建

恢复标准：

• 集群状态：PRIMARY或UP状态恢复时间
• 数据一致性：校验和比对
• 性能恢复：QPS回到基准值的95%以上

本文通过操作题解析与原理深度剖析，构建了从基础操作到架构设计的完整知识体系。开发者可通过实战练习巩固技能，同时理解底层原理实现更优的数据库设计。建议结合具体业务场景进行针对性优化，持续监控关键指标，建立完善的故障处理机制。