Hay nha bạn, tất nhiên phải đọc nhanh những change của AI trước. Tuy nhiên cũng có 1 vài giải pháp cho những vấn đề bạn kể trên khiến các agentic AI hoạt động 1 cách hiệu quả hơn. Mình sẽ viết nó trong loạt bài viết dịp "Mayfest" lần này. Hãy đón chờ nhé🥰
Cảm ơn góc nhìn của bạn nha! Quartz quả thực rất xuất sắc trong việc lập lịch phân tán (Clustered Scheduler) và giải quyết được vấn đề chạy trùng lặp tốt hơn ShedLock.
Tuy nhiên, Quartz chỉ giải quyết tốt bài toán 'Khi nào chạy' (Trigger) chứ chưa giải quyết triệt để bài toán 'Chạy như thế nào' (Orchestration) của các luồng nghiệp vụ phức tạp. Nếu Job đối soát tài chính dài hạn bị sập giữa chừng, Quartz chỉ có thể restart lại từ đầu (dễ gây lỗi double-spend nếu code không được xử lý idempotency cực kỳ kỹ).
Temporal đóng vai trò là một durable state machine, giúp lưu lại trạng thái từng bước chạy và phục hồi chính xác tại điểm sập. Cộng thêm khả năng quản lý retry/timeout và giao diện Web UI theo dõi trực quan, Temporal mang lại sự tin cậy cao hơn hẳn cho hệ thống tài chính bên mình. Rất mong nhận được thêm các đóng góp tiếp theo từ bạn!
Đọc bài của tác giả mới thấy cuộc chiến giữa JDK Dynamic Proxy và CGLIB nó ly kỳ như phim cung đấu vậy. Ông thì bắt buộc phải có Interface danh chính ngôn thuận mới chịu làm việc, ông thì chơi chiêu bẻ lái tạo Class con để lách luật. 😂
Tác giả phân tích nguồn gốc của 'gã thư ký' này rất sâu và trực quan, đọc xong phần 1 này mới thấy tự tin để sang phần 2 xem gã 'bẫy' anh em mình thế nào!
Bài viết quá hay! Spring nó lo hết từ A-Z làm anh em lười lặn xuống dưới xem bộ lòng Dynamic Proxy nó chạy thế nào. Đoạn giải phẫu hành vi của Proxy và lý do vì sao gọi nội bộ bị 'vượt rào' rất rõ ràng và chuẩn chỉnh. Đã upvote và bookmark lại để gửi cho mấy đứa em trong team đọc né bẫy!
Dùng Kafka bao lâu nay cứ gọi Producer.send() rồi Consumer.poll() như một cái máy, hôm nay mới được tác giả cho đi 'nội soi' chi tiết từng mảnh ghép Segment, Commit Log bên dưới. Bài viết quá hay, đi từ bản chất thế này mới thấm được vì sao nó lại đạt được tốc độ ánh sáng như vậy. Đã upvote!
Lúc DB có vài nghìn dòng: OFFSET 1000000 chạy vèo vèo, tự tin mình là master kiến trúc.
Lúc DB lên vài triệu dòng: Người dùng bấm sang trang cuối cùng một cái là CPU server nhảy lên 100%, sếp gọi điện hỏi thăm ngay lập tức. 😂
Bài viết phân tích đúng cái 'bẫy' kinh điển mà ai cũng từng ngã vào. Cảm ơn tác giả vì bài viết quá chất lượng và thực tế!
Lúc đọc bài viết: 'Áp dụng SOLID để code sạch, dễ mở rộng, nâng cấp hơn.' 🥰
Lúc sếp dí deadline: 'Thôi Single Responsibility cái gì tầm này nữa, gom hết vào một hàm cho nó chạy được trước 5h chiều nay đã rồi tính sau!' 😂
Tác giả phân tích cái đoạn 'nghệ thuật đánh đổi' chuẩn quá, không phải cứ nhét hết SOLID vào là thượng đẳng, quan trọng là phải đúng tầm. Bài viết quá chất lượng!
Đọc bài viết mà mồ hôi hột tự nhiên tuôn rơi, cứ ngỡ đang ngồi trong phòng phỏng vấn bị vặn hỏi: 'Em hãy giải thích cơ chế LinkedList chuyển sang Red-Black Tree khi cấu trúc của HashMap vượt quá ngưỡng (threshold)...' 😂
Tác giả giải phẫu chi tiết quá, bài viết chất lượng cứu cánh cho bao nhiêu anh em sắp đi phỏng vấn! Thank tác giả nhiều.
"Redis lưu trữ trên RAM,
Nhanh như tia chớp, ai làm lại anh?
Đùng một cái, mất điện nhanh,
Data bay mất, anh thành người dưng."
Cảm ơn bài viết chia sẻ rất chi tiết về bí kíp 'cân bằng' của tác giả nhé, đọc rất cuốn!
"Xem clip thì thấy rành rành,
Mở IDE lên... mắt thành quầng thâm.
Hóa ra học code âm thầm,
Là xem cho biết, còn làm... tính sau!"
Cảm ơn bài viết thức tỉnh con tim đang lạc lối trong 'Tutorial Hell' của mình nhé!
THẢO LUẬN
Bài tổng hợp đúng cái em cần luôn
Cảm xúc mô tả nghe rất chân thật, đọc xong bài này chắc người phỏng vấn mới là người phải đổ mồ hôi ấy chứ, dù sao cũm cảm ơn b nhé😁
rồi nha e Saga Pattern link bài viết: https://viblo.asia/p/microservices-thuc-chien-saga-pattern-nghe-thuat-quay-xe-rollback-an-toan-giua-chon-giang-ho-phan-tan-kNLr3vqOVgA
anh có bài về saga chưa a
Hay nha bạn, tất nhiên phải đọc nhanh những change của AI trước. Tuy nhiên cũng có 1 vài giải pháp cho những vấn đề bạn kể trên khiến các agentic AI hoạt động 1 cách hiệu quả hơn. Mình sẽ viết nó trong loạt bài viết dịp "Mayfest" lần này. Hãy đón chờ nhé🥰
Cảm ơn góc nhìn của bạn nha! Quartz quả thực rất xuất sắc trong việc lập lịch phân tán (Clustered Scheduler) và giải quyết được vấn đề chạy trùng lặp tốt hơn ShedLock.
Tuy nhiên, Quartz chỉ giải quyết tốt bài toán 'Khi nào chạy' (Trigger) chứ chưa giải quyết triệt để bài toán 'Chạy như thế nào' (Orchestration) của các luồng nghiệp vụ phức tạp. Nếu Job đối soát tài chính dài hạn bị sập giữa chừng, Quartz chỉ có thể restart lại từ đầu (dễ gây lỗi double-spend nếu code không được xử lý idempotency cực kỳ kỹ).
Temporal đóng vai trò là một durable state machine, giúp lưu lại trạng thái từng bước chạy và phục hồi chính xác tại điểm sập. Cộng thêm khả năng quản lý retry/timeout và giao diện Web UI theo dõi trực quan, Temporal mang lại sự tin cậy cao hơn hẳn cho hệ thống tài chính bên mình. Rất mong nhận được thêm các đóng góp tiếp theo từ bạn!
anh zai đừng trêu em nữa 🤣
3 năm mới thấy bác comeback 👋
Đọc bài của tác giả mới thấy cuộc chiến giữa JDK Dynamic Proxy và CGLIB nó ly kỳ như phim cung đấu vậy. Ông thì bắt buộc phải có Interface danh chính ngôn thuận mới chịu làm việc, ông thì chơi chiêu bẻ lái tạo Class con để lách luật. 😂 Tác giả phân tích nguồn gốc của 'gã thư ký' này rất sâu và trực quan, đọc xong phần 1 này mới thấy tự tin để sang phần 2 xem gã 'bẫy' anh em mình thế nào!
Bài viết quá hay! Spring nó lo hết từ A-Z làm anh em lười lặn xuống dưới xem bộ lòng Dynamic Proxy nó chạy thế nào. Đoạn giải phẫu hành vi của Proxy và lý do vì sao gọi nội bộ bị 'vượt rào' rất rõ ràng và chuẩn chỉnh. Đã upvote và bookmark lại để gửi cho mấy đứa em trong team đọc né bẫy!
Dùng Kafka bao lâu nay cứ gọi Producer.send() rồi Consumer.poll() như một cái máy, hôm nay mới được tác giả cho đi 'nội soi' chi tiết từng mảnh ghép Segment, Commit Log bên dưới. Bài viết quá hay, đi từ bản chất thế này mới thấm được vì sao nó lại đạt được tốc độ ánh sáng như vậy. Đã upvote!
Tuyệt vời, Hóng phần 2
Lúc DB có vài nghìn dòng: OFFSET 1000000 chạy vèo vèo, tự tin mình là master kiến trúc. Lúc DB lên vài triệu dòng: Người dùng bấm sang trang cuối cùng một cái là CPU server nhảy lên 100%, sếp gọi điện hỏi thăm ngay lập tức. 😂 Bài viết phân tích đúng cái 'bẫy' kinh điển mà ai cũng từng ngã vào. Cảm ơn tác giả vì bài viết quá chất lượng và thực tế!
Rất chi tiết, cảm ơn tác giả
Lúc đọc bài viết: 'Áp dụng SOLID để code sạch, dễ mở rộng, nâng cấp hơn.' 🥰 Lúc sếp dí deadline: 'Thôi Single Responsibility cái gì tầm này nữa, gom hết vào một hàm cho nó chạy được trước 5h chiều nay đã rồi tính sau!' 😂 Tác giả phân tích cái đoạn 'nghệ thuật đánh đổi' chuẩn quá, không phải cứ nhét hết SOLID vào là thượng đẳng, quan trọng là phải đúng tầm. Bài viết quá chất lượng!
Đọc bài viết mà mồ hôi hột tự nhiên tuôn rơi, cứ ngỡ đang ngồi trong phòng phỏng vấn bị vặn hỏi: 'Em hãy giải thích cơ chế LinkedList chuyển sang Red-Black Tree khi cấu trúc của HashMap vượt quá ngưỡng (threshold)...' 😂 Tác giả giải phẫu chi tiết quá, bài viết chất lượng cứu cánh cho bao nhiêu anh em sắp đi phỏng vấn! Thank tác giả nhiều.
"Redis lưu trữ trên RAM, Nhanh như tia chớp, ai làm lại anh? Đùng một cái, mất điện nhanh, Data bay mất, anh thành người dưng." Cảm ơn bài viết chia sẻ rất chi tiết về bí kíp 'cân bằng' của tác giả nhé, đọc rất cuốn!
"Xem clip thì thấy rành rành, Mở IDE lên... mắt thành quầng thâm. Hóa ra học code âm thầm, Là xem cho biết, còn làm... tính sau!" Cảm ơn bài viết thức tỉnh con tim đang lạc lối trong 'Tutorial Hell' của mình nhé!
Khuyên mọi người là nên đọc, hơi dài chút thôi nhưng cực dễ hiểu
Giờ mới hiểu bản chất, trước giờ pv toàn bị hỏi mấy vấn đề này