小红书Java岗面试真题-分库分表设计总结
小红书 Java 面试经验总结 | 分库分表设计
一、项目背景与问题引入
1.1 代金券项目分库分表实践回顾
代金券项目业务架构图：
在我参与的代金券项目中，我们采用了按用户 ID 分库分表的策略，将代金券数据按照用户 ID 的哈希值分配到不同的数据库和表中。这种设计的初衷是为了应对日益增长的数据量，避免单库单表带来的性能瓶颈。然而，在项目上线后，我们很快就遇到了一个严重的问题 —— 数据倾斜。
具体来说，我们的代金券表按用户 ID 进行哈希取模，分成了 16 个分片（库），每个库内再按时间范围分成 12 个表（按月）。原本以为这种设计能够均匀分布数据，但是在实际运行中发现，部分热门领券活动的活跃用户代金券数据量远超预期。特别是一些经常参与活动的用户，他们的代金券数量达到了数万张，导致这些用户所在的分片数据量是其他分片的 10 倍以上(70)。
这种数据倾斜带来的影响是灾难性的。首先是查询性能急剧下降，原本响应时间在 200ms 以内的查询，在数据倾斜严重的分片上飙升到 2 秒以上(80)。其次是写入性能也受到严重影响，在活动高峰期，这些热点分片的写入延迟达到了秒级，严重影响了用户体验。更糟糕的是，这些分片的 CPU 使用率长期保持在 90% 以上，内存使用率也接近上限，给系统稳定性带来了巨大风险。
1.2 数据倾斜问题的深层分析
经过深入分析，我们发现数据倾斜问题的根源在于以下几个方面：
分片键选择的局限性。虽然用户 ID 在理论上能够均匀分布数据，但在实际业务场景中，某些用户（如羊毛党、活动达人）会大量囤积代金券，导致这些用户的数据在特定分片上高度集中(72)。我们的分片策略没有考虑到业务数据的实际分布特征，只是简单地基于用户 ID 进行哈希，这是导致问题的根本原因。
业务场景的特殊性。代金券业务具有明显的 “二八定律” 特征，20% 的用户占据了 80% 的代金券数据。而我们的分库分表策略没有针对这种业务特征进行优化，导致热点数据无法有效分散。特别是在大型促销活动期间，这种倾斜会被进一步放大。
扩容策略的僵化。我们最初设计的 16 个分片在系统初期是足够的，但随着业务的快速增长，当需要扩容到 32 个分片时，面临着巨大的数据迁移挑战。由于采用的是固定哈希取模算法，扩容时需要迁移一半的数据，这个过程不仅耗时，而且存在数据不一致的风险(70)。
二、分库分表策略深度对比
2.1 按业务拆分策略详解
按业务拆分策略详解架构图：
按业务拆分是一种垂直分库的策略，它将不同业务模块的数据分散到不同的数据库中。在小红书的技术架构中，这种策略被广泛应用于各个核心业务模块。
小红书业务拆分的实践案例。小红书的技术架构采用了清晰的业务拆分策略，将整个系统分为多个独立的业务数据库。例如，用户模块包含用户表、关注表、粉丝表等，这些表被集中存储在 “用户数据库” 中；内容模块包含笔记表、评论表、点赞表等，存储在 “内容数据库” 中；互动模块包含消息表、通知表等，存储在 “互动数据库” 中。
这种架构设计带来了诸多优势。首先是业务与数据库的解耦，不同业务库可以独立部署、维护和扩展，降低了业务间的影响。其次是资源隔离，每个业务库可以根据自身的访问特点进行定制化优化。例如，用户库读多写少，可以配置更多的读副本；内容库写操作频繁，可以优化写性能。
然而，按业务拆分也带来了新的挑战。最突出的问题是跨库事务处理。例如，当用户发布一篇笔记时，需要同时更新用户库（增加发布数）和内容库（插入笔记记录），这就需要使用分布式事务来保证数据一致性。小红书在处理这类问题时，主要采用了 Seata 框架来实现分布式事务，通过 AT 模式和 TCC 模式来满足不同场景的需求(54)。
实际应用中的优化策略。在小红书的实践中，为了降低跨库事务的复杂度，他们采用了一些优化策略。例如，在用户发布笔记的场景中，会先在内容库中插入笔记记录，然后通过异步消息的方式更新用户库的发布数。这种最终一致性的方案虽然会有短暂的数据不一致，但在实际业务中是可以接受的，同时大大降低了系统的复杂度。
2.2 范围分片策略详解
范围分片策略详解架构图：
范围分片是一种水平分表的策略，它按照数据的某个字段范围进行划分。在小红书的业务场景中，这种策略被广泛应用于时间序列数据的存储。
小红书时间分片的典型应用。小红书的笔记数据采用了按时间范围分片的策略。具体来说，笔记表按创建时间分为多个分片，每个分片存储一个月的数据。例如，2025 年 1 月的数据存储在 note_202501 表中，2025 年 2 月的数据存储在 note_202502 表中，以此类推(34)。
这种设计带来了明显的优势。首先是数据的有序性，时间分片保证了数据的天然有序，这对于需要按时间查询的场景非常友好。其次是历史数据的管理，旧数据可以方便地归档或删除，不会影响当前业务的数据。第三是扩容的便利性，新增分片只需要创建新表即可，无需迁移历史数据(36)。
但是，范围分片也存在明显的劣势。最严重的问题是数据倾斜。在小红书的热门贴场景中，某些爆款笔记的访问量可能是普通笔记的数百倍，这些热点数据会集中在特定的时间分片内，导致该分片的负载远高于其他分片(83)。
热点数据的处理方案。面对热点数据问题，小红书采用了多种技术手段。首先是多级缓存策略，将热门贴的数据缓存在 Redis 中，减少对数据库的直接访问。其次是数据预热机制，在大促或活动前，将可能成为热点的内容提前加载到缓存中(74)。第三是读写分离架构，通过增加读副本的方式，分散读压力。
2.3 两种策略的对比分析
基于我的实战经验和小红书的技术实践，我们可以从多个维度对这两种策略进行深入对比：
| 对比维度 | 按业务拆分 | 范围分片 |
|---|---|---|
| 数据分布 | 业务内数据集中，业务间数据分散 | 数据按范围均匀分布 |
| 查询性能 | 单业务查询快，跨业务查询复杂 | 范围查询高效，随机查询需要路由 |
| 扩展性 | 业务扩展灵活，数据量扩展受限 | 数据量扩展容易，业务扩展复杂 |
| 事务处理 | 跨库事务复杂，需要分布式事务 | 本地事务简单，跨分片事务困难 |
| 运维复杂度 | 多库管理复杂，备份恢复成本高 | 分片管理相对简单，但需要协调 |
| 适用场景 | 业务模块清晰、耦合度低的系统 | 数据有明显时间或数值范围特征的场景 |
在实际应用中，这两种策略往往会结合使用。例如，小红书的整体架构采用按业务拆分，而在每个业务内部，对于特定的大表（如笔记表、评论表）又采用了范围分片的策略。这种混合策略既保证了业务的独立性，又解决了单表数据量过大的问题。
三、核心技术问题深度剖析
3.1 分片键选择的关键考量
分片键的选择直接决定了分库分表的性能和扩展性。基于我的代金券项目经验和小红书的实践，分片键选择需要遵循以下原则：
高基数原则。分片键应该选择基数高的字段，即该字段的值域范围大、重复率低。在小红书的用户系统中，用户 ID 是一个理想的分片键，因为每个用户都有唯一的 ID，且分布均匀(24)。相比之下，性别字段就不适合作为分片键，因为只有两个取值，会导致严重的数据倾斜。
业务关联原则。分片键应该与业务查询模式强相关。在我的代金券项目中，我们最初选择用户 ID 作为分片键，是因为大部分查询都是基于用户维度的。例如，查询用户的代金券列表、统计用户的领券记录等。这种设计保证了 90% 以上的查询可以路由到单个分片，避免了跨库查询(25)。
稳定性原则。分片键一旦确定，就不应该轻易修改。在小红书的实践中，用户 ID 从注册时就固定下来，不会发生变化，这保证了数据路由的稳定性。如果选择一个会频繁变化的字段（如手机号）作为分片键，那么每次修改都需要迁移数据，成本极高(25)。
哈希算法的选择。在确定分片键后，如何将其映射到具体的分片是另一个关键问题。简单的取模算法（如 user_id % 16）虽然实现简单，但在扩容时需要迁移大量数据。小红书在某些场景下采用了一致性哈希算法，这种算法可以保证在节点变化时，只有少量数据需要迁移。
复合分片键的应用。在某些复杂场景下，单一的分片键可能无法满足需求。小红书在处理评论数据时，采用了 “用户 ID + 笔记 ID” 的复合分片键。这种设计既保证了同一用户的评论数据集中存储，又避免了单个热门笔记的评论数据过度集中(85)。
3.2 分布式事务处理方案
分库分表后，本地事务变成了分布式事务，如何保证数据一致性是一个重大挑战。基于我的项目经验和小红书的技术实践，主要有以下几种解决方案：
2PC（两阶段提交）方案。2PC 是最传统的分布式事务解决方案，它将事务分为准备阶段和提交阶段。在小红书的某些核心业务（如支付、交易）中，会使用 2PC 来保证强一致性。例如，用户购买商品时，需要同时扣减账户余额和生成订单，这两个操作必须同时成功或失败(55)。
然而，2PC 也有明显的缺点。首先是性能问题，两阶段提交会锁定资源直到事务完成，在高并发场景下会成为瓶颈。其次是单点故障问题，如果协调者宕机，整个事务将无法完成。因此，小红书只在对一致性要求极高、并发量相对较低的场景下使用 2PC(55)。
TCC（Try-Confirm-Cancel）方案。TCC 是一种应用层的分布式事务解决方案，通过将业务操作分为三个阶段来实现最终一致性。在小红书的订单系统中，创建订单时会先执行 Try 操作（预留库存），然后执行 Confirm 操作（扣减库存、生成订单），如果任何一步失败，则执行 Cancel 操作（释放库存）(54)。
TCC 的优势在于实现灵活，可以根据业务需求定制。但它的缺点是侵入性强，每个业务操作都需要实现 Try、Confirm、Cancel 三个接口，代码量会增加 3 倍以上。在我的代金券项目中，我们在处理跨库的代金券发放时使用了 TCC，但维护成本确实很高(54)。
Saga 模式。Saga 模式将长事务拆分为多个短事务，每个短事务都有对应的补偿操作。如果某个步骤失败，则执行前面所有步骤的补偿操作，实现最终一致性。在小红书的笔记发布流程中，会涉及用户发布数增加、笔记内容存储、索引更新等多个步骤，这些可以通过 Saga 模式来协调(52)。
Saga 模式的优势是性能好，因为没有长时间的锁等待。但它的挑战在于事务的原子性需要自己保证，而且补偿逻辑的实现比较复杂。小红书在使用 Saga 时，通常会配合状态机来管理事务流程，确保每个步骤都能正确执行或回滚(52)。
本地消息表方案。这是一种基于最终一致性的方案，将分布式事务转换为本地事务 + 消息队列。在我的代金券项目中，我们使用了这种方案来处理跨库的代金券发放。具体流程是：用户领券时，先在用户库中记录领券信息（本地事务），然后向消息队列发送 “发放代金券” 的消息，代金券服务消费消息后，在代金券库中创建记录。
这种方案的优点是实现简单，不需要引入复杂的分布式事务框架。但它也有缺点，比如消息可能丢失、需要处理重复消费、可能出现短暂的数据不一致等。为了解决这些问题，小红书在实践中会使用可靠消息队列（如 RocketMQ），并在消息处理中实现幂等性。
3.3 跨库查询优化策略
跨库查询是分库分表后最常见也是最复杂的问题之一。基于我的项目经验和小红书的实践，主要有以下几种优化策略：
避免跨库查询的设计原则。最好的跨库查询优化是根本不进行跨库查询。在设计阶段，应该通过合理的数据冗余来避免跨库操作。例如，在小红书的笔记详情页中，需要展示用户的昵称、头像等信息。如果严格按照业务拆分，用户信息存储在用户库，笔记存储在内容库，每次查询都需要跨库。为了避免这种情况，小红书会在笔记表中冗余存储用户的昵称和头像 URL，这样查询笔记时就可以直接获取这些信息(58)。
全局表策略。对于数据量小、更新频率低、被多个业务频繁引用的表（如地区表、字典表、配置表等），可以在每个数据库中都保存一份副本。在小红书的系统中，地区表就是一个全局表，每个业务库都有完整的地区数据。这样，当业务需要查询地区信息时，直接在本地库查询即可，无需跨库(59)。
搜索引擎方案。对于复杂的查询需求，特别是涉及多条件组合查询、全文搜索等场景，可以引入搜索引擎（如 Elasticsearch）来解决。在小红书的搜索功能中，用户可以搜索笔记、用户、话题等内容，这些数据会实时同步到 ES 集群中。查询时直接访问 ES，避免了复杂的跨库查询(58)。
分布式查询框架。如果必须进行跨库查询，可以使用分布式查询框架。小红书在某些场景下会使用 Sharding-JDBC 或 MyCat 等中间件来实现跨库查询。这些框架可以将一个跨库查询拆解为多个单库查询，然后在内存中进行结果集的合并、排序、分页等操作。
但是，这种方案也有性能问题。例如，查询 “所有用户的代金券总数”，需要查询所有分片，然后汇总结果。如果有 16 个分片，就需要执行 16 次查询，然后在内存中聚合，效率很低。为了优化这种场景，小红书会在业务层做缓存，定期更新汇总数据。
数据仓库方案。对于一些复杂的统计分析需求，可以将数据同步到数据仓库中。小红书使用 ClickHouse 作为实时数据分析平台，每天有 6000 亿条数据同步到 ClickHouse 中。在进行复杂统计（如 “各城市用户的笔记发布趋势”）时，可以直接查询 ClickHouse，而不影响在线业务(19)。
3.4 扩容策略与数据迁移
随着业务的增长，分库分表系统不可避免地需要扩容。基于我的项目经验和小红书的实践，主要有以下几种扩容策略：
预分片策略。这是一种 “未雨绸缪” 的扩容策略。在系统设计之初，就规划好足够多的虚拟分片，初期只使用其中一部分。例如，规划 32 个分片，但初期只使用 4 个物理库，每个库包含 8 个分片。当需要扩容时，只需要将虚拟分片映射到新增的物理库即可，无需迁移历史数据(59)。
小红书在某些核心业务中采用了这种策略。例如，用户表设计了 64 个虚拟分片，初期使用 16 个物理库。当用户量增长时，只需要增加物理库，然后调整路由规则，就可以实现平滑扩容。这种方式的优点是扩容速度快、对业务影响小，但缺点是初期会浪费一些存储空间(59)。
数据迁移策略。当预分片策略无法满足需求时，就需要进行数据迁移。数据迁移是一个复杂且风险较高的过程，需要精心设计。小红书在进行数据迁移时，通常采用以下步骤：
首先是双写阶段。在新库准备好后，业务同时向旧库和新库写入数据。这一步是为了保证数据不丢失，同时验证新库的功能正确性(45)。
其次是全量迁移。使用工具（如 DataX、Kettle 等）将旧库的历史数据批量迁移到新库。这个过程可能需要数小时甚至数天，期间通过双写保证增量数据的同步(49)。
第三是增量同步。全量迁移完成后，需要继续双写一段时间，确保新库的数据与旧库完全一致。这个阶段可以通过对比新旧库的数据校验和来验证一致性(46)。
最后是切换阶段。在业务低峰期（如凌晨），将读请求切换到新库，然后逐步停止写旧库，最终完成整个迁移过程。这个过程需要监控系统性能，准备好回滚方案(45)。
一致性哈希扩容。对于使用哈希分片的场景，可以采用一致性哈希算法来实现平滑扩容。一致性哈希的原理是将数据和节点都映射到一个环形空间上，当新增节点时，只需要迁移该节点在环空间上的相邻数据。这种方式大大减少了数据迁移量(47)。
在小红书的 Redis 集群中，就采用了一致性哈希来管理数据分布。当需要扩容时，只需要将部分哈希槽迁移到新节点，而不需要迁移所有数据。根据实测，这种方式可以将扩容时的数据迁移量减少到原来的 1/10 以下(47)。
在线扩容技术。对于一些特殊的业务场景，可能无法接受停机时间，这就需要在线扩容技术。小红书在使用 TiDB 作为存储时，就充分利用了其在线扩容的能力。TiDB 可以在不影响业务的情况下，动态增加存储节点，数据会自动在节点间迁移，实现真正的在线扩容(70)。
四、小红书业务场景实战分析
4.1 热门贴分库分表设计
小红书的热门贴是平台的核心业务之一，每天有数以亿计的用户访问这些内容。如何设计一个高效的分库分表方案来支撑这种高并发场景，是技术团队面临的重大挑战。
热门贴业务架构图：
业务特点分析。小红书的热门贴具有以下特征：一是读多写少，一篇热门贴可能有百万级的阅读量，但只有作者可以修改；二是访问集中，热门贴的访问量可能是普通帖子的数百倍，形成明显的热点；三是关联查询多，用户查看帖子时，通常还会查看作者信息、评论、点赞等数据(11)。
基于这些特点，小红书采用了一种复合的分库分表策略。首先，按业务将数据分为几个核心模块：帖子主表（存储帖子基本信息）、用户表（存储作者信息）、评论表（存储评论内容）、点赞表（存储点赞记录）等。这些表分布在不同的数据库中，实现了业务隔离。
帖子主表的分片策略。对于帖子主表，小红书采用了 “时间范围 + 热度分级” 的混合分片策略。具体来说，帖子按发布时间分为多个时间片（如每月一个分片），同时根据热度将帖子分为不同级别。普通帖子存储在常规分片中，热门帖子则存储在专门的热点分片中(83)。
这种设计的好处是明显的。首先，时间分片保证了历史数据的有序性和可管理性，旧数据可以方便地归档。其次，热度分级避免了热门帖子对常规分片的冲击，热点分片可以配置更高的硬件资源，专门处理高并发读请求(83)。
评论数据的存储优化。评论是帖子的重要组成部分，也是访问热点之一。小红书的评论表采用了 “帖子 ID + 用户 ID” 的复合分片键。这种设计有两个好处：一是同一个用户对不同帖子的评论会分散存储，避免了单个用户的评论数据过度集中；二是同一帖子的评论会存储在相邻的分片上，查询时可以快速定位(85)。
为了进一步优化评论的查询性能，小红书还采用了索引优化策略。在评论表上创建了多个索引，包括按帖子 ID 的索引（用于查询某帖子的评论）、按用户 ID 的索引（用于查询某用户的评论）、按时间的索引（用于查询最新评论）等。这些索引大大提升了不同场景下的查询效率(58)。
点赞数据的分布式处理。点赞是小红书的核心互动行为之一，具有极高的并发量。为了处理这种高并发场景，小红书的点赞数据采用了分布式存储方案。具体来说，点赞数据被分散存储在多个 Redis 实例中，每个实例负责一部分用户的数据。当用户点赞时，根据用户 ID 路由到对应的 Redis 实例，执行原子递增操作(18)。
这种设计充分利用了 Redis 的高性能和原子操作特性，保证了点赞计数的准确性和高性能。同时，通过一致性哈希算法管理 Redis 节点，可以在扩容时实现平滑迁移(18)。
4.2 数据倾斜与热点数据处理
数据倾斜和热点数据是分库分表系统面临的共性问题，小红书在这方面积累了丰富的经验。
数据倾斜的识别与监控。小红书建立了完善的数据倾斜监控体系。通过定期统计各分片的数据量、查询耗时、CPU 使用率等指标，可以及时发现数据倾斜问题。例如，当某个分片的查询耗时是其他分片的 3 倍以上，或者 CPU 使用率超过 80% 时，系统会自动报警(69)。
在我的代金券项目中，我们也采用了类似的监控策略。通过监控发现，某些用户 ID 对应的分片数据量达到了其他分片的 10 倍，查询耗时从 200ms 飙升到 2 秒。这种监控体系帮助我们及时发现了问题，避免了系统崩溃(80)。
热点数据的分级处理策略。小红书根据数据的访问热度，将其分为不同级别，并采用相应的处理策略：
-
一级热点（如明星发布的新帖、热门活动）：访问量可能达到每秒百万级。这类数据会被直接缓存在 CDN 和边缘节点，用户就近访问，减少对核心系统的压力(74)。
-
二级热点（如头部博主的优质内容）：访问量达到每秒万级。这类数据会被加载到 Redis 集群的热数据节点中，使用 LRU 策略管理，保证热点数据常驻内存(74)。
-
三级热点（如普通用户的优质内容）：访问量相对较低。这类数据存储在 MySQL 的主从集群中，通过增加读副本的方式分散读压力(78)。
动态分片调整机制。面对动态变化的热点，静态的分片策略往往无法适应。小红书在某些场景下采用了动态分片技术。例如，当检测到某个帖子成为热点时，系统会自动为其分配更多的存储资源，或者将其数据分散到多个分片上(69)。
在我的代金券项目中，我们尝试了一种 “虚拟节点” 的方案。每个物理分片被虚拟成多个节点，当某个用户的数据量过大时，自动将其分散到多个虚拟节点上。这种方式不需要修改业务代码，通过路由层的调整就可以实现数据的重新分布(69)。
缓存预热与降级策略。对于可以预测的热点（如大型活动、明星入驻等），小红书会提前进行缓存预热。通过分析历史数据和当前趋势，预测可能成为热点的内容，提前加载到各级缓存中。这样，当热点真正出现时，大部分请求可以直接从缓存中获取，不会对数据库造成冲击(74)。
同时，小红书还实现了完善的降级策略。当系统检测到某个服务的负载过高时，会自动降级部分非核心功能。例如，在热点帖子的详情页中，如果评论服务过载，可以先展示部分评论，或者将评论加载改为异步方式，保证核心的帖子内容可以正常访问。
实际效果评估。通过这些综合措施，小红书在处理热点数据方面取得了显著成效。根据公开数据，在 2024 年的 “618” 大促期间，小红书的热门贴访问量达到了平时的 5 倍，但系统依然保持稳定运行。通过多级缓存和智能路由，热点数据的访问延迟控制在 50ms 以内，用户体验没有受到明显影响(78)。
在我的代金券项目中，通过实施类似的策略，数据倾斜问题得到了有效缓解。通过将热点用户的数据分散到多个虚拟节点，将原本 10 倍的数据倾斜降低到 2 倍以内。同时，通过缓存热点用户的代金券列表，将这些用户的查询响应时间从 2 秒降低到 200ms 以内，基本恢复到了正常水平(68)。
五、面试经验总结与技术思考
5.1 面试高频问题汇总
基于我在小红书的面试经历和对技术社区的观察，分库分表相关的问题在 Java 开发工程师面试中出现频率极高。以下是我总结的高频问题及回答要点：
分片策略选择问题。面试官经常会问：“你在项目中使用过哪些分库分表策略？它们各自的优缺点是什么？” 这个问题考察的是候选人对不同策略的理解和实践经验。
我的回答会结合实际项目展开：“在代金券项目中，我们主要使用了按用户 ID 哈希分片的策略。这种策略的优点是数据分布相对均匀，90% 以上的查询可以路由到单个分片。缺点是遇到活跃用户时会出现数据倾斜，比如有个用户的代金券数量达到了 10 万张，导致所在分片的负载是其他分片的 10 倍。” 然后我会对比范围分片、按业务拆分等策略，分析各自的适用场景。
分片键设计问题。“如何选择合适的分片键？” 这是另一个必问问题。我会从高基数、业务关联、稳定性等原则出发，结合具体案例说明。比如：“在设计分片键时，我们遵循三个原则。第一是高基数，选择值域范围大的字段，避免使用性别、地区等低基数字段。第二是业务关联，分片键应该与主要查询条件一致，比如用户 ID 适合用户维度的查询。第三是稳定性，分片键一旦确定就不要修改，否则需要迁移所有数据。”(25)
分布式事务处理问题。“分库分表后如何处理跨库事务？” 这个问题考察候选人对分布式事务的理解。我会介绍 2PC、TCC、Saga、本地消息表等方案，并说明各自的适用场景：“在我们的项目中，对于核心业务（如代金券发放）使用了 TCC 方案，因为需要强一致性。对于非核心业务（如活动统计）使用了本地消息表方案，通过最终一致性保证数据完整。在小红书的实践中，他们会根据不同场景选择不同的方案，比如支付场景用 2PC，订单场景用 TCC，异步流程用 Saga。”
跨库查询优化问题。“如何优化跨库查询？” 这是考察候选人解决实际问题的能力。我会从多个角度回答：“首先是通过数据冗余避免跨库查询，比如在订单表中冗余存储用户昵称。其次是使用全局表，将字典数据同步到每个库。第三是引入搜索引擎，比如用 ES 处理复杂查询。最后是使用分布式查询框架，如 Sharding-JDBC，但要注意性能问题，16 个分片的跨库查询可能比单库慢 10 倍以上。”(58)
数据倾斜解决方案。“遇到数据倾斜如何处理？” 这个问题直接关联到我的项目经验。我会详细描述问题发现和解决过程：“在代金券项目中，我们通过监控发现了数据倾斜问题，某个分片的 CPU 使用率达到 98%。我们采取了几个措施：一是将热点用户的数据分散到多个虚拟节点；二是使用 Redis 缓存热点用户的代金券列表；三是调整分片策略，对高频用户使用单独的分片。通过这些措施，将数据倾斜从 10 倍降低到 2 倍以内，查询性能恢复正常。”(69)
扩容策略问题。“如何设计可扩展的分库分表方案？” 这个问题考察系统设计能力。我会介绍预分片、一致性哈希、在线扩容等技术：“我们在设计时采用了预分片策略，初期设计 32 个虚拟分片，只使用 8 个物理库。当需要扩容时，只需要增加物理库，将虚拟分片映射过去即可。同时，我们对部分场景使用了一致性哈希算法，这样扩容时只需要迁移 1/4 的数据。在小红书，他们还使用了 TiDB 这样的分布式数据库，可以真正实现在线扩容，无需停机。”(45)
5.2 技术深度要求分析
通过面试经历，我发现小红书对 Java 开发工程师在分库分表方面的技术要求呈现出 “广度与深度并重” 的特点。
基础原理的深度理解。面试官不会满足于表面的使用经验，而是会深入追问底层原理。例如，在问到 “为什么选择 ReentrantLock 而不是 synchronized” 时，我不能只说 “ReentrantLock 更灵活”，而要深入到 AQS 的实现原理：“ReentrantLock 基于 AQS 实现，通过 volatile 修饰的 state 变量表示锁状态，通过 CLH 队列管理等待线程。它支持可中断锁、公平锁、条件变量等高级特性，在高并发场景下性能更好。在我们的项目中，通过将全局锁改为分片锁，接口吞吐量提升了 2 倍。”
性能优化的实战经验。小红书非常看重候选人的性能优化能力。在面试中，我被问到了很多具体的性能问题，比如 “如何优化分库分表后的查询性能？” 我会结合具体数据回答：“在我们的项目中，通过分析慢查询日志，发现跨库查询占了总查询时间的 80%。我们采取了几个优化措施：一是增加冗余字段，将常用的关联数据直接存储在主表中；二是使用索引优化，在经常查询的字段上创建索引；三是实施查询缓存，将热门查询结果缓存 1 分钟。通过这些优化，整体查询性能提升了 5 倍，从平均 2 秒降低到 400 毫秒。”
故障排查与问题解决能力。“线上出现数据倾斜导致的性能问题，你会如何排查和解决？” 这类问题考察候选人的实战能力。我会描述一个完整的问题解决流程：“首先，我会通过监控系统查看各分片的负载情况，确定是否真的是数据倾斜。然后，通过慢查询日志分析具体是哪些 SQL 语句导致了性能问题。接着，分析这些 SQL 的执行计划，找出是否存在全表扫描或跨库查询。最后，根据分析结果制定解决方案，可能包括优化查询语句、调整分片策略、增加缓存等。在我们的项目中，通过这种方法成功解决了多次性能问题。”(9)
架构设计与技术选型能力。“如果让你重新设计分库分表方案，你会怎么做？” 这类问题考察候选人的架构思维。我会从业务特点出发，提出一个综合方案：“基于之前的经验教训，我会设计一个混合架构。核心业务（如用户、订单）采用按业务拆分，保证业务独立性。大表（如评论、日志）采用时间分片 + 哈希分片的复合策略。对于热点数据，使用多级缓存架构，将访问频率最高的数据放在 Redis 中。同时，预留在线扩容能力，使用 TiDB 或自研的分布式存储系统，支持数据的自动均衡。”(70)
技术趋势与前沿技术了解。小红书的面试官还会关注候选人对新技术的了解。例如，“你了解 TiDB、OceanBase 等分布式数据库吗？” 我会介绍这些新技术的特点：“TiDB 是一个开源的分布式关系型数据库，采用 Shared Nothing 架构，支持自动分片、在线扩容、事务一致性等特性。在处理海量数据时，它可以将数据自动分散到多个节点，每个节点存储 64MB 的数据块。当某个节点负载过高时，会自动将部分数据迁移到其他节点。相比传统的分库分表中间件，TiDB 提供了更好的性能和可扩展性。”(70)
5.3 经验分享与同行讨论
基于这次面试经历和项目实践，我想与同行分享一些思考和建议。
从失败中学习的重要性。我的代金券项目经历是一次宝贵的失败经验。通过这次经历，我深刻理解了理论与实践的差距。在学校学到的分库分表理论看似完美，但在实际应用中会遇到各种意想不到的问题。比如，我们在设计时只考虑了数据的均匀分布，却忽略了业务场景的特殊性。这提醒我们，技术方案必须结合具体业务，不能照搬理论。
我建议同行在设计分库分表方案时，要进行充分的业务调研和数据模拟。可以通过分析历史数据，找出可能的热点和倾斜模式。同时，要预留足够的监控手段，及时发现和处理问题。最重要的是，要保持学习的心态，从每次失败中总结经验教训(71)。
技术选型的平衡艺术。在选择分库分表策略时，没有绝对正确的方案，只有最适合的方案。按业务拆分适合业务模块清晰的系统，可以实现业务隔离和独立扩展，但会增加跨库事务的复杂度。范围分片适合时间序列数据，查询效率高，但可能导致冷热数据不均。哈希分片数据分布均匀，但扩容困难。
我建议在选型时采用 “合适优于完美” 的原则。根据业务特点、数据规模、团队能力等因素综合考虑。可以先从简单的方案开始，比如先按业务拆分，然后在大表上实施水平分片。随着业务发展，逐步演进到更复杂的架构。记住，技术是为业务服务的，不要为了技术而技术(42)。
持续优化的必要性。分库分表不是一次性工程，而是一个持续优化的过程。业务在不断变化，数据特征在不断演进，技术方案也需要随之调整。在小红书的实践中，他们会定期评估现有架构，根据业务发展和技术趋势进行优化升级。
我建议建立一个持续优化的机制。定期分析系统性能数据，找出瓶颈和改进空间。关注业界的新技术和最佳实践，适时引入新的解决方案。同时，要建立完善的文档体系，记录每次优化的过程和效果，为后续的优化提供参考。只有这样，才能保证系统始终保持良好的性能和可扩展性(48)。
团队协作与知识共享。分库分表涉及多个技术领域，包括数据库设计、分布式系统、性能优化等，很少有人能精通所有方面。因此，团队协作至关重要。在我的项目中，DBA 团队负责数据库性能优化，中间件团队负责分库分表中间件的维护，应用开发团队负责业务逻辑实现，监控团队负责系统性能监控。大家各司其职，密切配合，共同解决遇到的问题。
我建议在团队中建立技术分享机制，定期组织技术沙龙，分享项目经验和技术心得。同时，要重视知识沉淀，将项目中的经验教训整理成文档，形成团队的知识库。只有整个团队的技术水平提升了，才能设计出更好的技术方案(5)。
最后，我想强调的是，分库分表虽然是一个技术难题，但也是一个提升技术能力的好机会。通过深入研究和实践，我们可以学到分布式系统设计、数据库原理、性能优化等多方面的知识。这些经验不仅对当前的工作有帮助，也会成为我们职业发展的宝贵财富。希望我的经验分享能对同行有所启发，也期待大家分享自己的经验，共同进步。
参考资料
[1] 【上海 后端开发工程师-IDC/数据中心/服务器招聘】-小红书上海招聘信息-猎聘 https://m.liepin.com/job/1967679857.shtml?pgRef=
[2] 24届Java开发实习-牛客网 https://www.nowcoder.com/jobs/detail/152342
[3] 小红书 正在招聘 【25届校招】数据开发工程师 -实习僧 https://www.shixiseng.com/intern/inn_9jxg5joo0zjn?pcm=pc_SearchList
[5] 快速梳理互联网开发岗位的通用要求_互联网技术运用岗位要求-CSDN博客 https://blog.csdn.net/sluck_0430/article/details/136460902
[6] 小红书面试经验:Java与技术深度考察,-CSDN博客 https://blog.csdn.net/qq_41535923/article/details/131841678
[8] 小红书Java面试题及答案(现场面试39题实拍) – mikechen https://mikechen.cc/20424.html
[9] 小红书Java后端一面，被问麻了_小红书java面试-CSDN博客 https://blog.csdn.net/Javatutouhouduan/article/details/131724556
[10] 小红书 Java 面试 | 小林coding | Java面试学习 https://xiaolincoding.com/backend_interview/internet_medium/xiaohongshu.html
[11] React Native零基础全栈贯通:2023新版+小红书APP全流程实战在移动应用开发领域，React Native - 掘金 https://juejin.cn/post/7546507803332280371
[12] React Native从0到1:跨平台开发精讲 + 小红书APP全栈实战一、跨平台开发技术演进与React Nativ - 掘金 https://juejin.cn/post/7546326670678097946
[13] 小红 书 宣布 开源 其 首个 自 研 大模型 dots . llm 1 小红 书 作为 一家 社交 平台 ， 在 人工 智能 领域 一直 保持 着 低调 的 姿态 。 然而 近日 ， 小红 书 发布 了 其 首个 自 研 大模型 dots . llm 1 ， 引发 广泛 关注 。 该 模型 拥有 1420 亿 参数 ， 训练 使用 了 11.2 万亿 高 质量 token 的 数据 ， 性能 堪比 阿里 Qwen 3 - 32B 模型 。 dots . llm 1 采用 了 Mixture of Experts 架构 ， 在 推理 过程 中 仅 激活 140 亿 参数 ， 大大 降低 了 训练 和 推理 的 成本 。 据 小红 书 技术 团队 介绍 ， 此 模型 在 中英文 通用 场景 、 数学 、 代码 、 对齐 任务 上 表现 出色 ， 特别 是 在 中文 任务 中 ， CLUE WSC 评测 得分 高达 92 . 6 分 ， 达到 业界 领先 水平 。 小红 书 通过 引入 Interleaved 1 F1 B with All to All overlap 和 Group edGE MM 优化 技术 ， 显著 提升 了 计算 效率 。 随着 AI 技术 的 不断 进步 ， 小红 书 正 积极 布局 大模型 领域 ， 力求 在 未来 的 工作 中 开发 出 更加 强大 的 模型 。 # 小红 书 # 自 研 大模型 dots llm 1
[14] 长在云原生架构上的小红书-中国卓越技术团队访谈录-极客时间 https://time.geekbang.org/column/article/468594
[15] 小红书自研KV存储架构如何实现万亿量级存储与跨云多活_小红书 新增 存储 pb-CSDN博客 https://blog.csdn.net/REDtech_1024/article/details/130030150
[16] 万字解读:小红书是怎么用云的?_InfoQ http://m.toutiao.com/group/7498620063344362018/?upstream_biz=doubao
[17] 小红书鸿蒙 OS 下的性能优化探索与实践|os|sdk|小红书|性能优化|知名企业|网络信息_手机网易网 https://m.163.com/dy/article/JSKRF9090511D3QS.html?clickfrom=subscribe
[18] 小红书KV存储架构:万亿级数据与跨云多活不在话下_小红书信息架构-CSDN博客 https://blog.csdn.net/m0_60259116/article/details/133353395
[19] 小红书数据架构的演进——基于通用增量计算构建全增量实验数仓生产新范式📌 导读: 小红书App是一个聚焦年轻人的生活兴趣 - 掘金 https://juejin.cn/post/7591786340322476066
[20] 当你 的 数据 达到 千万 级 ， 这 招 是 救命稻草 # 企业 数字化 转型 # 软件 开发 知识 # 乐山 软件 开发 https://www.iesdouyin.com/share/video/7600223586506280192/?region=&mid=7600223666114562870&u_code=0&did=MS4wLjABAAAANwkJuWIRFOzg5uCpDRpMj4OX-QryoDgn-yYlXQnRwQQ&iid=MS4wLjABAAAANwkJuWIRFOzg5uCpDRpMj4OX-QryoDgn-yYlXQnRwQQ&with_sec_did=1&video_share_track_ver=&titleType=title&share_sign=tGqvLD78m02e.TLeRN66zH_pVhE1_ypiEjwXKMXLKKw-&share_version=280700&ts=1771581869&from_aid=1128&from_ssr=1&share_track_info=%7B%22link_description_type%22%3A%22%22%7D
[21] 千万级大表分库分表设计:架构师视角的原理、实战与避坑指南_从程序员到架构师 http://m.toutiao.com/group/7579202979677438499/?upstream_biz=doubao
[22] 小红书湖仓架构的跃迁之路_StarRocks_InfoQ写作社区 https://xie.infoq.cn/article/6d32a69100fff1b9cd7e8489a
[23] ClickHouse 存算分离改造:小红书自研云原生数据仓库实践 - 智源社区 https://hub.baai.ac.cn/view/30838
[24] 分片键选user_id还是order_id?为什么?_用户表分片键如何选择-CSDN博客 https://blog.csdn.net/qq_35426036/article/details/147505919
[25] 分片键选错了，你的数据库分片就是"灾难现场"!一、开场白:分片键，数据库分片的"命门" 还记得第一次做数据库分片时，我天 - 掘金 https://juejin.cn/post/7535758155694342185
[26] 分布式数据库架构设计中的数据分片策略:从理论到实践的深度探索-天翼云开发者社区 - 天翼云 https://www.ctyun.cn/developer/article/764990916010053
[28] 分库分表确定分片数量_分库分表如何确定库和表的数量-CSDN博客 https://blog.csdn.net/weixin_39304656/article/details/146497789
[29] 平台规则变动时的应对策略:稳住基本盘，寻找新机会_幸运橙子 http://m.toutiao.com/group/7598134588883354166/?upstream_biz=doubao
[30] 视频与图文笔记:平台流量倾斜的真相_幸运橙子 http://m.toutiao.com/group/7598146829850624518/?upstream_biz=doubao
[32] 备战618!品牌如何在小红书抢流量 | 人人都是产品经理 https://www.woshipm.com/share/6202109.html
[33] 数据应用:“对标观测”功能，小红书博主如何实时盯紧全行业爆款榜、话题榜?_笔记_流量_内容 https://m.sohu.com/a/987033851_121804176/
[34] 分库分表及其类型(策略)-CSDN博客 https://blog.csdn.net/weixin_43521001/article/details/148765442
[35] 数据库分库分表方案实战案例指南:5大方案+避坑技巧(附真实项目案例)-腾讯云开发者社区-腾讯云 https://cloud.tencent.com/developer/article/2624397?policyId=1003
[36] 哈希 vs 范围 分表 ！ 王二 实测 查询 速度 差 出 天际 面试 被 问 分表 策略 ？ 3 秒 答 完 面试 官 直接 录用
[37] 千万级大表分库分表设计:架构师视角的原理、实战与避坑指南_从程序员到架构师 http://m.toutiao.com/group/7579202979677438499/?upstream_biz=doubao
[38] 浅谈MySQL分库分表:从原理到分布式事务与全局ID设计随着业务的快速发展，单机MySQL数据库在数据量和并发访问方面逐 - 掘金 https://juejin.cn/post/7545902821604278281
[39] 分库分表后的“雷区“:七大问题与解决方案全解析_分库分表会有什么问题怎么解决-CSDN博客 https://blog.csdn.net/qq_44378083/article/details/149103997
[41] 分库分表终极方案:TiDB/OceanBase凭什么替代中间件?_无心水 http://m.toutiao.com/group/7572959528581382691/?upstream_biz=doubao
[42] mysql:深度解析分库分表:问题全景与阿里/字节级解决方案-CSDN博客 https://blog.csdn.net/weixin_43290370/article/details/149601600
[43] 数据库分库后可能会产生的问题以及解决方案:分布式事务一致性问题、跨节点关联查询问题、跨节点分页、排序函数问题、主键避重。_数据库分库分表存在分布式事务的问题怎么解决-CSDN博客 https://blog.csdn.net/m0_56615376/article/details/137226884
[44] 分库分表 - 数据库博客-OceanBase https://open.oceanbase.com/blog/25399168000
[45] 【分布式利器:分库分表】5、分库分表避坑指南:从设计到落地_老旧系统分库分表改造-CSDN博客 https://wuxinshui.blog.csdn.net/article/details/154882383
[46] MySQL分库分表架构设计与实践指南-CSDN博客 https://blog.csdn.net/weixin_47233946/article/details/148777563
[47] 数据库分库分表方案实战案例指南:五大方案+避坑技巧(附真实项目案例)-51CTO.COM https://www.51cto.com/article/834810.html
[48] 🗂️ 分库分表后的性能优化:驾驭分布式数据库!📖 为什么要分库分表? 想象一个图书馆: 单库单表:所有书都堆在一个 - 掘金 https://juejin.cn/post/7566627744873234458
[49] 阿里二面:10亿级分库分表，如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图，看完直接上offer!-阿里云开发者社区 https://developer.aliyun.com/article/1656181
[50] MySQL分库分表实战:从0到1实现指南，高频坑全规避_女码农的重启 http://m.toutiao.com/group/7600590378097459721/?upstream_biz=doubao
[51] 分布式事务实战指南:从理论到落地，解决数据一致性难题-CSDN博客 https://blog.csdn.net/2503_94434664/article/details/156829663
[52] 【分布式事务】从基础概念到现代解决方案的全面解析-CSDN博客 https://blog.csdn.net/weixin_36082987/article/details/149170394
[53] SpringCloud专题 - 四种主流分布式事务模式_首席架构师 http://m.toutiao.com/group/7527119825437491758/?upstream_biz=doubao
[55] 架构之分布式事务_transfertccservice-CSDN博客 https://blog.csdn.net/IOIO_/article/details/157394858
[56] 图解7种分布式事务模型(一文带你掌握分布式事务)-腾讯云开发者社区-腾讯云 https://cloud.tencent.com.cn/developer/article/2509923
[57] 数据库分库后可能会产生的问题以及解决方案:分布式事务一致性问题、跨节点关联查询问题、跨节点分页、排序函数问题、主键避重。_数据库分库分表存在分布式事务的问题怎么解决-CSDN博客 https://blog.csdn.net/m0_56615376/article/details/137226884
[58] 分库分表后的“雷区“:七大问题与解决方案全解析_分库分表会有什么问题怎么解决-CSDN博客 https://blog.csdn.net/qq_44378083/article/details/149103997
[60] 分库分表踩坑!分布式事务 5 种实战方案，从入门到精通_女码农的重启 http://m.toutiao.com/group/7573141225176433204/?upstream_biz=doubao
[61] 分库分表一体化升级解决方案-数据库解决方案-分布式数据库-OceanBase https://www.oceanbase.com/solution/sharding
[62] Java分布式常提到的面试题包含答案_分布式面试题java-CSDN博客 https://blog.csdn.net/huayula/article/details/146331289
[64] 分库分表常见问题参考答案(收录25年至今的牛客面经)_牛客网 https://www.nowcoder.com/feed/main/detail/aa3f5b34ecc04ea8ae7ea71aa1d9372d
[65] 面试系列-mysql分库分表 -_mob64ca13f2b62d的技术博客_51CTO博客 https://blog.51cto.com/u_16213561/14465923
[66] 分库分表夺命连环问 https://m.nowcoder.com/feed/main/detail/eff4328906fa415694b82897bb199cc5?urlSource=home-api
[67] 【分布式利器:分库分表】5、分库分表避坑指南:从设计到落地_老旧系统分库分表改造-CSDN博客 https://blog.csdn.net/RickyIT/article/details/154882383
[68] 分库分表后，如何解决因热点key导致的数据倾斜问题?_编程语言-CSDN问答 https://ask.csdn.net/questions/9238101
[70] 分库分表终极方案:TiDB/OceanBase凭什么替代中间件?_无心水 http://m.toutiao.com/group/7572959528581382691/?upstream_biz=doubao
[71] 分库分表后，我后悔了摘要:从一次"单表8000万数据分表后发现更慢了"的架构灾难出发，深度剖析分库分表的5大难题。通过分 - 掘金 https://juejin.cn/post/7563108340537835574
[72] 分库分表方案中的数据倾斜问题及解决方案详解_分库分表数据倾斜的解决方法-CSDN博客 https://blog.csdn.net/lssffy/article/details/142614424
[73] 高并发下分布式数据库性能下降的解决方法_对高并发,海量数据性能差的是-CSDN博客 https://blog.csdn.net/2409_89014517/article/details/148811547
[74] 从Redis热Key到湖仓一体:大厂热点数据存储实战拆解(落地指南)_从程序员到架构师 http://m.toutiao.com/group/7600707643220558372/?upstream_biz=doubao
[75] 分库分表一体化升级解决方案-数据库解决方案-分布式数据库-OceanBase https://www.oceanbase.com/solution/sharding
[76] 星环 分布式 交易 型 数据库 - Transwarp Kun DB 星环 分布式 交易 型 数据库 （ Transwarp Kun DB ） 是 星环 基于 分布式 技术 自主 研发 的 交易 型 数据库 ， 提供 完整 的 关系型 数据库 的 能力 ， 具备 可 扩展 、 高 并发 、 高 可用 、 数据 灾备 等 特性 。 主要 面向 高 并发 、 大 数据 量 的 交易 型 业务 场景 。 也 可以 支持 传统 企业 生产 、 经营 和 管理 业务 ， 在 技术 上 提供 更好 的 可 运维 性 、 数据 一致性 和 可靠性 保证 ， 满足 自主 可控 的 数据 系统 建设 的 需求 。
[77] 基于 SQL 语句执行频率的热点数据识别与缓存策略优化实践方案_基于sql语句执行频率的热点数据识别与缓存策略优化实践方案-CSDN博客 https://blog.csdn.net/jingjing45678/article/details/149779676
[78] 高并发场景解决方案-数据库解决方案-分布式数据库-OceanBase https://www.oceanbase.com/solution/ecommerce
[79] 数据库分库分表方案实战案例指南:5大方案+避坑技巧(附真实项目案例)-腾讯云开发者社区-腾讯云 https://cloud.tencent.com/developer/article/2624397?policyId=1004
[80] Sharding-JDBC 分库分表实战:你踩过的坑，都是性能优化的垫脚石_大龄程序猿小武 http://m.toutiao.com/group/7477230957909606924/?upstream_biz=doubao
[81] 分库分表实战:应对数据增长的扩展策略_分库分表数据增长问题-CSDN博客 https://blog.csdn.net/sinat_27016095/article/details/146897504
[82] 高德 地图 如何 用 国产 数据库 重构 “ 足迹 ” 系统 ？ 高德 为何 放弃 分库 分表 ？ 又 如何 实现 “ 用户 零 感知 ” 的 在线 迁移 ？ # 国产 数据库 # 分布式 数据库 # Ocean Base # 数据库 # 高德 地图 https://www.iesdouyin.com/share/video/7579249234088660243/?region=&mid=7579249351253986090&u_code=0&did=MS4wLjABAAAANwkJuWIRFOzg5uCpDRpMj4OX-QryoDgn-yYlXQnRwQQ&iid=MS4wLjABAAAANwkJuWIRFOzg5uCpDRpMj4OX-QryoDgn-yYlXQnRwQQ&with_sec_did=1&video_share_track_ver=&titleType=title&share_sign=WHs0p_8JevDP11WS64srVVeV07r6gn4ZGOGcX33f_WU-&share_version=280700&ts=1771581904&from_aid=1128&from_ssr=1&share_track_info=%7B%22link_description_type%22%3A%22%22%7D
[83] 千万级大表分库分表设计:架构师视角的原理、实战与避坑指南_从程序员到架构师 http://m.toutiao.com/group/7579202979677438499/?upstream_biz=doubao
[84] 分库分表中如何避免数据热点问题? https://docs.feishu.cn/v/wiki/wikcn6rPh5541ES3bKX9aSQk49e/ae
[85] 外卖霸王餐系统数据库分库分表策略:ShardingSphere实战案例-CSDN博客 https://blog.csdn.net/m0_48183922/article/details/156906932
（注：文档部分内容可能由 AI 生成）
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)