我们先来看一看主流的这个分布式消息队列都有哪些
技术选型要从哪些点着手去考虑呢？
首先就是关注各个MQ的性能优缺点，以及相应的业务场景。
在这里呢，我简单说一说这个ActiveMQ呢，它是适合于这种传统行业中小型公司，并且它的这个并发或者说消息的这个承载能力不是特别特别的优秀。
你比如说你想要去应对天猫双十一大促这种场景，ActiveMQ很明显是不满足需求。也就是说如果以后你们公司的业务呢，如果是有高并发海量数据，大流量的这么一个需求，如果想要去做服务的解耦，如果用ActiveMQ，这个明显不是说特别合适的。
但是说如果你是这种中小型的业务系统，或者是说互联网内部公司的一些边缘的系统，如果你想用ActiveMQ，完全没问题。
然后呢我们接下来继续往下看，如果是RabbitMQ，很明显是可以满足需求的。
但是呢RabbitMQ呢，它也有一个瓶颈，比如说RabbitMQ，我们后面要学习它这个集群模型，它有这种镜像队列，主要是满足这个数据不丢失，就是可靠性高可用等等，但是呢它的横向扩展能力不是特别好。
在这里呢我们对应着像ActiveMQ 、RabbitMQ， RocketMQ MQ以及kafka，其实都有自己的这个集群架构模式以及分布式的时机的这个搭建。
但是可扩展性还有这个可用性以及可维护性后面这三点就要针对某些不同的MQ他自己有自己的特点。
我举个例子，像RabbitMQ，它呢可能可扩展性不是特别好，需要你自己的去加一层中间的这个路由组，但是它的可用性和可维护性这个都是业界首屈一指的。
像我们的kafka，或者是说刚才我说的这个RocketMQ，它的扩展性是非常强的，高可用性也是具备的，然后可维护性呢可能稍微有一点点麻烦。
除了这些硬性的指标，你还要去考虑一些实际的情况，比如说结合综合的这个成本，还有这个集群的规模以及人员的成本。
人员成本指的是什么意思呢？比如说你们团队里，他可能对MQ认知不是特别特别的这个清楚，或者是说呢相对来讲有些MQ应用的不是特别多，你就要看我们公司的这个技术栈，大家对哪一种MQ比较熟悉，或者是说作为一个架构你能hold得住哪一种MQ，然后并且能满足你的业务需求，你就可以去做一个最终的一个选型。
当然你也要考虑以后的各方面，比如说扩展性，扩容伸缩性，还有可用性，数据丢了，磁盘坏了，怎么去做恢复，这个都是你需要综合去考虑的，刚才我说的就是说未来的方向规划和思考，这个都一定要有。
所以说呢针对于这个技术选项，其实不仅仅是MQ本身上的这个优缺点，一定要结合着业务场景以及对于集群搭建的一些分布式扩展性、可用性、可维护性的一些特性，以及再结合你实际的这个集群规模和人员成本
这个集群规模是什么意思呢？比如说我们如果说消息不是特别要求可靠性，对可靠性依赖不是特别高，完全可以用kafka。
为什么？因为kafka可以在很廉价的这个武器上，然后呢有着非常非常高的这个性能和这个吞吐量的表现。
