Kiến trúc của trình phát nhạc có danh sách phát, sử dụng Rails, Redis và HTML5

Question

Tôi đang phát triển một ứng dụng có nhiều danh sách phát nhạc, chế độ xem cho mỗi danh sách phát và trình phát.

Tôi đang sử dụng hệ thống HTML5 History API trong hệ thống của mình (để có chức năng khác) và sẽ sử dụng nó thêm để ngăn tải lại trang giữa các yêu cầu và do đó nhạc dừng trên mỗi trang.

Tôi bị mắc kẹt là cách tiếp cận tốt nhất để quản lý tuyến đường mà người chơi sẽ phát giữa các lượt xem. Hiện tại, như bạn mong đợi, người dùng nhấp vào liên kết, nhận danh sách tuyến đường. Các bản nhạc được tải vào trình phát và phát theo trình tự, đơn giản. Tuy nhiên, với âm nhạc phát liên tục, tôi cần đảm bảo danh sách phát bài hát chính xác theo thứ tự mặc dù nội dung thay đổi trên trang và giờ đây là URL động.

Tuy nhiên, khi người dùng điều hướng đến trang khác, nhấn phát trên bản nhạc trong danh sách phát mới, tôi cần tải mục đó vào trình phát và tải hiệu quả phần còn lại của danh sách phát trong khi người dùng tiếp tục để điều hướng.

Tôi đang sử dụng Redis để lưu trữ danh sách id bản nhạc cho danh sách phát để tham khảo nhanh để giảm độ trễ giữa các bản nhạc. Kết quả là tôi có một Redis khác nhau được đặt cho mỗi danh sách phát. Tôi cũng đã xây dựng các cuộc gọi API theo dõi tiếp theo và trước đó dựa trên bản nhạc đang phát, do đó, bản nhạc tiếp theo từ tập Redis có thể được tải vào trình phát.

Như đã đề cập mặc dù tôi không thể quyết định cách tốt nhất để tham chiếu danh sách phát nào hiện đang phát để người chơi biết từ đó Redis được đặt để gọi các bản nhạc. Suy nghĩ của tôi đã để lại cho tôi một vài ý tưởng khác nhau:

a) Thuộc tính dữ liệu tùy chỉnh HTML5 - tôi có thể đặt danh sách phát đang phát làm thuộc tính dữ liệu trên trình phát và cập nhật nó. Sau đó tôi có thể tham chiếu thuộc tính này khi quyết định đặt Redis nào để tải bản nhạc tiếp theo của tôi từ đó.

Hoặc tôi có thể đổ danh sách phát hiện tại và tất cả tuyến đường (và thuộc tính của chúng) thành đối tượng JSON thành thuộc tính dữ liệu trên trang. Danh sách phát có thể là hàng nghìn bài hát dài mặc dù vậy tôi đang loại bỏ bài hát này vì mã nguồn sẽ trông khủng khiếp, hãy để một mình các vấn đề về hiệu suất có thể có liên quan. Tôi có đúng không?

b) LocalStorage - Hỗ trợ trình duyệt chéo bị giới hạn. Sự hỗ trợ nhiều hơn cho giải pháp này tốt hơn trong trường hợp cụ thể này. Mặc dù tôi có thể lưu danh sách phát hiện tại trong trình duyệt của người dùng. Điều này đã khiến tôi băn khoăn liệu việc lưu trữ các đối tượng JSON trong LocalStorage cũng có thực tế hay không, để ngăn chặn các cuộc gọi DB bổ sung.

c) Trong phiên - Tôi có thể cập nhật phiên để lưu trữ biến cho danh sách phát hiện đang phát.

d) Redis - Tôi có thể mở rộng việc sử dụng Redis để lưu chuỗi tham chiếu tên của danh sách phát hiện tại. Sau đó tôi có thể kiểm tra nó giữa mỗi lần theo dõi Tiếp theo/Trước đó.

Thông qua viết câu hỏi này tôi đã có ý tưởng tốt hơn về tuyến đường nào tôi sẽ thực hiện nhưng nếu có ai có lời khuyên nào cho kịch bản này thì tôi rất muốn nghe.

Cảm ơn.

CẬP NHẬT: Tôi đã triển khai 95% giải pháp sử dụng Redis cho việc này. Tôi đang gặp một số vấn đề về hiệu suất mặc dù các trang tải ~ 10 giây để tải. Không tuyệt vời chút nào.

Về cơ bản, mỗi người dùng có 2 danh sách phát: Hiện tại và Vũ trang. Mỗi yêu cầu tải id bài hát vào danh sách phát Có vũ trang lại và nếu nút phát được nhấn vào một bản nhạc, danh sách Phát lại hiện tại sẽ hết hạn và được thay thế bằng danh sách Vũ trang.

Các nút Tiếp theo và Trước đó của tôi sau đó chỉ tìm nạp ID của bài hát tiếp theo hoặc trước đó trong danh sách phát Hiện tại và tải trong nguồn nhạc cho trình phát. Khái niệm này hoạt động tốt và tôi hài lòng với nó.

Tuy nhiên, như hiệu suất được đề cập chậm giữa các yêu cầu trang và cần cải thiện đáng kể. SQL của tôi là tối ưu hóa, tôi chỉ kéo ra các thuộc tính cần thiết và tôi có chỉ số SQL khi cần thiết vì vậy tôi đang tìm kiếm lựa chọn thay thế khác vào lúc này.

Tùy chọn tôi đang xem xét:

1. Chỉ cư playlist vũ trang nếu một ca khúc được nhấp vào trang mới. Điều này sẽ tiết kiệm được việc xử lý bổ sung nếu người dùng không thực sự muốn nghe một trong các bản nhạc mới.

2. Sử dụng thêm Redis và lưu trữ các đối tượng theo dõi lean trong danh sách phát Redis thay vì chỉ ID theo dõi - độ trễ hiệu suất phần lớn giữa các yêu cầu trang và không thực sự phát các bản nhạc và điều hướng danh sách phát.

3. Sử dụng danh sách phát lại Làm chủ chính bao gồm tất cả các bản nhạc ứng dụng mà từ đó danh sách phát Hiện tại và Trang có thể chọn. Điều này có thể được duy trì thông qua một nhiệm vụ cào giờ và sẽ ngăn chặn các cuộc gọi DB dài trên các yêu cầu trang. Tôi chỉ lo lắng có bao xa này sẽ quy mô về việc sử dụng bộ nhớ trên máy chủ và số lượng các bài hát trong DB.

Answer 1

Tôi sẽ đề nghị c) Trong phiên.
Dữ liệu phiên có thể được truy cập dễ dàng trên cả phía máy khách lẫn phía máy chủ.

Việc lấp đầy bộ nhớ cache Redis của bạn với dữ liệu người dùng cụ thể không mở rộng đặc biệt tốt.

LocalStorage - chính xác, điều này sẽ không thành công cho một số lượng lớn người dùng vào ngày hiện tại.

Thuộc tính tùy chỉnh - chỉ đơn giản là lộn xộn, như đã lưu ý.

Chỉ 2 xu của tôi.

Answer 2

Nếu bạn cần mô hình trạng thái ứng dụng phía máy khách, tốt nhất là nên có một nguồn của trạng thái. Đây là một trong những vấn đề của các khung công tác Javascript MV (V) C phía khách hàng cố gắng giải quyết. Tôi chủ yếu quen thuộc với backbone.js và ember.js để tôi có thể nói chuyện với những người đó.

Backbone.js

Tạo một mô hình gọi là Playlist và một bộ sưu tập được gọi là Playlists. Thêm thuộc tính vào bộ sưu tập PlaylistscurrentPlaylist giữ danh sách phát hiện tại của bạn. Sau đó, xác định chế độ xem có tên là PlaylistView và xác định phương thức render trên đó.Kết nối các trình kích hoạt sự kiện và các ràng buộc sao cho khi currentPlaylist thay đổi, danh sách phát sẽ tự động được hiển thị lại. Điều này sẽ yêu cầu di chuyển mẫu của bạn hiển thị cho khách hàng, nhưng có thể bạn sẽ muốn làm điều đó để giảm bớt các vòng lặp máy chủ và giảm tải trên máy chủ gây ra bằng cách hiển thị.

Ember.js

Tạo một bộ điều khiển (tương tự như bộ sưu tập xương sống) với một tài sản gọi là currentPlaylist và cư trú trong bộ điều khiển với tất cả các danh sách nhạc biểu diễn dưới dạng Ember.object s. Sau đó, trong mẫu danh sách phát xử lý danh sách phát được bao gồm trên trang, bạn có thể liên kết với playlists.currentPlaylist và mẫu sẽ tự động hiển thị lại khi playlists.currentPlaylist thay đổi.

Tôi rõ ràng sẽ loại bỏ phần lớn các chi tiết, nhưng tốt nhất là để lại tài liệu, ví dụ và hướng dẫn về khung công tác.

từ chối trách nhiệm: Tôi mới làm quen với các khung công tác phía máy khách, một phần lý do tôi bỏ hầu hết các chi tiết. Tôi đánh giá cao bất kỳ ai có thể sửa tôi nếu tôi gặp lỗi.

Answer 3

Kết hợp bộ nhớ phiên và cục bộ sẽ là một cách tiếp cận tốt.

Nhưng thay vì tìm nạp toàn bộ danh sách phát, bạn chỉ cần tìm X (ví dụ 10) các bản nhạc tiếp theo và cũng có thể là các bản nhạc X trước đó. Khi người chơi đến bài hát cuối cùng, nó sẽ lấy 10 bài hát tiếp theo, những bài hát trước có thể được tính toán trong máy khách.

Mô hình dữ liệu có thể chỉ là một băm trong đó phần tử [0] là bài hát hiện tại, các phần tử [X] là các bài hát tiếp theo và [-X] các bài hát trước đó.

Lưu trữ phía máy khách thông tin danh sách phát có vẻ hợp lý với tôi, nhưng bạn cũng có thể sử dụng phiên để tham chiếu bài hát và danh sách bài hát hiện tại, vì vậy khi người dùng quay lại hoặc tải lại trang web của bạn, bạn vẫn nhận được bài hát mà không cần gọi cơ sở dữ liệu.