Về phân chia partition. Chủ tus đã có đề cập đến "Mỗi topic partition có khả năng xử lý 10 MB/s". B cân nhắc size của message để tính toán partition cụ thể. Ngoài ra nếu b quan tâm để latency, trên blog của confluent cũng đưa ra công thức limit partition/broker được tính bằng công thức 100 * b * r (b: số lượng broker trong cụm, r: replication factor)
Về topic. Mỗi topic được tạo ra phụ thuộc vào bussiness và requirement của bài toán. Nôm na phải trả lời được câu hỏi: Tạo topic với mục đích gì.
Còn broker. Cụ thể hơn là Kafka broker nằm trong 1 Kafka Cluster được deploy nên nhiều server. Nó giải quyết vấn đề "Single-point failure" cũng như đảm tính high reliable , số lượng broker thường là 3, 5, 7, 10, Cái này phụ thuộc vào hạ tầng của b, hiểu đơn giản b có càng nhiều server -> high reliable càng cao. Nhưng chắc bạn không muốn phung phí tiền cho một việc không cần thiết lắm.
Cuối cùng là consumer, nó cx phụ thuộc vào message + partion để tránh bottle neck.
Để đưa ra một tính toán chung cụ thể thì b nên define thêm size của message
bởi vì máy của e chưa cài redis đó e, ở đầu bài a đã nói là trước khi làm bài này thì e phải đảm bảo là máy e đã cài và chạy redis.
lỗi kia báo là Laravel kết nối tới cổng 6379 (cổng mặc định của redis) thì ko kết nối được -> redis chưa chạy.
e cài redis vào máy nhé (Search google cách cài theo hệ điều hành), hoặc đơn giản nhất là e cài docker vào và chạy redis cho a . a khuyên là nên dùng docker cho tiện nhanh và ít lỗi lầm khi chạy.
Sau khi cài Docker thì e tạo file docker-compose.yml:
Mình thấy việc sử dụng Dragonfly phù hợp cho môi trường Kubernetes gồm nhiều node có khả năng autoscale, các ứng dụng được đóng gói thành Docker Image có kích thước lớn. Khi quá trình scale diễn ra, việc bật ứng dụng trên Node mới sẽ nhanh hơn do Image được pull từ cache thay vì trực tiếp từ Image Registry
@NGUYENQUANGTUYEN vấn đề này thì 1 2 câu comment không thể nói rõ được đâu ạ :v cách tokenize mà mình giới thiệu trong bài chỉ là cách nguyên thủy nhất, các phương pháp tokenization của LLM phức tạp hơn nhiều. Bạn có thể thử tìm hiểu qua BPE tokenization được sử dụng khá phổ biến trong các LLM với course của huggingface:
https://huggingface.co/learn/nlp-course/chapter6/5?fw=pt
Thực ra mình thấy login cũng không làm thay đổi dữ liệu nên có thể dùng GET vì login API sẽ chỉ lấy về token mà thôi. Còn nếu bạn vẫn muốn cùng POST chẳng hạn thì cũng có thể phá lệ khi ngoài meta-data bạn có thể đưa token vào giá trị trả về.
@vitqst này là bác sử dụng webhook để quét liên tục, nhưng hình như là không có cách trực tiếp từ telegram bot -> google scripts hả bác. Em tìm mà không thấy, đa số đều qua webhook để làm.
ở ví dụ cuối, nếu từ khóa final là để không để hàm bị override được trong các lớp dẫn xuất, thế mình ghi từ khóa virtual ở đầu làm gì ấy nhỉ? kiểu anh đã xác định hàm của anh là ảo ở lớp cơ sở (từ khóa virtual) mục đích để các lớp dẫn xuất override hàm của anh, thế giờ anh lại ghi tiếp từ khóa final để không override được hàm ở lớp cơ sở? hòa vốn thế nhỉ?
Bạn có ví dụ nào chỉ rõ chức năng của từ khóa final một cách hữu ích được không?
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 ạ
THẢO LUẬN
chào ,mình muốn tìm hiểu mã nguồn 1 website upload file ảnh trên mạng,thì dùng lệnh curl lấy được 0
Về phân chia partition. Chủ tus đã có đề cập đến "Mỗi topic partition có khả năng xử lý 10 MB/s". B cân nhắc size của message để tính toán partition cụ thể. Ngoài ra nếu b quan tâm để latency, trên blog của confluent cũng đưa ra công thức limit partition/broker được tính bằng công thức 100 * b * r (b: số lượng broker trong cụm, r: replication factor)
Về topic. Mỗi topic được tạo ra phụ thuộc vào bussiness và requirement của bài toán. Nôm na phải trả lời được câu hỏi: Tạo topic với mục đích gì.
Còn broker. Cụ thể hơn là Kafka broker nằm trong 1 Kafka Cluster được deploy nên nhiều server. Nó giải quyết vấn đề "Single-point failure" cũng như đảm tính high reliable , số lượng broker thường là 3, 5, 7, 10, Cái này phụ thuộc vào hạ tầng của b, hiểu đơn giản b có càng nhiều server -> high reliable càng cao. Nhưng chắc bạn không muốn phung phí tiền cho một việc không cần thiết lắm.
Cuối cùng là consumer, nó cx phụ thuộc vào message + partion để tránh bottle neck.
Để đưa ra một tính toán chung cụ thể thì b nên define thêm size của message
bởi vì máy của e chưa cài redis đó e, ở đầu bài a đã nói là trước khi làm bài này thì e phải đảm bảo là máy e đã cài và chạy redis.
lỗi kia báo là Laravel kết nối tới cổng 6379 (cổng mặc định của redis) thì ko kết nối được -> redis chưa chạy.
e cài redis vào máy nhé (Search google cách cài theo hệ điều hành), hoặc đơn giản nhất là e cài docker vào và chạy redis cho a
. a khuyên là nên dùng docker cho tiện nhanh và ít lỗi lầm khi chạy.
Sau khi cài Docker thì e tạo file docker-compose.yml:
cuối cùng là
docker-compose up -dvậy là xong=))))
cho em hỏi khi em khai báo REDIS_CLIENT
'redis' => [
khi chạy lại thì gặp lỗi này:
No connection could be made because the target machine actively refused it [tcp://127.0.0.1:6379]
em cũng thử fix vài cách nhưng k được ạ, mong anh xem giúp e với
Mình thấy việc sử dụng Dragonfly phù hợp cho môi trường Kubernetes gồm nhiều node có khả năng autoscale, các ứng dụng được đóng gói thành Docker Image có kích thước lớn. Khi quá trình scale diễn ra, việc bật ứng dụng trên Node mới sẽ nhanh hơn do Image được pull từ cache thay vì trực tiếp từ Image Registry
Anh ơi, có cách nào để lần sau từ folder db có thể load lại db và cho vào gpt để không phải chạy lại dữ liệu không ạ ?
Bài viết bổ ích quá, mình đang gặp khúc mắc chạy parallel mobile, may mà gặp dc bài viết này
@NGUYENQUANGTUYEN vấn đề này thì 1 2 câu comment không thể nói rõ được đâu ạ :v cách tokenize mà mình giới thiệu trong bài chỉ là cách nguyên thủy nhất, các phương pháp tokenization của LLM phức tạp hơn nhiều. Bạn có thể thử tìm hiểu qua BPE tokenization được sử dụng khá phổ biến trong các LLM với course của huggingface: https://huggingface.co/learn/nlp-course/chapter6/5?fw=pt
vnpt hồ chí minh: https://vnptwifi24h.com/ Tổng đài cskh vnpt hcm: 0911612618 ( đăng ký dịch vụ vnpt hcm)
viết chả khác gì đi copy bài
Thực ra mình thấy login cũng không làm thay đổi dữ liệu nên có thể dùng GET vì login API sẽ chỉ lấy về token mà thôi. Còn nếu bạn vẫn muốn cùng POST chẳng hạn thì cũng có thể phá lệ khi ngoài meta-data bạn có thể đưa token vào giá trị trả về.
@vitqst này là bác sử dụng webhook để quét liên tục, nhưng hình như là không có cách trực tiếp từ telegram bot -> google scripts hả bác. Em tìm mà không thấy, đa số đều qua webhook để làm.
Mỗi ngày cố gắng một chút, tích tiểu thành đại 🚀
Thank you man 🤜🤛
Anh cho em hỏi nguồn học những cái thread này ở java ở đâu ạ
bài viết hay
ở ví dụ cuối, nếu từ khóa final là để không để hàm bị override được trong các lớp dẫn xuất, thế mình ghi từ khóa virtual ở đầu làm gì ấy nhỉ? kiểu anh đã xác định hàm của anh là ảo ở lớp cơ sở (từ khóa virtual) mục đích để các lớp dẫn xuất override hàm của anh, thế giờ anh lại ghi tiếp từ khóa final để không override được hàm ở lớp cơ sở? hòa vốn thế nhỉ?
Bạn có ví dụ nào chỉ rõ chức năng của từ khóa final một cách hữu ích được không?
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 ạ