e có 1 case này: có tầm 5000 msg được bắn liên tục từ producer vào nhiều topic khác nhau vậy cách phân chia broker, topic, partition, và consumer như thế nào để tối ưu tốc độ, xử lý của kafka ạ? mong được anh giải đáp, em cảm ơn ạ
ngôn ngữ viết trong @Query không phải là Navite SQL nguyên thủy, nó được gọi là HQL(Hibernate Query Language) hoặc JPQL(Java Persistence Query Language), tất nhiên nó vẫn chạy tốt khi bạn viết SQL, nhưng nó sẽ không sử dụng nguyên văn câu SQL đó để thực hiện, nên là bạn đổi DB thì những câu này vẫn sẽ chạy tốt
Sai rồi, nếu người 100 đoán sai => 1 người die
Đến người 99 đoán, cũng chỉ thấy đc 98 mũ còn lại + loại trừ mũ của người vừa die nữa là 99 vẫn còn thiếu 2 mũ chưa đoán => lại không có cơ sở để đoán tiếp, nếu đoán sai tiếp cũng die luôn. Tương tự những người sau không có cơ sở gì.
Tóm lại theo cách của bạn không có gì chắc chắn ở đây cả, thậm chí xui rủi có thể 100 người đều chết :v
Ồ một câu hỏi rất hay đến từ người em hâm mộ haha, rất vui nha.
Có ổn không nếu em tạo 1 flag isRefreshing và nếu đang isRefreshing thì sẽ không gọi api refresh token nữa anh nhỉ?
export const useRefreshToken = () => {
const { data: session } = useSession();
let isRefreshing = false;
let refreshPromise;
const refreshToken = async () => {
// Nếu đang không gọi refresh token thì gọi thôi
if (!isRefreshing) {
isRefreshing = true;
refreshPromise = Api.post("/auth/refresh-token", {
refreshToken: session?.tokens.refreshToken,
})
.then((res) => {
if (session) session.tokens.accessToken = res.data.tokens.accessToken;
else signIn();
})
.finally(() => {
isRefreshing = false;
});
return refreshPromise;
} else {
// Nếu đang có đứa khác gọi rồi thì đợi cho nó gọi mình ké là được
return refreshPromise;
}
};
return refreshToken;
};
Một câu hỏi PV mình hay hỏi ứng viên là: Vậy nếu trang web của mình đang gọi đồng thời nhiều API và bị hết hạn token cùng lúc phải refresh, vậy thì bạn sẽ xử lý thế nào? Để nó call api refresh nhiều lần luôn hở?
Anh em suy nghĩ và trả lời để bổ sung vào giải pháp xem.
hình như phải có GPT-4 mới được đúng không. Lúc mình thử nghiệm thì lỗi liên quan đến phiên bản
"RateLimitError: You exceeded your current quota, please check your plan and billing details."
mình nghĩ là bạn nên thêm bos và eos token vào các đoạn văn trong training corpus. Khi đó thì model sẽ dần học được cách dừng khi nói đủ ý, tức là khi nói đủ ý thì token tiếp theo sẽ là eos token và model sẽ dừng generate ở đấy luôn, sau đấy bạn chỉ cần set max new token lớn 1 chút là được
THẢO LUẬN
Câu trả lời này khá giống với Lê Tú đã trả lời ở trên, tuy nhiên đáp án này không chính xác vì CHỈ ĐƯỢC TRẢ LỜI 1 TRONG 101 MÀU MŨ ĐÃ CHO TRƯỚC
e có 1 case này: có tầm 5000 msg được bắn liên tục từ producer vào nhiều topic khác nhau vậy cách phân chia broker, topic, partition, và consumer như thế nào để tối ưu tốc độ, xử lý của kafka ạ? mong được anh giải đáp, em cảm ơn ạ
hữu ích quá ạaa😷
nhận học sinh k ạ :v
Disconnected rồi à bạn ?
Hoá đơn điện tử: https://vnpt-invoicepos.vn/hoa-don-dien-tu/hoa-don-dien-tu-tt78.html
"end-to-end object detection" bạn nhé
ngôn ngữ viết trong @Query không phải là Navite SQL nguyên thủy, nó được gọi là HQL(Hibernate Query Language) hoặc JPQL(Java Persistence Query Language), tất nhiên nó vẫn chạy tốt khi bạn viết SQL, nhưng nó sẽ không sử dụng nguyên văn câu SQL đó để thực hiện, nên là bạn đổi DB thì những câu này vẫn sẽ chạy tốt
Sai rồi, nếu người 100 đoán sai => 1 người die Đến người 99 đoán, cũng chỉ thấy đc 98 mũ còn lại + loại trừ mũ của người vừa die nữa là 99 vẫn còn thiếu 2 mũ chưa đoán => lại không có cơ sở để đoán tiếp, nếu đoán sai tiếp cũng die luôn. Tương tự những người sau không có cơ sở gì.
Tóm lại theo cách của bạn không có gì chắc chắn ở đây cả, thậm chí xui rủi có thể 100 người đều chết :v
Ồ một câu hỏi rất hay đến từ người em hâm mộ haha, rất vui nha. Có ổn không nếu em tạo 1 flag isRefreshing và nếu đang isRefreshing thì sẽ không gọi api refresh token nữa anh nhỉ?
@nguyen.van.quan cảm ơn bạn, nhưng nếu áp dụng model này với tiếng Việt thì sao nhỉ, mình dùng cơ chế tokenize khác hay sao ạ
Một câu hỏi PV mình hay hỏi ứng viên là: Vậy nếu trang web của mình đang gọi đồng thời nhiều API và bị hết hạn token cùng lúc phải refresh, vậy thì bạn sẽ xử lý thế nào? Để nó call api refresh nhiều lần luôn hở? Anh em suy nghĩ và trả lời để bổ sung vào giải pháp xem.
Không cần b à, bản nào cũng có thể dùng đc. Mình đã sửa code, bạn thử chạy lại xem nhé
Cảm ơn em nhé, có thời gian rảnh a sẽ viết thêm về chủ đề này
link sdn của bài viết đã bị hỏng. Tôi có thể xin link khác để vào nghiên cứu thêm về sdn rõ hơnn không?
Thực tế dự án như thế nào thì phù hợp triển khai tech stack này bạn nhỉ?
Ý tưởng hay, nhưng đáp án chưa chính xác. Chỉ được trả lời 1 trong 101 màu hợp lệ thôi nhé.
bạn có tiện gửi source code lên không nhỉ, không thì bạn cho mình xin thêm ảnh phần code html 'nhập mã + submit mã' của bạn xem, theo mình thấy thì phần code trong class "XulyDL" của bạn chỉ có method void 'processRequest' để xử lý hành động 'nhập mã + submit mã', mà trên thực tế hành động 'nhập mã + submit mã' của bạn thường sẽ là phương thức POST hoặc GET, mà mình chưa thấy method 'doPost'/'doGet' của bạn ở đâu cả. https://docs.oracle.com/en/database/oracle/oracle-database/18/tdpjd/creating-servlet-process-request.html#GUID-983136BE-A0DB-4615-A281-1A3B0C3492C3
hình như phải có GPT-4 mới được đúng không. Lúc mình thử nghiệm thì lỗi liên quan đến phiên bản "RateLimitError: You exceeded your current quota, please check your plan and billing details."
mình nghĩ là bạn nên thêm bos và eos token vào các đoạn văn trong training corpus. Khi đó thì model sẽ dần học được cách dừng khi nói đủ ý, tức là khi nói đủ ý thì token tiếp theo sẽ là eos token và model sẽ dừng generate ở đấy luôn, sau đấy bạn chỉ cần set max new token lớn 1 chút là được