消息中间件-简介
1.分布式消息中间件
分布式系统：组件分布在网络计算机上 + 组件之间通过消息来协调行动
中间件： 为应用程序提供操作系统所提供的服务之外的服务，简化应用程序的通信、输入输出的开发，使他们专注于自己的业务逻辑
分布式消息中间件： 支持在分布式系统中发送和接受消息的硬件或软件基础设施
2.功能
功能需求核心的其实就发送消息和消费消息，细化下去，发送需求会有同步发送、异步发送，会有实时消息、定时消息等；消费需求会有各种模式，比如业务方主动Pull、或者消息中间件Push的模式等等
与RPC的区别： RPC和消息中间件的场景的差异很大程度上在于就是“依赖”和“量”。比如短信通知服务并不是事交易环节必须的，并不影响下单流程，不是强依赖，所以交易系统不应该依赖短信服务。比如一些数据分析程序可能需要在拿到一天的总销售量，这个就只需要销售中心提供接口在需要时调用即可。
业务解耦：交易系统不需要知道短信通知服务的存在，只需要发布消息
削峰填谷：比如上游系统的吞吐能力高于下游系统，在流量洪峰时可能会冲垮下游系统，消息中间件可以在峰值时堆积消息，而在峰值过去后下游系统慢慢消费消息解决流量洪峰的问题
事件驱动：系统与系统之间可以通过消息传递的形式驱动业务，以流式的模型处理
3.组成
Topic：从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合
Partition：分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息
producer + consumer + broker
nameserver：用于服务发现，Kafka-ZooKeeper，RocketMQ-重写了NameServer服务
group：用于标志Consumer的身份，拥有相同Group名称的Consumer一般消费一类消息，且消费逻辑是相同的
集群消费：一类Consumer（即Group相同的Consumer的集合）共同完成对一个Topic的消费
广播消费：Topic中的每一条消息都会被一类Consumer（属于同一个Group的多个Consumer）中的每个Consumer实例消费
4.消息发送
实时消息：Producer发送一条消息，这条消息对Consumer是立即可见的，会尽快被消费掉的
定时消息：Producer发出一条消息后，这条消息不是立即可见，可以被消费的。它需要等待一个固定时间之后才能被Consumer进行消息。
事务消息：消息是业务操作绑定在一起的，要么业务操作成功且消息发送成功，如果业务操作失败，消息是需要回滚的。
消息发送还会有顺序性的要求，消息的消费顺序需要和发送顺序保持一致
5. 消息消费
提供集群消费和广播消费，另外对消息获取的方式也会有特定的需求，比如一些业务方是期望由他们自己主动去获取消息的，另一些会要求以监听的模式，即提供Listener当有新消息时触发Listener（pull or push）
6.位点重置、消息跟踪、消息堆积
7.性能
延迟：对业务系统而言，它本身不会容忍在执行消息发送时消耗过多的时间，因为过长的耗时将直接影响它系统的吞吐，所以一般对消息的发送延迟要求都是毫秒级的，平均需要在2ms左右吧。对消费也是一样，对实时性要求比较高的系统响应的会期望消息从发送出来到被消费到的这个时间尽可能的短。
吞吐：因为直接影响到使用MQ的业务系统的性能，所以也是需要一个超过业务系统吞吐上限的能力。
8.可用性
可用性是指系统可以提供服务的正常运行时间和总运行时间的比值，为了满足可用性的要求，系统需要做备份等等
9.可靠性
在消息中间件中，业务方对可靠性的要求主要集中在消息会不会丢失。消息不丢失也是对消息中间件最最基础的要求