面试题答案
一键面试数据分片策略选择
- 基于范围（Range-based Sharding）
- 适用场景：适用于具有明显范围特征的数据，例如时间序列数据（如日志按时间戳）、数值区间数据（如订单金额范围）。如果数据按某个字段有自然的顺序，并且希望相近的数据存储在同一分片上，基于范围的分片策略较为合适。比如，电商系统中不同年份的订单数据，将同一年份订单数据分到同一分片，方便按年份进行查询等操作。
- 优点：顺序读取性能好，对于范围查询效率高，因为数据按范围分布，查询特定范围数据时，可能只需访问少数几个分片。
- 缺点：容易产生数据倾斜，例如某个范围的数据量远大于其他范围。如果范围划分不合理，热门范围的分片负载会很高，而其他分片闲置。
- 基于哈希（Hash - based Sharding）
- 适用场景：适用于没有明显范围特征，希望数据均匀分布的数据。例如用户ID、随机生成的UUID等。对于一些没有自然顺序且需要均匀分布负载的数据，哈希分片是不错的选择。比如社交平台的用户数据，使用用户ID进行哈希分片，能让不同用户数据均匀分布在各个分片上。
- 优点：数据分布均匀，能有效避免数据倾斜，各分片负载均衡。因为哈希函数将数据均匀映射到不同分片。
- 缺点：不适合范围查询，因为哈希后的数据顺序被打乱，无法通过范围快速定位到特定分片。对于按范围查询的场景，可能需要扫描所有分片。
Shard Server、Config Server和Query Router协作
- Shard Server
- 功能：负责存储实际的数据分片。每个Shard Server包含一部分数据，并且可以是副本集（Replica Set）的形式，以提供数据冗余和高可用性。例如，在一个电商订单系统中，部分订单数据存储在某个Shard Server上。
- 协作：接收来自Query Router的数据读写请求，处理后返回结果。同时，与Config Server保持通信，获取集群的元数据信息，以了解自身在集群中的位置和职责。
- Config Server
- 功能：存储集群的元数据，包括数据的分片信息（哪个范围或哈希值的数据存储在哪个Shard Server上）、集群的拓扑结构等。它是整个集群的“大脑”，记录着数据分布的关键信息。
- 协作：当Query Router启动或需要获取最新的分片信息时，向Config Server请求元数据。Config Server实时更新并维护这些信息，确保集群状态的一致性。当Shard Server的状态发生变化（如新增、移除）时，Config Server会更新元数据并通知相关组件。
- Query Router（mongos）
- 功能：客户端与集群交互的入口，接收客户端的读写请求，根据从Config Server获取的元数据，将请求路由到正确的Shard Server上。它对客户端屏蔽了集群的内部复杂性，客户端像操作单台MongoDB一样与Query Router交互。例如，客户端发送一个查询订单的请求，Query Router根据订单ID的分片信息，将请求转发到对应的Shard Server。
- 协作：与Config Server保持连接，定期获取最新的元数据。当接收到客户端请求时，解析请求，根据元数据确定数据所在的Shard Server，然后将请求转发过去，并将Shard Server返回的结果汇总后返回给客户端。
避免数据倾斜问题
- 合理选择分片键
- 基于范围分片：确保范围划分合理，对数据进行充分的分析，预测不同范围的数据量增长趋势。例如，对于按时间分片的日志数据，如果某些时间段（如业务高峰期）数据量较大，可以适当细分这些时间段的范围，避免单个分片负载过高。
- 基于哈希分片：选择具有足够随机性的字段作为哈希分片键。如果使用用户ID，要确保ID的生成方式足够随机，避免某些ID集中在少数哈希值上。如果ID是顺序生成的，可以结合其他随机字段（如随机生成的盐值）进行哈希计算。
- 动态调整分片
- 监控数据分布：通过MongoDB提供的监控工具（如mongostat、mongsot等），实时监控各分片的负载情况，包括数据量、读写操作频率等。如果发现某个分片负载过高，及时进行调整。
- 数据迁移：MongoDB支持在运行时进行数据迁移。可以使用平衡器（Balancer）工具，它会自动检测数据分布不均的情况，并在后台将数据从负载高的分片迁移到负载低的分片。也可以手动执行数据迁移操作，通过调整分片键范围或重新哈希等方式，将数据重新分布到不同分片。
- 预分片 在集群初始化阶段，根据预估的数据量和分布情况，预先创建足够数量的分片。例如，预计未来会有大量用户数据，提前创建较多的分片，随着数据的增长，数据会均匀分布到这些分片中，避免后期因分片不足导致数据倾斜。