What is MSMQ and what are its top alternatives?
Top Alternatives to MSMQ
Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...
RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received. ...
- IBM MQ
It is a messaging middleware that simplifies and accelerates the integration of diverse applications and business data across multiple platforms. It offers proven, enterprise-grade messaging capabilities that skillfully and safely move information. ...
- Azure Service Bus
It is a cloud messaging system for connecting apps and devices across public and private clouds. You can depend on it when you need highly-reliable cloud messaging service between applications and services, even when one or more is offline. ...
Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License. ...
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. ...
It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. ...
It is a framework for building service-oriented applications. Using this, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. ...
MSMQ alternatives & related posts
- Open source17
- Written in Scala and java. Runs on JVM11
- Message broker + Streaming system8
- Avro schema integration4
- Suport Multiple clients2
- Partioned, replayable log2
- Extremely good parallelism constructs1
- Simple publisher / multi-subscriber model1
- Non-Java clients are second-class citizens31
- Needs Zookeeper28
- Operational difficulties8
- Terrible Packaging3
related Kafka posts
The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.
Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).
At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.
For more info:
- Our Algorithms Tour: https://algorithms-tour.stitchfix.com/
- Our blog: https://multithreaded.stitchfix.com/blog/
- Careers: https://multithreaded.stitchfix.com/careers/
#DataScience #DataStack #Data
As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.
We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.
- It's fast and it works with good metrics/monitoring232
- Ease of configuration79
- I like the admin interface58
- Easy to set-up and start with50
- Standard protocols18
- Intuitive work through python18
- Written primarily in Erlang10
- Simply superb8
- Completeness of messaging patterns6
- Scales to 1 million messages per second3
- Better than most traditional queue based message broker2
- Supports MQTT2
- Supports AMQP2
- Inubit Integration1
- Delayed messages1
- Runs on Open Telecom Platform1
- High performance1
- Clear documentation with different scripting language1
- Great ui1
- Better routing system1
- Too complicated cluster/HA config and management9
- Needs Erlang runtime. Need ops good with Erlang runtime6
- Configuration must be done first, not by your code5
related RabbitMQ posts
As Sentry runs throughout the day, there are about 50 different offline tasks that we execute—anything from “process this event, pretty please” to “send all of these cool people some emails.” There are some that we execute once a day and some that execute thousands per second.
Managing this variety requires a reliably high-throughput message-passing technology. We use Celery's RabbitMQ implementation, and we stumbled upon a great feature called Federation that allows us to partition our task queue across any number of RabbitMQ servers and gives us the confidence that, if any single server gets backlogged, others will pitch in and distribute some of the backlogged tasks to their consumers.
Hi, I am building an enhanced web-conferencing app that will have a voice/video call, live chats, live notifications, live discussions, screen sharing, etc features. Ref: Zoom.
I need advise finalizing the tech stack for this app. I am considering below tech stack:
- Frontend: React
- Backend: Node.js
- Database: MongoDB
- IAAS: #AWS
- Containers & Orchestration: Docker / Kubernetes
- DevOps: GitLab, Terraform
- Brokers: Redis / RabbitMQ
I need advice at the platform level as to what could be considered to support concurrent video streaming seamlessly.
Also, please suggest what could be a better tech stack for my app?
#SAAS #VideoConferencing #WebAndVideoConferencing #zoom #stack
- Useful for big enteprises3
- Reliable for banking transactions3
- Many deployment options (containers, cloud, VM etc)1
- High Availability1
- Easy Integration with .Net4
- Cloud Native2
- Use while high messaging need1
- Observability of messages in the queue is lacking1
- Easy to use18
- Open source14
- JMS compliant10
- High Availability6
- Distributed Network of brokers3
- Support XA (distributed transactions)3
- Docker delievery1
- Highly configurable1
- ONLY Vertically Scalable1
- Low resilience to exceptions and interruptions1
- Difficult to scale1
related ActiveMQ posts
I want to choose Message Queue with the following features - Highly Available, Distributed, Scalable, Monitoring. I have RabbitMQ, ActiveMQ, Kafka and Apache RocketMQ in mind. But I am confused which one to choose.
I use ActiveMQ because RabbitMQ have stopped giving the support for AMQP 1.0 or above version and the earlier version of AMQP doesn't give the functionality to support OAuth.
If OAuth is not required and we can go with AMQP 0.9 then i still recommend rabbitMq.
- Super fast540
- Ease of use510
- In-memory cache441
- Advanced key-value cache321
- Open source190
- Easy to deploy180
- High Availability39
- Data Structures34
- Very Scalable31
- Great community21
- "NoSQL" key-value data store17
- Sorted Sets10
- BSD licensed8
- Integrates super easy with Sidekiq for Rails background7
- Async replication7
- Keys with a limited time-to-live6
- Open Source6
- Lua scripting5
- Awesomeness for Free!4
- Runs server side LUA3
- outstanding performance3
- LRU eviction of keys3
- Written in ANSI C3
- Feature Rich3
- Performance & ease of use2
- Data structure server2
- Channels concept1
- Temporarily kept on disk1
- Dont save data if no subscribers are found1
- Automatic failover1
- Easy to use1
- Existing Laravel Integration1
- Object [key/value] size each 500 MB1
- Cannot query objects directly15
- No secondary indexes for non-numeric data types3
- No WAL1
related Redis posts
We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.
As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).
When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.
I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.
We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.
Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis for cache and other time sensitive operations.
We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.
- Varying levels of Quality of Service to fit a range of3
- Lightweight with a relatively small data footprint2
- Very easy to configure and use with open source tools2
- Easy to configure in an unsecure manner1
related MQTT posts
Kindly suggest the best tool for generating 10Mn+ concurrent user load. The tool must support MQTT traffic, REST API, support to interfaces such as Kafka, websockets, persistence HTTP connection, auth type support to assess the support /coverage.
The tool can be integrated into CI pipelines like Azure Pipelines, GitHub, and Jenkins.
For the com part, depending of more details not provided, i'd use SSE, OR i'd run either Mosquitto or RabbitMQ running on Amazon EC2 instances and leverage MQTT or amqp 's subscribe/publish features with my users running mqtt or amqp clients (tcp or websockets) somehow. (publisher too.. you don't say how and who gets to update the document(s).
I find "a ton of end users", depending on how you define a ton (1k users ;) ?) and how frequent document updates are, that can mean a ton of ressources, can't cut it at some point, even using SSE
how many, how big, how persistant do the document(s) have to be ? Db-wise,can't say for lack of details and context, yeah could also be Redis, any RDBMS or nosql or even static json files stored on an Amazon S3 bucket .. anything really