Hệ thống huy hiệu trang web

Question

Tôi hiện đang làm việc trên một trang web dựa trên tiện ích, được xây dựng hoàn toàn dựa trên xã hội hóa của người dùng. Kể từ khi một hệ thống danh tiếng trả tiền cho việc thu hút người dùng, tôi quyết định thực hiện một trong những điều này.

Bây giờ, tôi muốn nghe một số giải pháp về cách thực hiện điều này đúng cách (ví dụ: hệ thống huy hiệu của Foursquare).

Về cơ bản, tôi cần để có thể làm như sau:

• có một bảng huy hiệu, nơi tôi có thể thêm, chỉnh sửa và xóa phù hiệu;
• có thể bật và tắt huy hiệu;
• có thể giới thiệu huy hiệu mới, nhưng mà không cần viết mã mới - chỉ cần cung cấp một số tham số cho biểu mẫu thêm huy hiệu về những gì cần theo dõi để người dùng nhận huy hiệu;
• có thể cung cấp huy hiệu theo thời gian thực - có nghĩa là bất cứ khi nào người dùng hoàn thành bất kỳ điều gì cần nhận huy hiệu, hệ thống sẽ biết ngay để trao huy hiệu cho người dùng đó;
• cũng vậy, hệ thống không nên bị quá tải với "người nghe huy hiệu" - tôi tin rằng việc thẩm vấn từng yêu cầu của người dùng với mọi yêu cầu huy hiệu là tốn thời gian;

Những đang được nói, tôi muốn nghe ý kiến ​​của bạn về làm thế nào để thực hiện một cách đúng đắn một hệ thống huy hiệu (logic, lược đồ cơ sở dữ liệu, phương pháp, vv)

Answer 1

Bạn có thể xem xét sử dụng các module Drupal User Badges hoặc thậm chí nhìn vào cách nó đặt lược đồ của nó lên.

Answer 2

Cơ sở dữ liệu & Live-cập nhật:
tạo ra một bảng với các cột như điều kiện
ví dụ: trả lời - phiếu - câu trả lời đặc trưng vv ...

mỗi khi người dùng tạo ra một gửi hoặc khi người dùng bỏ phiếu (kịch bản phía máy khách để gửi), họ được trao một điểm/ponts (số gia số trong cột bảng).

trên giá trị trả về (client-side scripting cho lấy), dựa trên báo cáo có điều kiện có liên quan đến các cột trong bảng, huy hiệu là kiếm được.
ví dụ:
nếu phiếu = 50, đạt heplful huy hiệu
nếu đặc trưng = 10, đạt đóng góp hàng đầu huy hiệu

bởi client-side scripting Ý tôi là ajax hoặc json, Im không chắc chắn như thế nào bạn sẽ đi về việc tạo một ứng dụng nguồn cấp dữ liệu trực tiếp

Answer 3

điều đầu tiên bạn nên làm để có cấu trúc phù hợp cho dự án của bạn rồi bắt đầu phát triển nó ... bạn sẽ có nhiều vấn đề chắc chắn nhưng bạn có thể hỏi bất cứ lúc nào vì đăng bài ở đây là ju nói chung và bất kỳ câu trả lời sẽ không giúp đỡ trong trường hợp của bạn.

nhưng ý tưởng của bạn tuyệt vời :)

Answer 4

Điều này nghe giống như một dự án lớn. Mức độ phức tạp sẽ tăng khá nhanh dù bạn có muốn hay không.

Điều đầu tiên tôi sẽ làm là bắt đầu bằng cách tạo tài liệu cho API.

Khi bạn có tài liệu, bạn có thể vẽ các yêu cầu cho dự án của mình. Những điều bạn viết trong câu hỏi là một số loại yêu cầu, nhưng quá trừu tượng, hình ảnh quá lớn như thế nào.

Khi bạn có yêu cầu, bạn bắt đầu nghĩ về kỹ thuật và cấu trúc phần mềm.

Trong bước này, chia nhỏ mọi thứ theo ý kiến ​​của tôi là con đường để đi. Điều này sẽ giúp mọi thứ dễ dàng hơn trong việc quản lý. Tìm lỗi cổ chai, v.v.

Tôi không biết điều gì sẽ kích hoạt trong hệ thống của bạn cho 'nếu người dùng sẽ nhận được huy hiệu'. Vì vậy, tôi đang sử dụng tương tự.

Để công bằng, các bạn đang làm công việc tuyệt vời để xử lý tất cả các yêu cầu này trong thời gian thực. Ý tôi là, có vẻ như họ đang kiểm tra xem tôi có nhận được huy hiệu theo mọi yêu cầu hay không. Vì vậy, đăng ký của tôi đang kích hoạt một số thuật toán ở phía máy chủ để xem lại lịch sử đăng ký và kiểm tra của tôi, quy tắc huy hiệu, kết hợp chúng lại với nhau, tạo huy hiệu xứng đáng của tôi và hiển thị huy hiệu mới của tôi để phản hồi. Nghe có vẻ đúng không? Vâng, nó là!

Tôi không tin rằng họ đang làm tất cả công việc này song song. Điều này sẽ là quá nhiều công việc cho một máy chủ. Mặc dù, huy hiệu fourquare của tôi không tương tác với bất kỳ người dùng nào khác (dễ dàng hơn nhiều), vì vậy việc xử lý song song không nằm ngoài câu hỏi.

Ý tưởng đầu tiên về cách thức hoạt động của mạng. Load balancer chuyển tiếp yêu cầu của tôi đến máy chủ không tải nặng. Và có tất cả công việc được thực hiện trong paralel. Càng tải, càng nhiều máy chủ được kích hoạt. Làm tất cả các tính toán cho phù hiệu trên bay chỉ sử dụng cơ sở dữ liệu nô lệ. Trình bày cho người dùng huy hiệu của anh ấy và gửi dữ liệu này trở lại làm chủ db. Điều này là có thể, vì huy hiệu không tương tác giữa những người dùng khác nhau. Một huy hiệu - một lịch sử người dùng cần thiết.

Một giải pháp khác là sử dụng bản đồ - giảm. Sử dụng nhà môi giới thư để xử lý đánh giá huy hiệu song song. Bạn nhận được yêu cầu. Gửi tin nhắn đến người môi giới tin nhắn. Thư được đáp xuống trên multiple workers trong đó một công nhân chỉ đang kiểm tra một quy tắc huy hiệu cụ thể đối với lịch sử người dùng. Cuối cùng, tính toán sẽ được thực hiện nhanh hơn nhiều.

Giới thiệu về cấu trúc db. Tôi nghĩ rằng không có cách nào xung quanh đi qua tất cả các db để thực sự tìm hiểu xem người dùng sẽ nhận được một huy hiệu hay không. Tôi sẽ đi với cách đơn giản, thẳng về phía trước để xử lý việc này. Chỉ cần tạo db có cấu trúc tốt bằng cách sử dụng các khóa ngoài, các kiểu cột thích hợp, các chỉ mục ở đúng vị trí và bạn sẽ ổn. Xây dựng nền tảng ổn định và chỉ tối ưu hóa khi cần thiết.

Nếu bạn thực sự mong muốn tối ưu hóa khi bắt đầu dự án (tôi nghĩ đó là ý tưởng tồi), tôi sẽ giữ tất cả dữ liệu liên quan đến huy hiệu trong các bảng được phân tách. Một bảng cho một huy hiệu có tất cả các cột cụ thể có liên quan đến huy hiệu đó.

Ví dụ: badge_restaurants (user_id, badge_id, current_level, checkin_count). Để nhận được huy hiệu nhà hàng mới, bạn sẽ chỉ cần kiểm tra nếu người dùng đã checkin_count + 1> = qty cần thiết và bạn được tự do không tìm thêm bất kỳ chi tiết nào.

Tất nhiên, đây không phải là giải pháp hoàn hảo. Trừu tượng hơn có thể được thêm vào để làm cho nó được thực hiện theo cách tinh vi hơn (không tạo ra hàng trăm bảng).Tuy nhiên, các huy hiệu phức tạp hơn sẽ thúc đẩy bạn tạo ra các giải pháp phức tạp hơn.