“TikTok 难民”涌入小红书，流量激增迎来用户暴增，而平台并未因流量过载崩溃且保持稳定运行背后的秘密武器是？

“TikTok 难民”涌入小红书，流量激增迎来用户暴增，而平台并未因流量过载崩溃且保持稳定运行背后的秘密武器是？

本文摘录来自：TiDB社区活动上海站

演讲嘉宾：蔡金龙（小红书关系数据库负责人）

引言

在当今数字化时代，社交媒体平台如小红书在全球范围内迅速崛起，积累了庞大的用户体和海量的数据。小红书以其独特的内容社区、商业广告和电商交易业务板块，成为了 亿人生活兴趣爱好的聚集地。然而，随着业务的高速增长，小红书面临着诸多技术挑战，尤其是在数据库管理方面。如何选择合适的数据库技术来应对数据规模飙升带来的数据存储、处理和管理需求，以及实现降本增效的目标，成为了小红书技术团队的关键任务。本文将深入探讨小红书在这一过程中如何利用 TiDB 来应对这些挑战，分享其实践经验和成果。

小红书 TiDB 的使用情况

小红书使用 TiDB 总体集规模：拥有过万核的TiDB集，集数量数十套，存储使用量在数百 TB左右。主要承接业务及使用场景：

1、报表大盘：用于报表以及部分大屏展示。

使用场景：业务使用中涉及复杂SQL（包括各种函数、JSO、子查询、JOI关联等），主要为OLAP场景。

2、风控审核：很多风控业务历史数据直接使用TiDB，OLTP和OLAP集均存在。

使用场景：涉及风控审核相关业务，对数据处理和查询有一定要求，涵盖不同类型的集应用。

、中台技术：承担了数十个业务，包括审核、广告、笔记发布等服务。

使用场景：有多个维度的查询，以OLTP为主，支持多种业务的日常运营和数据处理。

4、离线服务：主要以数仓的抽数集为主。

使用场景：专注于OLAP场景，为离线数据分析和处理提供支持。

5、其他：涵盖部分历史集以及不适合MySQL的业务。

使用场景：OLTP和OLAP集均有涉及，满足多样化的业务需求和数据处理模式。

小红书数据规模飙升情况及技术挑战

业务多元与存储性能需求

小红书的业务涵盖了搜索、推荐、AI、视频、交易等多个领域，业务的多元化导致了对数据库存储能力和性能的多样化要求。例如，在用户浏览小红书内容时，需要快速获取大量的图文、视频等信息，这就要求数据库具备高并发读取和低延迟响应的能力；而在电商交易环节，需要确保订单数据的准确存储和快速处理，对数据库的事务处理能力提出了较高要求。

随着业务的不断发展，数据量呈爆炸式增长。小红书的数据库规模年复合增长率超 100%，这种高速增长使得原有的数据库系统逐渐难以支撑业务发展诉求。传统的数据库架构在面对如此大规模的数据增长时，往往会出现性能瓶颈，如查询响应时间延长、数据写入延迟等问题，严重影响用户体验和业务运营效率。

运维困境与稳定性挑战

从运维视角来看，小红书面临着一系列严峻的问题。首先，运维工具相对匮乏，DBA兜底现象严重，导致运维负荷不堪重负。在处理数据库故障和问题时，缺乏有效的自动化工具和系统，大部分工作需要人工手动完成，这不仅效率低下，而且容易出错。

其次，数据库相关信息呈点状散落和割裂状态，异常定位时间长。当出现问题时，运维人员需要从多个分散的数据源收集和整合信息，才能进行故障诊断和定位，这一过程耗费大量时间和精力。而且，由于缺乏有效的体系化处理机制，小问题容易演变成大事故，运维人员往往处于被动的“救火”状态，头痛医头脚痛医脚，缺少系统化的运营思路，难以从根本上解决问题和预防故障的发生。

此外，在经济下行的大环境下，市场竞争从增量拓展转向存量厮杀，降本成为企业的战略优选事项。小红书需要在保证业务稳定运行的前提下，降低数据库的运营成本和资本支出，这对数据库技术和管理策略提出了更高的要求。

小红书的数据库选型思路

基于业务需求的定制化选型

小红书坚持问题导向，根据不同业务场景的需求定制数据库解决方案。其业务的多样性决定了需要多种类型的数据库来支撑。对于数据量较小、查询少量数据且要求低时延的场景，如部分缓存数据和用户快速查询场景，可能会选择 Redis 等内存数据库；对于结构化数据且规模较小的业务，如一些简单的订单数据，可能会采用 MySQL 等关系型数据库。

而对于大数据量存储且对弹性能力有较高要求的场景，尤其是在 TP（事务处理）要求较高并发处理的情况下，TiDB 成为了重要的选择之一。TiDB 能够很好地应对小红书数据规模飙升带来的数据存储和处理压力，无需进行复杂的分库分表操作，降低了架构的复杂性和运维成本。

在数据类型方面，如果涉及到非结构化或半结构化数据，如用户生成的多媒体内容、文本评论等，会选择相应的 oSQL 数据库；对于图数据相关的业务，如用户关系图谱、内容推荐图谱等，则会采用图数据库。通过构建丰富的数据库产品生态，小红书能够更好地赋能不同形态的业务发展诉求，确保每个业务场景都能得到最适合的数据库支持。

场景驱动与局部领先策略

在数据库选型过程中，小红书以场景为驱动，以需求为牵引，以实际为导向，不追求大而全的数据库解决方案，而是寻求在各个特定场景下的局部领先。例如，在报表大盘业务中，需要处理复杂 SQL 查询（包括各种函数、JSO、子查询、JOI 关联等），且涉及大量数据分析（OLAP），TiDB 能够凭借其强大的查询处理能力和对复杂数据类型的支持，满足这一业务场景的需求。

在风控审核业务中，虽然部分核心服务已经迁移到 MySQL，但历史上很多业务直接使用 TiDB，且在 OLTP（联机事务处理）和 OLAP 集中均有应用，这体现了 TiDB 在不同业务处理模式下的适应性和灵活性。对于中台技术业务，有多个维度的查询需求，承担了数十个业务，包括审核、广告、笔记发布等服务（以 OLTP 为主），TiDB 的高并发处理能力和良好的扩展性能够有效支持这些业务的稳定运行。

在离线服务方面，主要以数仓的抽数集为主（OLAP 为主），TiDB 也能够提供高效的数据抽取和分析能力，满足数据仓库的建设和运营需求。通过这种场景驱动和局部领先的选型策略，小红书能够充分发挥不同数据库的优势，构建高效、稳定的数据库架构体系。

小红书数据库降本增效经验分享

保稳定与降成本的策略与实践

1、故障处理效率提升

小红书高度重视故障处理效率的提升，将其视为降低成本的关键环节之一。从业务视角来看，故障处理效率的提高能够缩短系统不可用时间，进而提升产品体验，减少业务损失，降低获客和资损成本。

在实际操作中，小红书采取了一系列措施。首先，建立了完善的故障演练机制，通过模拟各种可能出现的故障场景，如批量主库故障、DS 解析错误、CMDB 异常、全局锁、写大事务、大表删除、磁盘 I/O 打满、连接打满、进程异常重启、内存打满、CPU 打满、网络丢包、网络延迟、磁盘单盘夯死等，对系统的稳定性和恢复能力进行全面测试和验证。通过不断地进行故障演练，能够及时发现系统中的潜在问题和薄弱环节，并针对性地进行改进和优化。

同时，加强了 SQL 分析和限流功能。通过对 SQL 语句的执行情况进行实时监测和分析，能够及时发现并处理可能导致性能问题的 SQL 查询，如慢 SQL 等。对于高并发情况下的 SQL 请求，采用限流策略，确保系统资源的合理分配和利用，避免因个别 SQL 查询导致系统性能下降或故障发生。

此外，还注重主动异常诊断和根因定位。利用先进的监测工具和技术，对数据库系统的各项指标进行实时监测，一旦发现异常情况，能够迅速进行诊断和分析，准确出问题的根源。例如，通过对系统日志的深入分析、结合业务反馈和运行时的各种数据指标，能够快速定位到故障发生的具体位置和原因，从而采取有效的措施进行修复。

2、架构评审与改进验收

架构评审是小红书保障数据库稳定性和降低成本的重要手段之一。定期对数据库架构进行全面评审，能够及时发现架构设计中的潜在问题和风险，如不合理的数据分布、低效的存储结构、潜在的性能瓶颈等。在评审过程中，邀请了数据库专家、业务负责人和运维人员等多方面的专业人员参与，从不同角度对架构进行评估和分析，确保评审结果的全面性和准确性。

对于评审过程中发现的问题，制定详细的改进计划，并严格按照计划进行改进和验收。在改进过程中，充分考虑业务的发展需求和未来的扩展性，确保改进后的架构能够更好地支持业务的增长和变化。通过持续的架构评审和改进验收，小红书的数据库架构不断优化，系统的稳定性和性能得到了有效提升。

、流量切换与数据回滚机制

为了确保在故障发生时业务的连续性，小红书建立了完善的读流量切换和写流量切换机制。当数据库节点出现故障或性能问题时，能够迅速将读流量或写流量切换到其他正常节点上，确保用户的请求能够得到及时响应，业务不受影响。

同时，还具备强大的数据回滚能力。在数据出现错误或不一致的情况下，能够快速将数据回滚到之前的某个稳定状态，保证数据的完整性和一致性。这一机制在数据更新、事务处理等过程中发挥了重要作用，有效降低了因数据问题导致的业务风险和损失。

提效率与降成本的平台化建设

1、智能化运维管理平台

小红书致力于打造一个智能化的运维管理平台，以提高数据库运维的效率和质量。该平台提供了丰富的功能，如人机交互的 Web UI 和 Chat 功能导航，方便运维人员进行日常的数据库管理操作。通过 Chat 运维管理和 Chat 智能分析功能，运维人员可以与系统进行自然语言交互，快速获取所需的信息和帮助，如查询数据库状态、执行特定的管理任务、分析性能问题等。

在数据资产方面，平台实现了全方位的管理，包括数据库开发、数据传输与集成、数据库自治、数据应用、数据安全等多个环节。通过资产大盘功能，能够直观地展示数据库的整体情况，如数据存储分布、资源使用情况、性能指标等，方便运维人员进行监控和管理。同时，还提供了详细的资产列表、资产图谱和资产管理功能，对数据库中的各种数据资产进行分类、梳理和管理，确保数据资产的安全和有效利用。

2、自动化与智能化工具集成

在运维管理平台中，集成了大量自动化和智能化的工具，实现了数据库管理的自动化和智能化。例如，在数据传输与集成方面，提供了自动化的数据订阅和导入/导出功能，能够根据预设的规则和任务，自动将数据从不同的数据源传输到数据库中，或者将数据库中的数据导出到其他系统中，大大提高了数据处理的效率。

在数据库自治方面，利用机器学习和人工智能技术，实现了智能分析与定位、故障自愈、异常发现等功能。系统能够自动监测数据库的运行状态，分析性能指标和数据变化趋势，当发现异常情况或潜在故障时，能够自动进行诊断和修复，无需人工干预。这不仅提高了故障处理的速度和准确性，还降低了运维人员的工作强度和工作量。

在数据安全方面，平台提供了完善的权限体系和安全规则配置功能，能够对用户的访问权限进行精细管理，确保数据的安全性和合规性。同时，还具备操作审计功能，对所有的数据库操作进行记录和审计，便于追溯和分析安全事件。

省资源与降成本的架构优化

1、关停并转策略实施

小红书积极实施关停并转的运营策略，以降低数据库的资源消耗和成本。在“关”方面，定期下掉无流量机器，避免资源的浪费。通过对系统的流量监测和分析，能够准确识别出长时间无流量或流量极低的机器，并将其关闭，释放资源。

在“停”方面，停掉无访问业务和库，对于一些已经不再使用或访问频率极低的业务和数据库，及时进行停止和清理，减少不必要的资源占用。在“并”方面，推动多业务库合并，将一些业务相关性较高或数据量较小的数据库进行合并，优化数据存储结构，提高资源利用率。在“转”方面，将部分业务迁移到低配机器上，根据业务的实际需求和性能要求，合理调整资源配置，避免高配机器的过度使用。

2、硬件超售与存算分离架构

在硬件部署方面，小红书采用了硬件超售的策略，通过高密机器多实例部署，实现了硬件资源的最大化利用，降低了硬件成本。在高密机器上运行多个数据库实例，根据业务的负载情况动态分配资源，确保每个实例都能够得到合理的资源保障，同时提高了硬件的整体利用率。

此外，积极推进存算分离架构的应用。存算分离架构将计算和存储资源分离，实现了资源池化和按需分配。在业务高峰期，能够快速为计算节点分配足够的存储资源，满足数据处理的需求；在业务低谷期，释放闲置的资源，降低成本。这种架构还提高了系统的灵活性和扩展性，方便进行资源的动态调整和管理。

小红书选择 TiDB 的理由

针对大数据量存储的弹性优势

在 TP 要求的大数据量存储场景中，TiDB 展现出了卓越的弹性能力。与传统的数据库架构相比，TiDB 无需进行复杂的分库分表操作，避免了由此带来的数据迁移、校验和流量切换等一系列繁琐且容易出错的过程。

TiDB 能够根据业务的负载变化自动进行弹性扩展和收缩，无论是数据量的增长还是并发访问量的增加，都能够轻松应对。当业务量增加时，只需简单地添加 TiDB 节点，系统即可自动实现数据的重新分布和负载均衡，实现性能和存储容量的线性提升。这种弹性能力极大地提高了运维效率，降低了运维成本，为小红书在处理大数据量存储和高并发业务时提供了强有力的支持。

TP + AP 业务的可靠性保障

对于 TP + AP 要求的业务，TiDB 无需维护长链条多组件服务，简化了系统架构，提高了可靠性。在小红书的业务中，如报表大盘和风控审核等业务，既需要处理大量的事务性操作（TP），又需要进行实时的数据分析（AP）。

TiDB 的 HTAP（混合事务/分析处理）架构能够在同一套系统中高效地支持事务处理和数据分析，实现了 TP 和 AP 的统一，且两者互不影响。这意味着在进行事务处理的同时，不会影响数据分析的性能，反之亦然。相比传统的架构，需要搭建多个独立的系统来分别处理 TP 和 AP 业务，TiDB 大大减少了系统的复杂性和维护成本，提高了系统的整体可靠性和稳定性。

多维度优势综合考量

1、研发视角优势：

• 从研发视角来看，TiDB 高度兼容 MySQL 协议，这使得小红书在将原有基于 MySQL 的业务迁移到 TiDB 时，转换过程透明，无需对应用程序进行大规模的修改。研发人员可以继续使用熟悉的 MySQL 语法和开发工具，大大降低了开发成本和迁移风险。
• TiDB 还具备无需分库分表的优势，避免了因分库分表带来的一系列技术难题，如分布式事务处理、数据一致性维护、跨库查询性能等问题。这使得研发人员能够更加专注于业务逻辑的实现，提高了开发效率。

2、运维视角优势：

• 在运维方面，TiDB 的弹性能力使其可水平无限扩展，能够轻松应对业务的快速增长和突发的高负载情况。无论是数据量的指数级增长还是并发访问量的急剧增加，TiDB 都能够通过简单地添加节点来实现性能的线性提升，确保业务的稳定运行。
• TiDB 满足金融级 RPO（恢复点目标）= 0 的要求，这意味着在发生故障时，数据不会丢失，保证了数据的完整性和一致性。同时，故障切换 RTO（恢复时间目标）< 0s，能够在极短的时间内完成故障切换，确保业务的连续性，大大降低了因故障导致的业务损失。
• 此外，TiDB 还具备 PITR（时间点恢复）能力，在数据出现错误或丢失的情况下，能够快速恢复到指定的时间点状态，为数据的安全性提供了有力保障。

、社区视角优势

• TiDB 拥有活跃的社区，用户活跃度高，反馈改进迅速。这使得小红书在使用 TiDB 的过程中，能够及时获取社区的支持和帮助，解决遇到的问题。同时，社区的不断发展和创新也为 TiDB 的功能完善和性能提升提供了源源不断的动力。
• TiDB 的产品使用广泛且持续拓展，这表明其在市场上得到了广泛的认可和应用。小红书选择 TiDB，也能够借助其良好的市场口碑和广泛的用户基础，降低技术选型的风险，确保数据库技术的先进性和可靠性。

结论

小红书在应对数据规模飙升和降本增效的挑战过程中，通过深入分析业务需求和技术现状，选择了 TiDB 作为重要的数据库解决方案，并在实践中取得了显著的成效。TiDB 在大数据量存储的弹性扩展、TP + AP 业务的可靠性保障以及多维度的优势方面，为小红书的业务发展提供了强有力的支持。

通过实施一系列的降本增效策略，小红书在数据库管理方面实现了成本的有效控制和效率的大幅提升。同时，TiDB 的应用也使得小红书的数据库架构更加灵活、稳定和可靠，能够更好地适应业务的快速变化和发展。

未来，随着小红书业务的持续增长和技术的不断创新，相信 TiDB 将继续发挥重要作用，助力小红书在社交媒体领域取得更大的成功。同时，小红书的实践经验也为其他面临类似挑战的企业提供了宝贵的参考和借鉴，推动了数据库技术在行业内的应用和发展。

在数据库技术不断演进的今天，企业需要不断探索和创新，选择最适合自身业务需求的数据库解决方案，才能在激烈的市场竞争中立于不败之地。小红书与 TiDB 的成功合作案例，为企业在数据库选型和应用方面提供了一个生动的范例，展示了如何通过合理的技术选型和有效的管理策略，实现数据规模飙升与降本增效的双赢目标。

活动回顾&ppt下载：