一款支持用户登录和退出的吉他曲谱识别平台。用户可以将音频片段上传到服务器进行处理和和识别和保存和弦识别结果。处理是异步进行的，用户可以监视进度。用户可以查看所有处理的音频文件和其结果，并创建播放列表以对其音频和曲谱结果进行分类。用户可以调整识别出的和弦并发表它们。在应用程序的主页面上，用户可以查看他们自己和其他人发布的所有和弦曲谱。
1.可能会有许多用户同时上传许多音频文件进行处理，服务器压力过大。 2.所有用户发布的曲谱清单是一个动态更新的流。应该如何设计这个feed流？ 2.客户端如何检测处理进度？
为了设计这个音频处理和分析平台，我们可以使用以下技术栈：
Spring Boot - 用于构建基于微服务的应用程序。 MyBatis - 用于与MySQL数据库进行交互。 MySQL - 存储用户信息、音频元数据和处理结果。 Redis - 缓存处理进度和实现分布式锁。 Docker - 打包和部署微服务。 RabbitMQ - 实现异步处理和进度更新。 以下是一个概要设计：
该系统将由前台网页/移动应用程序、后台服务器、消息队列和处理服务器组成。
1.前端应用程序将允许用户注册/登录、上传音频文件、查看处理进度、查看/编辑结果、发布标签以及查看标签流。它将通过 REST API 与后台服务器通信。
2.后台服务器将负责处理用户账户、上传/检索数据库中的音频文件和结果，并将新文件推送到消息队列中。它将使用 Spring Boot、MyBatis 和 MySQL 构建。
3.消息队列（例如 RabbitMQ）将充当后台服务器和处理服务器之间的缓冲区。它将对要处理的音频文件排队。
4.处理服务器将轮询消息队列、检索音频文件、在其中运行和弦检测算法、将结果保存到数据库中，并更新处理进度以供前端进行查询。采用 Docker 微服务。
5.为了处理高负载，可以运行多个处理服务器的实例。使用 Redis 缓存来减少数据库负载。
6.信息流设计，前端的信息流将显示所有已发布标签的列表，最新的排在前面。对于每个标签，它将显示：
标题/艺术家 和弦进行（例如 C、G、F） 发布者的用户名 点赞数和点赞选项 评论区 用户可以点击任何已发布的标签，查看带有时间戳、弦图表等的完整结果。
7.可扩展性： i.使用 Docker 和 Kubernetes 启动/停止音频处理服务器的实例 ii.使用 Redis 缓存数据，将数据库负载最小化 iii.使用强大的消息队列（RabbitMQ）作为后台和处理服务器之间的缓冲区 iv.处理算法应有一个合理的最大运行时间，以便单个文件如果需要，就可以超时。如果出现超时问题，用户可以重新上传。
- 微服务架构
将系统拆分为以下几个微服务：
用户服务（User Service）：负责用户注册、登陆和退出功能。 音频上传服务（Audio Upload Service）：负责接收用户上传的音频文件，并将其保存到文件存储系统（如S3或MinIO）。 音频处理服务（Audio Processing Service）：负责音频处理和分析任务。 进度查询服务（Progress Query Service）：负责查询音频处理进度。 2. 数据库设计
使用MySQL数据库存储用户信息、音频元数据和处理结果：
users表：存储用户信息，包括ID、用户名、密码、邮箱等。 audio_files表：存储音频元数据，如音频ID、用户ID、文件名、文件路径、状态（待处理、处理中、已完成）等。 audio_results表：存储处理结果，如音频ID、结果数据等。 3. 异步处理
当用户上传音频文件后，音频上传服务将处理任务发送到RabbitMQ消息队列。音频处理服务作为消费者，监听队列并异步处理任务。
音频处理服务在开始处理音频时，将状态更新为“处理中”，并将任务ID存储到Redis中。在处理过程中，根据进度更新Redis中的任务ID对应的进度值。处理完成后，将状态更新为“已完成”，并将结果数据保存到MySQL数据库中。
- 客户端感知进度
客户端可以通过轮询或WebSocket与进度查询服务通信，查询音频处理进度。进度查询服务从Redis中获取任务ID对应的进度值，并返回给客户端。
- 部署与扩展
使用Docker将各个微服务打包为容器，以便在任何支持Docker的环境中部署。在面临大量用户请求时，可以通过扩展音频处理服务的实例数量来应对服务器压力。
- 安全性
使用Spring Security实现用户鉴权和权限控制，确保只有已登陆用户才能上传音频和查询进度。
综上所述，这个音频处理和分析平台后端系统的设计可以有效地解决可能出现的问题，同时保证了系统的可扩展性和稳定性。
1. 总体方案
1. 分支开发，主干master上线
2. 多人开发相同需求时，先建立一个公共分支（如feat-A），然后每位同学通过提MR到feat-A分支的方式合并代码，最终测试完毕后将feat-A合入master
3. 强烈建议使用远程分支的方式管理代码，每天下班前把自己的代码推送到分支上，不要在本机保留过长时间代码（如电脑突然坏上怎么办，丢了怎么办，etc）
2. 代码内容约定：
1.对于新需求/变更较大的需求，需要在代码目录增加README.MD文件，写清楚页面使用场景是什么，各模块对接人是谁，需求相关文档地址等
3. Commit msg规范：所有commit msg都按照以下格式提交，如
feat: 视频分享页增加自动播放功能
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 代码格式优化（不影响代码运行的变动.
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
chore：代码重构，工具优化等
test：增加测试用例，测试代码等
4. Merge Request 规范：
■ 标题格式：feat: xxxxxx
■ 内容：写清楚合入内容