|
|
|
|
@ -0,0 +1,46 @@
|
|
|
|
|
一、系统整体架构
|
|
|
|
|
该音乐搜索系统后端基于 Flask 框架构建，采用了多层架构设计，集成了数据爬取、存储、搜索与展示等核心功能，同时通过 RESTful API 与前端进行交互。系统主要涉及以下关键组件：
|
|
|
|
|
数据爬取层：通过 UnifiedMusicCrawler 类实现对音乐数据的爬取，支持按关键词、分类、艺术家等多种维度获取音乐信息。
|
|
|
|
|
数据存储层：使用 Neo4j 图数据库存储音乐实体（歌曲、艺术家、专辑等）及其关系，同时利用 Elasticsearch 实现高效的全文搜索与数据统计。
|
|
|
|
|
业务逻辑层：封装了数据爬取、存储、搜索的核心逻辑，通过各类方法对外提供统一的操作接口。
|
|
|
|
|
API 层：基于 Flask 定义了丰富的 RESTful API，支持前端页面的各种交互需求，如搜索、数据统计、关系查询等。
|
|
|
|
|
二、核心模块与功能
|
|
|
|
|
（一）数据爬取模块（UnifiedMusicCrawler）
|
|
|
|
|
UnifiedMusicCrawler 是统一的数据爬取入口，负责从外部源获取音乐数据，主要功能包括：
|
|
|
|
|
通用爬取：crawl_massive_data(count) 方法可批量爬取指定数量的音乐数据；search_songs(keyword, limit) 支持按关键词搜索音乐。
|
|
|
|
|
分类爬取：crawl_by_category() 能按音乐类别进行爬取，丰富数据的多样性。
|
|
|
|
|
艺术家定向爬取：search_songs(artist, count) 可针对特定艺术家爬取其相关歌曲。
|
|
|
|
|
（二）数据存储模块
|
|
|
|
|
1. Neo4j 图数据库（MusicGraphDatabase）
|
|
|
|
|
用于存储音乐实体及它们之间的关系，核心功能有：
|
|
|
|
|
实体管理：提供 add_songs_batch(songs) 批量添加歌曲，get_popular_artists(limit) 获取热门艺术家等方法，管理歌曲、艺术家、专辑等实体。
|
|
|
|
|
关系管理：通过 attach_album_by_name_artist 建立歌曲与专辑的关系，get_related_songs(song_id) 获取歌曲的相关歌曲，利用图数据库的特性高效处理实体间的关联。
|
|
|
|
|
统计查询：get_statistics() 可获取数据库中的歌曲、艺术家、专辑等统计信息。
|
|
|
|
|
2. Elasticsearch 搜索引擎（MusicSearchEngine）
|
|
|
|
|
专注于全文搜索与数据统计，主要功能：
|
|
|
|
|
全文搜索：支持多字段（歌曲名、艺术家、专辑、歌词、标签等）的短语精确匹配与模糊匹配，如 search_by_artist(name, size) 按艺术家搜索歌曲。
|
|
|
|
|
数据统计：get_statistics() 获取索引的文档总数等统计信息；get_genre_count() 统计音乐流派分布；get_distinct_count(field) 统计指定字段（如艺术家、专辑）的不同值数量。
|
|
|
|
|
热门数据：get_popular_songs(limit) 可获取热门歌曲列表。
|
|
|
|
|
（三）API 接口模块
|
|
|
|
|
基于 Flask 定义了大量 API，覆盖搜索、数据统计、关系查询、系统管理等场景，部分关键 API 如下：
|
|
|
|
|
搜索相关：/api/search 支持多类型（歌曲、艺术家、专辑、歌词等）的全文搜索，优先短语精确匹配，再补充模糊匹配，还会结合 Neo4j 数据进行结果补充与去重。
|
|
|
|
|
数据统计：/api/stats 聚合 Neo4j 和 Elasticsearch 的统计数据，返回系统中的歌曲、艺术家、专辑总数等信息；/api/analytics/genre-stats 提供音乐类型的统计分布。
|
|
|
|
|
实体关系：/api/graph/related/<song_id> 获取歌曲的相关歌曲；/api/song/<song_id>/relationships 获取歌曲的关系图数据。
|
|
|
|
|
系统管理：/api/init 初始化系统，创建数据库约束并批量爬取数据；/api/admin/reset 清空数据库与索引，可选重建与爬取。
|
|
|
|
|
三、技术亮点与设计思路
|
|
|
|
|
（一）多数据源协同
|
|
|
|
|
系统同时使用 Neo4j 和 Elasticsearch，发挥各自优势：
|
|
|
|
|
Neo4j 擅长处理实体间的复杂关系，适合存储歌曲、艺术家、专辑之间的关联，便于进行关系型查询（如获取相关歌曲、艺术家的歌曲列表）。
|
|
|
|
|
Elasticsearch 则在全文搜索和数据统计方面表现出色，能快速响应多字段的模糊搜索、短语匹配以及各类数据聚合统计需求。
|
|
|
|
|
（二）数据流转与整合
|
|
|
|
|
数据从爬取模块获取后，会同时存入 Neo4j 和 Elasticsearch，保证了数据在关系存储和搜索统计两个维度的可用性。例如，爬取的歌曲数据会通过 add_songs_batch 存入 Neo4j，通过 index_songs_batch 索引到 Elasticsearch。
|
|
|
|
|
（三）自动化与健壮性
|
|
|
|
|
自动爬取：通过启动后台线程，按照指定时间间隔（AUTO_CRAWL_INTERVAL 配置）自动批量爬取数据，保证数据的实时性与丰富度。
|
|
|
|
|
异常处理：在关键方法（如爬取、存储、搜索）中都添加了异常捕获与处理，返回友好的错误信息，提升系统的健壮性。
|
|
|
|
|
（四）测试友好性
|
|
|
|
|
通过 IS_TEST_MODE 变量控制测试模式下的提示输出，便于在测试环境中查看关键操作的日志信息，如爬取、入库的提示。
|
|
|
|
|
四、依赖与环境配置
|
|
|
|
|
依赖库：Flask（Web 框架）、Flask-CORS（跨域支持）、neo4j（图数据库驱动）、elasticsearch（搜索引擎驱动）等。
|
|
|
|
|
环境变量：可通过 PYTEST_CURRENT_TEST、UNIT_TEST 控制测试模式；AUTO_CRAWL_INTERVAL 配置自动爬取的时间间隔。
|
|
|
|
|
五、总结
|
|
|
|
|
该音乐搜索系统后端代码结构清晰，模块职责明确，充分利用了 Neo4j 和 Elasticsearch 的技术特性，实现了高效的音乐数据管理、搜索与统计功能。同时，通过自动化爬取、完善的异常处理和测试友好的设计，保证了系统的实用性、健壮性与可维护性，能很好地支撑前端页面的各类交互需求。
|
