类似抖音系统的高可用系统建构思考 | 豆包MarsCode AI刷题
- 分布式存储系统
- 数据分片与冗余备份：
- 像抖音存储海量视频，要采用数据分片策略。将视频数据按照一定规则（如按用户ID范围、时间范围或者视频类别等）切分成多个数据片，存储在不同的存储节点上。这样能避免单个存储设备容量限制，实现存储的水平扩展。
- 同时，每个数据片都要有冗余备份。例如，采用多副本策略，将每个数据片复制多份存储在不同节点或数据中心。当某个节点出现故障时，能快速从其他副本节点获取数据，保证数据的可用性。
- 存储类型选择与优化：
- 对于频繁访问的热门视频数据，可以使用高性能的固态硬盘（SSD）存储，以提供快速的数据读取速度。而对于访问频率较低的历史视频或者用户备份数据等，可以采用大容量的机械硬盘（HDD）存储，以平衡成本和存储容量。
- 根据视频数据的特点，还可以采用对象存储。对象存储能够更好地管理非结构化数据，如视频文件，并且可以方便地实现数据的分布式存储和访问控制。
- 内容分发网络（CDN）应用
- 全球节点布局：
- 构建类似系统时，要在全球范围内部署CDN节点。考虑目标用户群体的地理分布，在人口密集地区和网络流量大的区域重点部署。例如，在亚洲、欧洲、北美洲等互联网用户集中的地方，设置多个边缘节点，使视频内容能够就近缓存和分发，减少数据传输的延迟。
- 智能缓存策略：
- 制定智能的缓存策略，根据视频的热度、访问频率等因素来决定缓存的时间和位置。对于热门视频，应该在多个边缘节点进行缓存，并且缓存时间可以适当延长。同时，要建立缓存更新机制，当视频内容发生变化（如用户重新编辑上传）时，能够及时更新缓存，确保用户获取到最新的内容。
- 负载均衡机制
- 四层和七层负载均衡结合：
- 在网络层面，采用四层（基于IP和端口）和七层（基于应用层协议，如HTTP）负载均衡相结合的方式。四层负载均衡主要负责将流量均匀分配到后端服务器集群，实现基本的流量分发功能。七层负载均衡则可以根据具体的应用协议（如视频请求的URL、用户身份等）进行更精细的流量调度，将不同类型的视频请求（如不同类别视频的播放请求、上传请求等）发送到最合适的服务器进行处理。
- 动态负载调整：
- 负载均衡器要能够实时监测后端服务器的负载情况，包括CPU使用率、内存占用、网络带宽等指标。根据这些指标动态调整流量分配策略。例如，当某台服务器负载过高时，减少发送到该服务器的流量，将新的请求分配到负载较轻的服务器上，以确保整个系统的性能稳定。
- 微服务架构设计
- 服务拆分与独立部署：
- 将系统按照功能划分为多个微服务，如视频上传服务、视频处理服务、推荐服务、用户关系服务等。每个微服务都可以独立开发、部署和扩展。这样，当某个微服务出现问题或者需要更新升级时，不会影响到其他服务的正常运行，提高了系统的可维护性和灵活性。
- 服务治理与通信：
- 建立服务治理机制，包括服务注册与发现、配置管理、熔断机制等。使用服务注册中心（如Consul、Eureka等）来记录各个微服务的地址和状态，方便服务之间的发现和调用。配置管理中心可以统一管理各个微服务的配置参数，实现配置的动态更新。同时，引入熔断机制，当某个微服务出现故障或者响应时间过长时，能够及时切断对该服务的调用，避免故障扩散，保证系统的整体可用性。
- 实时监控与故障恢复
- 全链路监控系统：
- 构建一个覆盖从用户端到服务器端的全链路监控系统。在用户端，收集视频播放的性能指标，如播放卡顿率、加载时间等；在网络层面，监控网络带宽、延迟、丢包率等；在服务器端，监测各个服务的运行状态、资源使用情况等。通过对这些指标的实时分析，及时发现系统中的潜在问题。
- 自动化故障恢复：
- 对于常见的故障场景，制定自动化的恢复策略。例如，当某个服务器节点出现故障时，自动将该节点从服务集群中移除，并启动备用节点或者在其他节点上重新分配任务；当数据库出现连接故障时，自动进行连接重试或者切换到备用数据库等操作。同时，对于复杂的故障情况，要能够及时通知运维人员，提供详细的故障信息，以便快速定位和解决问题。
- 数据一致性保障
- 分布式事务处理：
- 在涉及多个服务或存储系统的数据操作时，如用户上传视频同时更新用户信息和视频索引信息，需要采用分布式事务处理机制。可以使用分布式事务框架（如Seata）来保证数据的一致性。在事务执行过程中，通过两阶段提交或者补偿机制，确保所有操作要么全部成功，要么全部失败。
- 最终一致性策略：
- 在一些对实时性要求不是特别高的场景下，可以采用最终一致性策略。例如，对于视频的点赞数、评论数等统计信息，允许在短时间内数据的不一致，但通过异步更新的方式，最终使各个存储节点的数据达到一致。可以利用消息队列（如RabbitMQ、Kafka等）来实现异步数据更新，确保系统在高并发情况下的性能和可用性。
