共计 2926 个字符，预计需要花费 8 分钟才能阅读完成。
音讯队列
什么是音讯队列
举一个简略的例子：在网上买了海鲜，快递小哥给我送快递的时候我正好在下班，家中无人签收。而快递又不能推延送，可能会造成海鲜腐坏，而快递小哥还须要派送其他人的快递，此时就陷入了僵局。
此时家中楼下正好有一个便利店，快递小哥将快递放入便利店，而我上班后再去便利店中取。这样就防止了僵局的产生。
原来快递小哥和我之间的分割就变成了快递小哥和便利店分割，而我回去后或有工夫了再和便利店分割。便利店成为了中转地。
例子中的便利店便相当于音讯队列，而快递小哥相当于生产者。我相当于消费者。这就是音讯的三个重要组成。而音讯队列有蕴含很多其余的重要组成。
在上边的例子中音讯队列的次要作用是解耦合。
音讯队列的作用还有削峰填谷，异步解决，日志解决，音讯通信等
音讯队列的劣势
同异步解决流程比照：
同步解决
异步解决
减少零碎响应速度
削峰填谷：
- 服务器在接管到用户申请后，首先写入音讯队列。这时如果音讯队列中音讯数量超过最大数量，则间接回绝用户申请或返回跳转到谬误页面；
- 秒杀业务依据秒杀规定读取音讯队列中的申请信息，进行后续解决。
日志解决：
- 日志采集客户端：负责日志数据采集，定时写受写入 Kafka 队列；
- Kafka 音讯队列：负责日志数据的接管，存储和转发；
- 日志解决利用：订阅并生产 kafka 队列中的日志数据；
- Kafka：接管用户日志的音讯队列。
- Logstash：做日志解析，对立成 JSON 输入给 Elasticsearch。
- Elasticsearch：实时日志剖析服务的核心技术，一个 schemaless，实时的数据存储服务，通过 index 组织数据，兼具弱小的搜寻和统计性能。
- Kibana：基于 Elasticsearch 的数据可视化组件，超强的数据可视化能力是泛滥公司抉择 ELK stack 的重要起因。
音讯通信：
点对点通信架构设计中，客户端 A 和客户端 B 共用一个音讯队列，即可实现音讯通信性能。
客户端 A、客户端 B、直至客户端 N 订阅同一音讯队列，进行音讯的公布与接管，即可实现聊天通信计划架构设计。
音讯队列的毛病
- 零碎可用性升高：零碎可用性在某种程度上升高，在退出 MQ 之前，你不必思考音讯失落或者说 MQ 挂掉等等的状况，然而，引入 MQ 之后你就须要去思考了。
- 零碎复杂性进步：退出 MQ 之后，你须要保障音讯没有被反复生产、解决音讯失落的状况、保障消息传递的程序性等等问题！
- 一致性问题：我下面讲了音讯队列能够实现异步，音讯队列带来的异步的确能够进步零碎响应速度。然而，万一音讯的真正消费者并没有正确生产音讯怎么办？这样就会导致数据不统一的状况了!
音讯队列的标准规范
JMS（JAVA Message Service,java 音讯服务）是 java 的音讯服务，JMS 的客户端之间能够通过 JMS 服务进行异步的音讯传输。JMS（JAVA Message Service,Java 音讯服务）API 是一个音讯服务的规范或者说是标准，容许应用程序组件基于 JavaEE 平台创立、发送、接管和读取音讯。它使分布式通信耦合度更低，音讯服务更加牢靠以及异步性。
JMS 两种音讯模型
①点到点（P2P）模型
应用 队列（Queue）作为音讯通信载体；满足 生产者与消费者模式，一条音讯只能被一个消费者应用，未被生产的音讯在队列中保留直到被生产或超时。比方：咱们生产者发送 100 条音讯的话，两个消费者来生产个别状况下两个消费者会依照音讯发送的程序各自生产一半（也就是你一个我一个的生产。）
② 公布 / 订阅（Pub/Sub）模型
公布订阅模型（Pub/Sub）应用 主题（Topic）作为音讯通信载体，相似于 播送模式 ；发布者公布一条音讯，该音讯通过主题传递给所有的订阅者， 在一条音讯播送之后才订阅的用户则是收不到该条音讯的。
JMS 五种不同的音讯注释格局
JMS 定义了五种不同的音讯注释格局，以及调用的音讯类型，容许你发送并接管以一些不同模式的数据，提供现有音讯格局的一些级别的兼容性。
- StreamMessage — Java 原始值的数据流
- MapMessage– 一套名称 - 值对
- TextMessage– 一个字符串对象
- ObjectMessage– 一个序列化的 Java 对象
- BytesMessage– 一个字节的数据流
AMQP
AMQP，即 Advanced Message Queuing Protocol, 一个提供对立音讯服务的应用层规范 高级音讯队列协定（二进制应用层协定），是应用层协定的一个凋谢规范, 为面向音讯的中间件设计，兼容 JMS。基于此协定的客户端与消息中间件可传递音讯，并不受客户端 / 中间件同产品，不同的开发语言等条件的限度。
JMS vs AMQP
- AMQP 为音讯定义了线路层（wire-level protocol）的协定，而 JMS 所定义的是 API 标准。在 Java 体系中，多个 client 均能够通过 JMS 进行交互，不须要利用批改代码，然而其对跨平台的反对较差。而 AMQP 人造具备跨平台、跨语言个性。
- JMS 反对 TextMessage、MapMessage 等简单的音讯类型；而 AMQP 仅反对 byte[] 音讯类型（简单的类型可序列化后发送）。
- 因为 Exchange 提供的路由算法，AMQP 能够提供多样化的路由形式来传递音讯到音讯队列，而 JMS 仅反对 队列 和 主题 / 订阅 形式两种。
音讯队列比照
- ActiveMQ 的社区算是比拟成熟，然而较目前来说，ActiveMQ 的性能比拟差，而且版本迭代很慢，不举荐应用。
- RabbitMQ 在吞吐量方面尽管稍逊于 Kafka 和 RocketMQ，然而因为它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。然而也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做 erlang 源码级别的钻研和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种音讯队列中，RabbitMQ 肯定是你的首选。如果是大数据畛域的实时计算、日志采集等场景，用 Kafka 是业内规范的，相对没问题，社区活跃度很高，相对不会黄，何况简直是全世界这个畛域的事实性标准。
- RocketMQ 阿里出品，Java 系开源我的项目，源代码咱们能够间接浏览，而后能够定制本人公司的 MQ，并且 RocketMQ 有阿里巴巴的理论业务场景的实战考验。RocketMQ 社区活跃度绝对较为个别，不过也还能够，文档相对来说简略一些，而后接口这块不是依照规范 JMS 标准走的有些零碎要迁徙须要批改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被摈弃，社区黄掉的危险，那如果你们公司有技术实力我感觉用 RocketMQ 挺好的
- kafka 的特点其实很显著，就是仅仅提供较少的外围性能，然而提供超高的吞吐量，ms 级的提早，极高的可用性以及可靠性，而且分布式能够任意扩大。同时 kafka 最好是撑持较少的 topic 数量即可，保障其超高吞吐量。kafka 惟一的一点劣势是有可能音讯反复生产，那么对数据准确性会造成极其轻微的影响，在大数据畛域中以及日志采集中，这点轻微影响能够疏忽这个个性人造适宜大数据实时计算以及日志收集。
转载：https://www.jianshu.com/p/689…
转载:https://www.jianshu.com/p/36a…
