Hacker News new | ask | show | jobs
by looopTools 806 days ago
Seems nice, but are there any publicly available documentation to be able to evaluate its readiness and what languages are there libraries for? I may be blind but I cannot find any.
2 comments
wanshao 806 days ago
jpgvm is right. AutoMQ didn't modify the computation layer of Kafka, but only revamped the storage layer. This means you can use AutoMQ just like Kafka. This is very user-friendly for those who are already using Kafka and applying tools within the Kafka ecosystem.
link
jpgvm 806 days ago
If you need to ask you aren't ready for something like this.

That said, it's basically Kafka with the topic-partition persistence swapped out. So the libraries etc are just the standard Kafka libraries because the frontend listener is unmodified.

link
chenyang 806 days ago
Yes, thank you for the clarification. AutoMQ has replaced the topic-partition storage with cloud-native S3Stream (https://github.com/AutoMQ/automq/tree/main/s3stream) library, thereby harnessing the benefits of cloud EBS and S3.
link
jpgvm 806 days ago
One thing that isn't made clear is when writes are acknowledged.

Specifically is a write acknowledged when it's written to Delta WAL or when it's uploaded to object storage?

If writes are acknowledged when written to Delta WAL is it possible to lose acknowledged writes when an EBS volume becomes unavailable or does that whole partition become unwritable until the volume comes back? Or is Delta WAL itself replicated in a similar fashion to traditional Kafka storage?

link
chenyang 806 days ago
You might be interested in our strategies for managing different types of failures:

- In case of an EC2 instance failure, we take advantage of EBS's ability to be attached to multiple instances(https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes...). This allows us to quickly mount the EBS volume from the failed EC2 instance onto another Broker, facilitating a seamless failover process. - For failures that affect an entire availability zone, we utilize Regional EBS which is available in Azure and GCP: https://cloud.google.com/compute/docs/disks/regional-persist...

link
jpgvm 806 days ago
Ok yeah, multi-attach was the magic I was looking for to handle failure of instances.

Thanks!

link
chenyang 806 days ago
Yes, acknowledgments for writes occur once the data is committed to the EBS WAL, with each write operation bypassing the cache via Direct IO. Data is then asynchronously uploaded to S3.

Given that EBS already ensures various levels of data durability, AutoMQ does not replicate data. Addressing your last question regarding the scenario when an EBS volume becomes unavailable:

- AutoMQ maintains a minimal amount of data on EBS, for example, only 500MB, which can be easily cached in memory. If an EBS volume goes offline, we promptly upload all data to S3 and close all partitions on the affected broker. Subsequently, we redistribute the closed partitions to other brokers.

link