2010-07-29 10 views
13

Stackoverflow có một hệ thống huy hiệu tiện lợi. Một điều tôi nhận thấy là huy hiệu không được trao ngay lập tức, nhưng đôi khi dường như có một số loại chậm trễ sau khi tôi đáp ứng các tiêu chí. Tôi đã nhận thấy điều này trên một số trang web khác có huy hiệu.Tại sao các trang web như stackoverflow với phù hiệu sử dụng một số loại công việc bị trì hoãn để xác định khi nào nên trao một huy hiệu mới?

Có lẽ điều này là do họ đang sử dụng công việc bị trì hoãn quét theo định kỳ để xem có bất kỳ huy hiệu mới nào cần được trao tặng hay không. Tôi thấy cách tiếp cận này cũng được đề xuất ở đây:
How to implement badges?

Tuy nhiên, tôi không thực sự hiểu tại sao việc triển khai của tôi chỉ đơn giản là có hệ thống sau khi thực hiện một hành động có liên quan, ví dụ một bình luận mới được đăng, một hàm checkAwardBadge được gọi, sẽ kiểm tra xem người dùng có đáp ứng các tiêu chí cho một huy hiệu nhận xét mới hay không. Speedwise, tôi đã nghĩ rằng tất cả các thống kê người dùng có liên quan sẽ được lưu trữ trong Submodel của User, như UserStats để thay vì phải đếm số lượng bình luận mỗi lần, nó sẽ chỉ là một truy vấn đơn giản.

Điều đó khiến tôi thấy rằng hệ thống mà tôi ưa thích phải nhanh và dễ hiểu. Có những nhược điểm tôi đang thiếu ở đây về lý do tại sao nó cần thiết để làm phức tạp những thứ với công việc bị trì hoãn?

Để làm rõ: Tôi dự định có một lớp trừu tượng Thành tích, với mỗi Thành tựu thực tế là việc thực hiện Thành tích. Mỗi Thành tựu sẽ có chức năng checkAwardBadge, có thể được gọi từ bộ điều khiển hoặc thậm chí là công việc bị trì hoãn nếu tôi chọn chọn tuyến đường đó hoặc bất kỳ lúc nào để kiểm tra xem người dùng đã giành được một huy hiệu nào đó hay chưa. Vì vậy, mã thành tích tất cả sẽ được tập trung.

Trả lời

15

thực hiện của bạn có thể làm việc trên kịch bản đơn giản (như một trong những bạn đang mô tả), nhưng nếu mọi thứ trở nên phức tạp hơn bạn có một giải pháp mà:

  1. Làm cho kiểm tra không cần thiết trong mọi hành động
  2. Thêm hiệu suất phạt cho mọi hành động
  3. Không quy mô
  4. Không có vị trí trung tâm cho tất cả các quy tắc.
+0

(1) và (2) hình phạt về hiệu suất sẽ rất nhỏ. Chỉ một truy vấn hàng đơn giản cho cơ sở dữ liệu, tiếp theo là một số logic đơn giản như (X> 30) (3) Bạn có thể giải thích tại sao điều này không quy mô (4) Thực ra nó sẽ như thế. Tôi dự định tạo ra một lớp Achivements, với mỗi Thành tựu một lớp con. Sau đó, tôi chỉ cần thêm một dòng vào mã bộ điều khiển trong hầu hết các trường hợp để thực hiện cuộc gọi đến checkAwardBadge trên huy hiệu có liên quan. –

+2

(3) Ví dụ: Giả sử bạn có một hành động như xóa nhận xét, không kích hoạt bất kỳ Huy hiệu nào, nhưng sau đó bạn cần trao huy hiệu khi người dùng xóa nhận xét, bạn phải quay lại để tìm tất cả mã xóa một chú thích và thêm cuộc gọi vào checkAwardBadge. Hãy tưởng tượng nó trong các tình huống phức tạp hơn. –

+2

Nó không mở rộng quy mô, bởi vì khi bạn có hơn 100.000 người dùng và 10.000.000 hành động, bạn phải tăng cơ sở dữ liệu sau mỗi hành động của mỗi người dùng để truy vấn. Thay vào đó, nếu bạn tải công việc xuống chuỗi công việc (chờ nó), thì điều đó có thể chạy trong nền và cập nhật định kỳ mọi huy hiệu của người dùng. Nó có thể được thông minh bởi, nói, quét chỉ các hoạt động được tạo ra kể từ khi chủ đề mới nhất chạy, vv – BryanH

4

Có thể do đó nếu một hành động được thực hiện và ngay lập tức hoàn tác, nó sẽ không dẫn đến huy hiệu được trao tặng.

2

Tôi luôn cho rằng sự chậm trễ là do phân phối nội dung tĩnh nhanh hơn. Tôi nghĩ rằng điều này là phổ biến trên các trang web lưu lượng truy cập cao, cập nhật định kỳ nội dung tĩnh thay vì tạo ra nó cho mỗi yêu cầu web.

Công việc định kỳ sẽ chỉ tạo nội dung tĩnh mới và sẽ chạy rất thường xuyên, nhưng ít thường xuyên hơn mọi yêu cầu trang đơn lẻ.

+0

Thực tế, nội dung tĩnh chỉ cần được cập nhật nếu nội dung (hoặc các thành phần/widget của trang) được cập nhật. – BryanH

15

Mặc dù điều này chỉ tương đồng với kịch bản bạn mô tả, tôi cảm thấy rằng thảo luận những gì chúng tôi làm trong công việc của mình có thể giúp chiếu sáng một phần lý do cho phương pháp này.

Tôi làm việc cho một công ty giao dịch thuật toán thời gian thực. Một phần của những gì phần mềm của chúng tôi làm là xử lý dữ liệu thị trường từ một nhà cung cấp.

Bây giờ, có những thứ cần phải xảy ra để đáp ứng mọi dấu tick thị trường riêng lẻ. Chúng tôi chạy phân tích, có trình kích hoạt an toàn có hiệu lực trong một số trường hợp nhất định, v.v.Nhưng những gì chúng ta tránh làm ở tất cả các chi phí là bloating mã phản ứng với các sự kiện thị trường với tất cả logic "phụ" này.

Lý do ở đây là dữ liệu của chúng tôi đi qua mạng từ nhà cung cấp dữ liệu và chúng tôi cần nguồn cấp dữ liệu này được tự do lưu mà không cần sao lưu. Phần mềm của chúng tôi có thể xử lý khoảng 10.000 lần thị trường mỗi giây. Nếu mất quá nhiều thời gian để xử lý các sự kiện thị trường đó, nguồn cấp dữ liệu bắt đầu bị tắc và khả năng phản ứng của chúng tôi với thị trường càng nhanh càng tốt.

Hậu quả của việc này là mã của chúng tôi xử lý các sự kiện thị trường mới cực kỳ gọn gàng. Một sự kiện cập nhật một mức giá và đó là nó. Đối với tất cả các logic khác cần chạy cho mỗi sự kiện: điều đó xảy ra trên cơ sở định kỳ, thông qua một hàng đợi của tất cả các sự kiện chưa được kiểm tra bởi logic này.

Điều này cho phép chúng tôi có một chuỗi cực kỳ nhạy và không được sao lưu dữ liệu, trong khi một luồng khác xử lý các sự kiện đến và thực hiện các tính toán quan trọng hơn với chúng. Chia công việc thành hai phần theo cách này sẽ giúp mọi thứ diễn ra suôn sẻ.

Tôi thừa nhận điều này chỉ liên quan đến câu hỏi của bạn, nhưng có vẻ như tôi lý do không kiểm tra logic liên quan đến huy hiệu trên mọi hành động của người dùng có thể rất giống nhau. Bạn không muốn làm chậm mọi hoạt động trên máy chủ bằng cách thực hiện logic ít quan trọng hơn vào thời điểm chính xác hoạt động diễn ra. Chiến lược chung là giữ cho hoạt động nhanh của bạn nhanh chóng (tức là, về cơ bản tất cả các hành động của người dùng) và phân bổ công việc tốn nhiều thời gian hơn cho các quy trình thứ cấp chạy, có lẽ thường là, nhưng không phải cho mọi hoạt động như vậy.

+0

+1 hoàn toàn đồng ý, và cách rất tốt để giải thích lý do, tôi nghĩ. – Gian

Các vấn đề liên quan