各位运用Java展开开发工作的朋友们，你们可曾萌生出这样的想法过，即存在一个借助Java编写而成的消息队列，它能够被直接制作成jar包而后嵌入到你的项目之中，并且通过代码来实现启动以及配置的操作，如此这般的感觉是不是会显得颇为畅快呢？特别是处于某些特定的场景之下，比如说你有数量达到十万个的硬件设备需要连接上来，并且每一个设备都要求进行用户名以及密码的验证操作，在这种时候将队列嵌入到项目内部，使其随着项目的启动而一同启动，这简直是便利至极了。

内嵌启动的爽点

对于Java开发者而言，能够直接借助代码去操作消息队列，着实省去了相当多的麻烦事。你无需再特意前往服务器之上进行安装配置一整套环境，也不必在部署项目之际额外启动一个服务进程。直接于Spring或者普通Java项目当中，引入依赖，编写寥寥几行代码，队列便运行起来了。这样的集成方式在开发以及测试阶段尤其实用，能致使你将注意力集中于业务逻辑之上，而非耗费精力折腾环境配置。

以你所提及的十万设备接入情形为例，每个设备均具备自身的凭证，如果运用外置的MQ服务，你或许需要另行编写一套认证接口。或者配置复杂度颇高的插件，然而在进行内嵌操作之后，你能够全然借助Java编写一个权限验证装置，直接于凭借项目连接的数据库当中查找这十万个用户名与密码，认证逻辑同你的业务代码实现无缝对接。数据源也达成了统一，维护起来会使轻松程度增添不少。

基础概念与使用

提及，其所给出的基础观念颇为直观。一个被称作队列（queue）的东西能够关联多个消费者，然而这些消费者必须彼此相互认亲，标明自身归属于同一个消费组范畴。在安装完毕之后，它同样存在实例的概念，你能够如同创建数据库那般，构建不同的实例，进而在其中创建用户、划分权限，这套管理体系对于那些使用过数据库的人而言，上手不存在什么阻碍。

从消息模型去看，它是存在既有队列之意，队列也就是queue，同时还有主题的概念，主题即topic。在发消息之际，你能够指定一个路由键，此路由键就是key，而这个key后续会被用以决定消息应当送往何处。然而有趣的是，消费者这边显得单纯，他们仅仅负责从队列当中拿取消息，根本接触不上交换机也就是exchange那一层。这种设计致使消费者的逻辑变得极为简单，只负责进行处理，并不关心消息是怎样来的。

默认行为与简单路由

对新手而言，默认行为具备友好性。倘若你未作任何指定，它便会拥有一个属于默认直连类型的交换机。一旦你未手动去绑定队列与交换机之间的关系，那默认情况下将会依据消息的 key 展开匹配，即 key 是什么，消息就会被送至与之同名的队列当中。此时，你发送一条消息，将 key 指定为“order”，相应而言消息就会顺顺利利地跑到名称叫唤”order” 的队列里。

将代码里的基础参数进行设置 ， 像是把某个值设定为 1 ， 如此便能够达成多个消费者轮流去消费 ， 每次仅取一条 ， 处理完毕之后再去取下一条。 这样的模式极为契合需要负载均衡的任务处理情景。 其本质上运用的依旧是直连交换机 ， 借助绑定 key 的方式来达成精准投递 的任务。 要是期望两个队列都能接收到同一条消息 ， 也就是广播模式 ， 那就将它们都绑定至同一个交换机上面 ， 在绑定之时指定相同的 key ， 如此便形成了扇出 （ fanout） 交换机的效应。

灵活路由与高级特性

倘若你发觉直连交换机欠缺灵活性，意欲运用通配符去匹配一批键，那么便能够思索主题（topic）交换机。比如说你界定了“stock.usd.*”这般的规则，就能够匹配到一切以stock.usd起始的键。如此一来消息便能依据更为繁杂的规则，被路由至各异的队列之中。

存在着另外一种被称作头部（headers）交换机的东西，它并非依据key来进行操作，而是借助消息自身所带的头信息之中的键值对去实现路由。然而，官方文档针对这个的阐述并不多，平常大家基本上也不会用到它。死信队列偶尔会依靠这个，不过仅仅是少数情形而已。在进行使用的时候吗，你或者是某一个队列的消费者，或者是某一个主题的订阅者。要是你打算同时针对多个主题进行订阅，那就不得不自行在消费端这儿的代码当中编写逻辑以便达成要求。

集群架构与数据高可用

提及集群，其玩法存在较多情况。它规定起码得有一台机器充当磁盘节点，以此来实现队列、交换机等定义信息的持久化作业，而其余节点能够全部是内存节点，仅专司消息流转差事。然而在普通集群模式当中，存在一个关键要点需要予以留意：队列里的消息数据并非在所有机器上都呈现冗余态势。举例来讲，三台机器构建了集群，它们对配置予以共享，可是一条消息抵达第一台机器那儿后，另外两台机器并无此条数据。

从高可用的角度去思考，如若存数据的那台机器出现挂掉的情况，消息便会丢了。为将这个问题予以解决，它对镜像队列模式予以支持，会把队列当中的数据同样复制到集群里的多台机器之上。然而如此做性能必定会比普通集群要低，原因在于每一条消息都得花费时间去复制到其他节点上。这属于典型的用性能来换取可靠的做法，适用于对数据安全有着极高要求的业务。

对比Kafka的优势与短板

和Kafka相较而言，存在一些地方是不一样的。在RabbitMQ当中，当消费者将消息消费完毕之后，消息便会被删除掉，并不存在重复消费这样的概念。然而Kafka却并非如此，它队列里的消息会依据一定策略留存一段时间，消费者借助指定偏移量去读取数据，可以想从哪里读取就从哪里读取。而且Kafka还对每个消费者组的消费进度进行维护，下次再来的时候能够接着读取。

Kafka的核心优势在于，它能使消费者达成规模化，于传统队列模式当中，一组消费者需消费一个队列，每条消息仅给予其中一人，此乃队列模式，而在发布订阅模式里，一条消息会给到所有订阅者，然而却无法让一组人分工去消费同一个主题的系列消息。Kafka借助分区（partition）的设计，既达成了消息的冗余存放以及高可用，又能够让一个消费者组里的群员分工协作，各自消费若干个分区，彼此互不干扰。

假设要去处理数量巨大的消息，或开展数据的初步清洗工作，Kafka所具备的流式计算功能是极为便利的。并且创建Topic虽说属于份量较重的一种操作，不过对此做出分区数的调整便能够较为轻松地应对消息量快速增长的状况。与之形成对照，创建数以万计的Topic是相当容易达成的，这确切呈现出你能够让各个硬件设备去订阅自身专属的Topic，从而实现精准无误的推送。然而Kafka在这个具体的方向上比较孱弱，创建过多的Topic所产生的成本是非常高昂的。所以在内嵌的场景使用，在简单的场景使用，于大规模分布式的场景使用Kafka，它们各自都拥有独特的专长技能 了。

当你看到这里之时，你究竟是更加倾向于在项目内部嵌入通过代码实施的控制方式呢，还是心甘情愿去独立部署一整套Kafka以此来应对高并发的诸多场景呢，欢迎在评论放置区域分享你所做出的这般抉择以及曾经遭遇过的那些阻碍与失误之处，点一下赞从而让更多的朋友能够看到这一份全面的对比阐述，把它收藏存好等到日后进行选型之际再翻找出来观察查看一番！