消息系统(kafka，redis等）的认识

版权声明：如需转载，请写明出处 https://blog.csdn.net/weixin_43113679/article/details/90247359

学习过程中扩展自己的知识面
知识点来自郭俊(Jason Guo) ,他的技术博客文章http://www.jasongj.com/

消息系统分类

• Peer-to-Peer
  一般基于Pull或者Polling接收消息
  1. 发送到队列中的消息被一个而且仅仅一个接收者所接收，即使有多个接收者在同一个队列中侦听同一消息
  2. 即支持异步"即发及弃"的消息传送方式，也支持同步请求/应答传送方式
     
• 发布/订阅
  发布到一个主题的消息，可被多个订阅者所接收
  1. 发布/订阅即可基于Push消费数据，也可基于Pull或者Polling消费数据
  2. 解耦能力比P2P模型更强
     

看图可能会更好理解，

消息系统适用的场景

• 解耦 ：各位系统之间通过消息系统这个统一的接口交换数据。无须了解彼此的存在
• 冗余 ：部分消息系统具有消息持久化能力，可规避消息处理前的丢失的风险
• 扩展 ：消息系统是统一的数据接口，各系统可独立扩展
• 峰值处理能力 ：消息系统可顶住峰值流量，业务系统可根据处理能力从消息系统获取并处理对应量的请求
• 可恢复性 ：系统中部分组件失效并不会影响整个系统，它恢复后仍然可从消息系统中获取并处理数据
• 异步通信 ：在不需要立即处理请求的场景下，可以将请求放入消息系统，合适的时候再处理

解释峰值处理能力:以秒杀为例:平常流量1千万，但是到秒杀时流量到1亿，不能因为流量过大，把自己的系统压垮了，也不能因为这个专门提高系统的业务处理能力:限流是一个很好的方式,消息系统也挺好，把流量引入消息系统里，进行排队，业务系统根据自己的处理能力把消息系统里的流量根据队列取出来进行处理：
例:秒杀时把1亿的流量引入消息队列，自己系统的业务处理能力是2千万/s，那就根据队列的排序把这一亿的流量用5秒的时间处理完，最后的结果是系统不会被压垮，顶多有延迟

常用消息系统对比

1. RabbitMQ：
   　　 erlang编写，支持多协议AMQP，XMPP，XMTP，STOMP，支持负载均衡，数据持久化。同时支持Peer-to-Peer和发布/订阅模式(比较重量级)
2. Redis：
   　　基于Key-value对的NoSQL数据库，同时支持MQ功能，可做轻量级队列服务使用。就入队操作而言，Redis对短消息(小于10kb)的性能比RabbitMQ好，长消息的性能比RabbitMQ差(经常用于分布式的缓存系统)
3. ZeroMQ：
   　　轻量级，不需要单独的消息服务器或中间件，应用程序本身扮演该角色，Peer-to-Peer，它实质上是一个库，需要开发人员自己组合多种技术，使用复杂度高，门槛高，不支持持久化，很难做到异步，
4. ActiveMQ：
   　　JMS(指定java消息队列的一个接口)实现，Peer-to-Peer，支持持久化，XA事务，主要是用java实现
5. kafka/Jafka
   　　高性能跨语言的分布式发布/订阅消息系统，数据持久化，全分布式，同时支持在线和离线处理
6. MetaQ/RocketMQ
   　　 纯ava实现，发布/订阅消息系统，支持本地事务和XA分布式事务

kafka设计目标

• 高吞吐率:在廉价的商用机器上单机可支持每秒100万条消息的读写
• 消息持久化：所有消息均被持久化到磁盘，无消息丢失，支持消息重放
• 完全分布式：Producer，Broker，Consumer均支持水平拓展
• 同时满足适应在线流处理和离线批处理

希望未来的自己看到这篇博客时把这上面的消息系统都仔细的研究一遍