karenshii
Senior Member
haha, code nhàn quá nên mới có time hóng bảng điện ấy chứĐánh chứng thua quá lại vác phím đi culi ah anh bò húc. Có project thì ới tôi với nha, lõm quá rồi.
via theNEXTvoz for iPhone
thảo luận Nên chọn message queue nào
- Người tạo chủ đề chetdoi89
- Ngày bắt đầu
via theNEXTvoz for iPhone
dark_matter
Senior Member
học thì cứ vọc 1, 2 cái tiêu biểu. Giờ có Docker nên mấy cái message queue này test local cũng đơn giản hơn. Vọc nhiều hơn thì code thử ví dụ Embedded ActiveMQ, setup Virtual Topic etc..
Đi làm thì tuỳ infra cty hoặc dự án. (Vd IBM Webphere MQ)
Nắm vững kiến thức về Message Queue là được. Ví dụ queue, topic, queue topic bridging, message selector với monitoring tool như Grafana, Prometheus.
Đi làm thì tuỳ infra cty hoặc dự án. (Vd IBM Webphere MQ)
Nắm vững kiến thức về Message Queue là được. Ví dụ queue, topic, queue topic bridging, message selector với monitoring tool như Grafana, Prometheus.
ColdBailey
Đã tốn tiền
Kafka không phải đơn giản chỉ là message queue. Ngay trang chủ nó nói nó là event streaming platform
================
Apache Kafka is an open-source distributed event streaming platform
https://kafka.apache.org/
dienbien001
Senior Member
Prometheus + Grafana bác ạCho em hỏi bình thường các bác dùng tool gì để monitor thằng kafka nhỉ? Kiểu giống như pgAdmin cho postgres ấy. Em có tìm hiểu thấy kcat mà thằng này tải về window lằng nhằng quá.
gaconkute
Senior Member
bác thu thập những metric gì
cũng đúng, nhưng so sánh Pull và Push tốt hơn
ColdBailey
Đã tốn tiền
Devops cty đang host thằng này, web based nhưng chưa hài lòng lắm.Cho em hỏi bình thường các bác dùng tool gì để monitor thằng kafka nhỉ? Kiểu giống như pgAdmin cho postgres ấy. Em có tìm hiểu thấy kcat mà thằng này tải về window lằng nhằng quá.
https://github.com/provectus/kafka-ui
dienbien001
Senior Member
Prometheus cứ pull kafka metric về thôi bác. Muốn hiển thị gì thì grafana lấy lên thôi. Consumer lag, produce, consumer fetch, message in, bytes in, bytes out, ...
marmot
Junior Member
Đồng ý bác ạ!
ngorung1
Junior Member
Tùy thuộc tính huống thôi! Vấn đề của Brokerless là nó không có broker
. Message Broker trong hệ thống tổng thể về mặt kiến trúc có những giá trị nhất định:
Service Discovery: Thằng consumer chỉ cần biết tới broker và topic (msg type) mà chẳng cần quan tâm tới Producer, Brokerless thì ngược lại nên khi có nhiều producer/consumer thì ... hơi mệt! Có thể dùng DNS làm Service Discovery nhưng cũng hạn chế nhiều.
Decouple: Tương tự như trên, các service giao tiếp thông qua broker sẽ giảm sự phụ thuộc vào nhau.
Ngoài ra thì các tính năng/yêu cầu về hạ tầng Application Message cũng dễ implement (có nhiều lợi thế) khi có một broker đứng giữa: Communication Topology (Topic, Exchange, PubSub...), Messages Storage (Kiểu Event Storage như Kafka), Queue Logic, Failover...
Brokerless thì mọi thứ ... đơn giản chỉ là các thư viện giao tiếp giữa các ứng dụng, ngon thì có thêm các component để Failover, Storage.... nhưng nói chung là ít case sử dụng khi các thể loại Message Broker sẵn có! Thực tế thì thị trường Message Middleware phát triển tương đối sôi động mấy chục năm nay, project fail thì nhiều nhưng cũng học được nhiều thứ và thể loại Brokerless nó ít phát triển cũng có lý do của nó!
Darabeny
Senior Member
Phần mình nói đó là đặt trong cluster. Tức là đã có Service Discovery rồi.Tùy thuộc tính huống thôi! Vấn đề của Brokerless là nó không có broker
Message Broker trong hệ thống tổng thể về mặt kiến trúc có những giá trị nhất định:
Service Discovery: Thằng consumer chỉ cần biết tới broker và topic (msg type) mà chẳng cần quan tâm tới Producer, Brokerless thì ngược lại nên khi có nhiều producer/consumer thì ... hơi mệt! Có thể dùng DNS làm Service Discovery nhưng cũng hạn chế nhiều.
Decouple: Tương tự như trên, các service giao tiếp thông qua broker sẽ giảm sự phụ thuộc vào nhau.
Ngoài ra thì các tính năng/yêu cầu về hạ tầng Application Message cũng dễ implement (có nhiều lợi thế) khi có một broker đứng giữa: Communication Topology (Topic, Exchange, PubSub...), Messages Storage (Kiểu Event Storage như Kafka), Queue Logic, Failover...
Brokerless thì mọi thứ ... đơn giản chỉ là các thư viện giao tiếp giữa các ứng dụng, ngon thì có thêm các component để Failover, Storage.... nhưng nói chung là ít case sử dụng khi các thể loại Message Broker sẵn có! Thực tế thì thị trường Message Middleware phát triển tương đối sôi động mấy chục năm nay, project fail thì nhiều nhưng cũng học được nhiều thứ và thể loại Brokerless nó ít phát triển cũng có lý do của nó!
Bạn tham khảo thử Vert.x Cluster.
Còn viêc Decouple thì mình đồng ý là nó sẽ phụ thuộc vào nhau (cùng 1 cách serialize/deserialize) nên đôi khi sẽ không thể sử dụng kiểu micro-service nhiều ngôn ngữ/framework khác nhau. (Default Buffer của Vert.x hay cơ chế Trivially Copyable Serialization của Chronicle). Giống như việc thống nhất đồng bộ protobuf (chưa nói đến HTTP/2) của gRPC thì lại giúp cho hiệu năng trở nên tốt hơn.
ngorung1
Junior Member
Nếu chơi nguyên cái Vert.x Cluster (i.e Zookeeper) thì đã có một phần khá lớn của Message Platform rồi. Brokerless thực chất là nhúng các chức năng Message tại Application luôn. Lợi thế là không phải comunicate thông qua một node trung gian, nhưng với mạng cluster giờ toàn 10-25-40Gbps thì giảm latency cũng chẳng đáng là bao mà việc quản lý vận hành phức tạp hơn. Giải pháp kiểu brokerless có vẻ phục vụ cho các tính huống đặc thù như kiểu HFT, lúc đó tự custom Message Platform theo yêu cầu để tối ưu và cái giá thì ... lớn. Giờ thử so sánh 2 giải pháp:
1. Brokerless với các component: Vert.x Cluster (Cluster Management), Vert.x Eventbuss (Communication), Chronicle (Storage & Simple Queue, Có thể thay thế bằng Apache BookKeeper cho phần storage và tự implement queue)
2. General Broker như Apache Pulsar được builtin với các component: Zookeeper, Apache BookKeeper và Pulsar ....
Có thể thấy rõ luôn là nếu chơi kiểu Brokerless là tự build lại Message Platform theo kiểu lắp ghép các component để giải quyết một case cụ thể nào đó. Hàng thửa kiểu này thường scope nhỏ và đặc thù nên bắt buộc thì phải làm chứ cũng chẳng có lợi nhiều. Đó còn chưa kể có một số tính năng cần kết hợp giữa 2 component thì build vỡ mặt: Kiểu như Pulsar nó support cross-datacenter replication, đây là tính năng kết hợp giữa storage và communication component! dùng brokerless build thì cũng ... vỡ mặt
gaconkute
Senior Member
bác chơi cả vertx event bus cơ à :3 Spring follow cái reactive từ Vertx :3
Darabeny
Senior Member
Câu này thì hoàn toàn đồng ý với hầu hết các điểm, cái giá... lớn và nó đặc thù phù hợp cho HFT cần latency thấp cho mấy cái trading các kiểu.
Tạm bỏ qua Chronicle vì mình chưa thực sự impl 1 dự án nào dùng Chronicle cả, custom lắp ghép đặc thù mới thì đúng là vỡ mặt, và khi thực sự cần thiết thì sẽ làm.
Nói về hệ sinh thái của Vert.x, mình đoán là bạn chưa thực sự dùng Vert.x hoặc chưa sử dụng đến thứ này. Ngoài eventbus Zookeeper, thì 3 cái còn lại đều là in-mem cache. Với tư tưởng của việc horizontal scale mỗi khi service tham gia cluster thì nó cũng sẽ scale in-mem cache này lên. Và business sẽ chủ yếu thực hiện trên tầng cache này. Nhất là Ignite với cơ chế read through và write through.
Nhưng tất nhiên sẽ tốn thêm 1 lượng ram cho tầng in-mem cache này. Và nhược điểm của mỗi loại in-mem cache này thì cũng không phải không có.
Nó cũng là ý tưởng kết hợp giữa storage và communication như trên.Đó còn chưa kể có một số tính năng cần kết hợp giữa 2 component thì build vỡ mặt: Kiểu như Pulsar nó support cross-datacenter replication, đây là tính năng kết hợp giữa storage và communication component! dùng brokerless build thì cũng ... vỡ mặt
Nói chung là mình đang muốn tham khảo các góc nhìn khác. Chứ không phải kiểu phản biện cãi nhau đâu nhé
Darabeny
Senior Member
Đánh giá chủ quan thì reactive của Spring nó phèn quá bác. Kiểu mang tư tưởng của Spring nhưng ép nó thành reactive nên cứ bị nửa nạc nửa mỡ. Không ra sao cả.
Và quan trọng là nó không ngon được như Vert.x
ps: Mình có code cả Spring nhé!!
ngorung1
Junior Member
Storage trong context của Message Infrastructure là nói đến tính năng persistent xuống đĩa cững để tránh mất dữ liệu. Cái này là must have của một message infrastructure. Chronicle, BookKeeper implement phần này cho phép ghi dữ liệu ở mức vài triệu msg/s; Khi nói đến fault tolerance thì mấy cái in-memory không có ý nghĩa lắm mặc dù về lý thuyết các component như ignite đều có cơ chế persistent nhưng nó không được tối ưu cho lưu trữ kiểu này.Câu này thì hoàn toàn đồng ý với hầu hết các điểm, cái giá... lớn và nó đặc thù phù hợp cho HFT cần latency thấp cho mấy cái trading các kiểu.
Tạm bỏ qua Chronicle vì mình chưa thực sự impl 1 dự án nào dùng Chronicle cả, custom lắp ghép đặc thù mới thì đúng là vỡ mặt, và khi thực sự cần thiết thì sẽ làm.
Nói về hệ sinh thái của Vert.x, mình đoán là bạn chưa thực sự dùng Vert.x hoặc chưa sử dụng đến thứ này. Ngoài eventbus Zookeeper, thì 3 cái còn lại đều là in-mem cache. Với tư tưởng của việc horizontal scale mỗi khi service tham gia cluster thì nó cũng sẽ scale in-mem cache này lên. Và business sẽ chủ yếu thực hiện trên tầng cache này. Nhất là Ignite với cơ chế read through và write through.
Nhưng tất nhiên sẽ tốn thêm 1 lượng ram cho tầng in-mem cache này. Và nhược điểm của mỗi loại in-mem cache này thì cũng không phải không có.
Nó cũng là ý tưởng kết hợp giữa storage và communication như trên.
Nói chung là mình đang muốn tham khảo các góc nhìn khác. Chứ không phải kiểu phản biện cãi nhau đâu nhé
Eventbus của Vert.x thì thuần túy là communication bus, để tránh data loss thì người dùng phải tự handle!
Mình không rành Vert.x lắm nhưng theo mình hiểu thì mấy cái Cluster của Vert.x là các Cluster Management component được build dựa trên một số tools (Hazelcast, Zookeeper) của Java, Cái này thường được dùng theo dạng shared state để quản lý thông tin chung như metadata và implement một số tính năng của cluster management như service discovery. Đơn giản nó là một cái distributed storage dựa trên các giải thuật consesus dạng strong consistent (ZAB chẳng hạn)
ryannguyen0303
Senior Member
Trước product công ty em dùng AWS QSQ được 1 thời gian mà vụ fault tolerance với guarantee ordering nản quá giờ phải chuyển vội qua redis, kafka. Nếu muốn nhanh gọn lẹ thì cứ SQS còn muốn ngon thì né sớm cho đỡ rách việc
Chủ đề tương tự
