@Huyennv Trong trường hợp hệ thống chạy bt thì cũng khó kiếm ra lý do để clear cache. Xét với 3 cách thiết kế ở trên:
1. Redis đơn thuần là cache. Cache có expire time được cài đặt theo 3 cách:
Absolute - đặt thời gian tồn tại cố định cho cache, cache sẽ tự clear sau khi đến hạn.
Sliding - đặt thời gian clear cache nếu cache không được truy cập nữa, hay mỗi lần cache được truy cập thì thời gian hết hạn của cache được đặt lại về số ban đầu. Đối với sliding thì có vấn đề là nếu cache được truy cập liên tục thì sẽ không bao giờ được clear => nhu cầu clear cache thủ công
Cache validation: cài đặt một callback xử lý việc clear cache khi đạt một điều kiện nào đấy. Cái này thường được kết hợp cùng expire time. Đối với tính lượt view, một dependency để invalidate cache có thể là khi số view đạt đến hàng nghìn thì clear cache, hoặc một trick là rand trong range 100, 1000, nếu bằng 1 thì clear.
2. Redis chạy song song
Về cơ bản thì phương án này vẫn là cache, nhưng cái khác là số đếm được cập nhật song song giữa redis và lưu trữ trong DB. Do Redis được cập nhật trực tiếp như DB nên không cần validate cache. Redis bị xóa thì có thể do mất điện, shutdown hệ thống để maitain hay update.
3. Lưu Redis trước rồi backup lại trên DB sau
Trường hợp này thì không có lý do gì để xóa redis cả (xóa là mất dữ liệu). Chỉ có 1 trường hợp cần là khi hệ thống gián đoạn (maitainance, update ...), Redis sẽ mất hết dữ liệu và cần reload lại từ DB. (Redis lưu dữ liệu trong RAM nên mất điện là mất hết).
Tất nhiên là nếu dùng Kafka, thay vì xử lý trực tiếp phía API thì bạn có thể đẩy một số task vào Kafka chạy background. Tuy nhiên theo mình, nếu mục đích của bạn là muốn giảm độ trễ của REST API thì bạn nên cân nhắc tối ưu lại source code và dùng các công cụ như là memcache, redis để thực hiện caching và dựng queue trước. Dựa trên quy mô của dự án để quyết định có nên dùng Kafka hay không tránh giết gà dùng dao mổ trâu.
Hi tác giả, không biết env và ide của bạn đang chạy như thế nào ạ, mình có thử implement code của bạn ở env trên Jupyter và gặp một số lỗi về runningtimeerror cụ thể là: asyncio.run() cannot be called from a running event loop ạ
nếu document là 1 kiểu report có nhiều thông tin giá trị, kích thước document nhỏ, mỗi dòng trong document sẽ là 1 chunk (sẽ khoảng <30 word cho 1 dòng). Và yêu cầu là ta cần LLM chỉ tìm kiếm thông tin được yêu cầu và gửi kết quả về thôi (không diễn giải, gợi ý hay giải thích gì thêm), thì nên dùng phương pháp nào vậy anh ơi
Vậy SSR dưới BE phải build html rồi trả về FE đúng ko b. B có thể nói qua cách build html dưới BE thế nào đc ko. Kiểu FE phải nhìn giao diện mới căn content đc, chứ BE thì sao mà thấy đc nhỉ, hay là nháp bằng FE rồi paste file sang BE. Có gì chỉ giáo mình nhé ^^
À cảm ơn bạn đóng góp nhé. Mình lỗi chính tả tòe loe. Nhưng mình k định hướng các bài viết của mình theo văn bản hành chính hay dùng làm tài liệu document cho hãng. Mình thấy ae dev cũng dễ tính thôi, đọc hiểu là được. Đơn thuần chia sẻ thôi. Bạn k thích có thể k đọc ạ
@huukimit Lầu ngày quá ha, 😂
Quá chuẩn luôn! Thật sự không nên cứng nhắc áp dụng nguyên tắc SOLID vào tất cả trường hợp có thể. Tuy nhiên, việc hiểu rõ nó cũng giúp ích khá nhiều trong công việc hiện tại của mình.
Mình đã học về SOLID này cách đây khoảng 7-8 năm, nhưng cứ thỉnh thoảng ôn lại, mình vẫn nghiệm ra được nhiều điều mới. Đặc biệt gần đây, khi phải xây dựng nhiều bộ source code mới cho dự án, mình đã cân nhắc kỹ lưỡng khi đặt nền móng. Thường thì mình sẽ code một vài module nhỏ để các đồng nghiệp có thể tham khảo và làm theo.
Vì dự án thường được triển khai bởi đội ngũ offshore, nên cấu trúc code cần phải dễ mở rộng và đặc biệt là dễ kiểm thử, nhất là với automated testing. Đây cũng là bài học xương máu khi các module quá phụ thuộc vào nhau, dẫn đến việc kiểm thử trở nên vô cùng khó khăn.
Tuy nhiên, cuối cùng thì như @huukimit ông nói, SOLID không phải là luật bất di bất dịch. Việc áp dụng không nên quá cứng nhắc. Nhưng nếu thật sự nắm vững SOLID và Clean Code, nó sẽ giúp ích rất nhiều trong quá trình lập trình của chúng ta.
Mình thấy điểm quan trọng không kém đó là SOLID không phải là luật bất di bất dịch. Chúng ta không cần phải quá cứng nhắc viết code phải đáp ứng đủ cả 5 nguyên tắc. Miễn sao khi nhìn vào những dòng code,người đọc thấy nó dễ đọc, dễ hiểu là được.
THẢO LUẬN
@Huyennv Trong trường hợp hệ thống chạy bt thì cũng khó kiếm ra lý do để clear cache. Xét với 3 cách thiết kế ở trên:
1. Redis đơn thuần là cache. Cache có expire time được cài đặt theo 3 cách:
2. Redis chạy song song
Về cơ bản thì phương án này vẫn là cache, nhưng cái khác là số đếm được cập nhật song song giữa redis và lưu trữ trong DB. Do Redis được cập nhật trực tiếp như DB nên không cần validate cache. Redis bị xóa thì có thể do mất điện, shutdown hệ thống để maitain hay update.
3. Lưu Redis trước rồi backup lại trên DB sau
Trường hợp này thì không có lý do gì để xóa redis cả (xóa là mất dữ liệu). Chỉ có 1 trường hợp cần là khi hệ thống gián đoạn (maitainance, update ...), Redis sẽ mất hết dữ liệu và cần reload lại từ DB. (Redis lưu dữ liệu trong RAM nên mất điện là mất hết).
@refacore Sorry bạn, mình giờ mới rep được, Bạn giải thích khá dễ hiểu. Mình đã hiểu các ý bạn nói, mình muốn làm rõ thêm ý nữa là:
Cám ơn bạn nhiều
Mình đang bị lỗi chatbox không có hồi đáp từ rasa, Hãy chỉ cách giúp mình với. Thanks
Tất nhiên là nếu dùng Kafka, thay vì xử lý trực tiếp phía API thì bạn có thể đẩy một số task vào Kafka chạy background. Tuy nhiên theo mình, nếu mục đích của bạn là muốn giảm độ trễ của REST API thì bạn nên cân nhắc tối ưu lại source code và dùng các công cụ như là memcache, redis để thực hiện caching và dựng queue trước. Dựa trên quy mô của dự án để quyết định có nên dùng Kafka hay không tránh giết gà dùng dao mổ trâu.
Với một Dev quèn như em code chạy được là tốt rồi, để mà code được theo nguyên tắc SOLID thật sự khá khó.
Bài viết rất hay !
bạn ơi cho hỏi thu thập thông tin khóa học từ các trang web như coursera, udemy, edx,... nó toàn trả về kết quả là {'course_info': 'NA'} nhỉ 😅
Hi tác giả, không biết env và ide của bạn đang chạy như thế nào ạ, mình có thử implement code của bạn ở env trên Jupyter và gặp một số lỗi về runningtimeerror cụ thể là: asyncio.run() cannot be called from a running event loop ạ
nếu document là 1 kiểu report có nhiều thông tin giá trị, kích thước document nhỏ, mỗi dòng trong document sẽ là 1 chunk (sẽ khoảng <30 word cho 1 dòng). Và yêu cầu là ta cần LLM chỉ tìm kiếm thông tin được yêu cầu và gửi kết quả về thôi (không diễn giải, gợi ý hay giải thích gì thêm), thì nên dùng phương pháp nào vậy anh ơi
Cái này sinh ra để giúp giảm tải độ trễ của RestAPI không bạn
=))) a có push lên github ko cho em xin clone về nghịch với
Vậy SSR dưới BE phải build html rồi trả về FE đúng ko b. B có thể nói qua cách build html dưới BE thế nào đc ko. Kiểu FE phải nhìn giao diện mới căn content đc, chứ BE thì sao mà thấy đc nhỉ, hay là nháp bằng FE rồi paste file sang BE. Có gì chỉ giáo mình nhé ^^
Cảm ơn bác rất nhiều, nghe một mentor có nói về bác từ lâu mà nay mới đọc bài của bác, mà đọc cuốn quá không dứt ra được
Cảm ơn những chia sẻ hết sức quý báu của bác ạ,
Ước có mentor nào đó
chào bạn,trong django có custome field như handfield ,làm sao ghi admin.py để cái hand filed xuất hiện trong trang admin
À cảm ơn bạn đóng góp nhé. Mình lỗi chính tả tòe loe. Nhưng mình k định hướng các bài viết của mình theo văn bản hành chính hay dùng làm tài liệu document cho hãng. Mình thấy ae dev cũng dễ tính thôi, đọc hiểu là được. Đơn thuần chia sẻ thôi. Bạn k thích có thể k đọc ạ
@Clarence161095
@huukimit Lầu ngày quá ha, 😂 Quá chuẩn luôn! Thật sự không nên cứng nhắc áp dụng nguyên tắc SOLID vào tất cả trường hợp có thể. Tuy nhiên, việc hiểu rõ nó cũng giúp ích khá nhiều trong công việc hiện tại của mình.
Mình đã học về SOLID này cách đây khoảng 7-8 năm, nhưng cứ thỉnh thoảng ôn lại, mình vẫn nghiệm ra được nhiều điều mới. Đặc biệt gần đây, khi phải xây dựng nhiều bộ source code mới cho dự án, mình đã cân nhắc kỹ lưỡng khi đặt nền móng. Thường thì mình sẽ code một vài module nhỏ để các đồng nghiệp có thể tham khảo và làm theo.
Vì dự án thường được triển khai bởi đội ngũ offshore, nên cấu trúc code cần phải dễ mở rộng và đặc biệt là dễ kiểm thử, nhất là với automated testing. Đây cũng là bài học xương máu khi các module quá phụ thuộc vào nhau, dẫn đến việc kiểm thử trở nên vô cùng khó khăn.
Tuy nhiên, cuối cùng thì như @huukimit ông nói, SOLID không phải là luật bất di bất dịch. Việc áp dụng không nên quá cứng nhắc. Nhưng nếu thật sự nắm vững SOLID và Clean Code, nó sẽ giúp ích rất nhiều trong quá trình lập trình của chúng ta.
Mình thấy điểm quan trọng không kém đó là SOLID không phải là luật bất di bất dịch. Chúng ta không cần phải quá cứng nhắc viết code phải đáp ứng đủ cả 5 nguyên tắc. Miễn sao khi nhìn vào những dòng code,người đọc thấy nó dễ đọc, dễ hiểu là được.
🤣🤣🤣