各种消息中间件
都支持消息持久化,但是都有性能损耗
协议AMQP: rabitmq就是为AMQP而生的,ActiveMQ也支持, 但是性能就不好了
小公司并发低用前个就好了,
ActiveMQ
太老了, 江河日下
唯一优点是java写的
RabbitMQ
erlang写的,语言很难 ,很难看源码难以深入研究, 有问题难解决
erlang 高可用 99.999%
RocketMQ
诞生最晚,社区活跃度低,资料少
支持语言少 Java php
Java写的, 并发可以
运维难度大对技术有自信的公司可以用,
延迟队列实现方便(RabbitMQ要延迟队列就比较绕),可以做限时订单
Kafka
很强大, 很强的技术维护
使用是简单,需要强的开发团队, JVM调优 操作系统调优
需要 大数据,流计算 时用
一般就记记日志简单用下
定义
其实并没有标准定义。一般认为:
分布式系统中一个子系统，
关注于数据的发送和接收，
利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。
关键:
- 高效: 一定要快
- 可靠: 持久化,不丢失
- 异步: 发成功了就行,不用一定等人收
为什么用
低耦合,扩展性
不管是程序还是模块之间，使用消息中间件进行间接通信。
没有mq是高耦合的, 要知道彼此
加入mq, 只管发, 加了接收者的话 发送者不用改,不用知道
彼此有关系->只和mq关系
物流系统挂了, 交易系统也不会被影响
扩展性: 增加新的业务产品时，不需改动既有业务功
这是设计模式中的开闭原则（对扩展开放，对修改关闭）在架构层面的一个原则。
异步
异步通信能力，使得子系统之间得以充分执行自己的逻辑而无需等待。
发到mq就成功了, 不用等消费者真的消费完
使用场景: 让用户少等点时间, 优化了, 因为发到mq就可以返回用户完成了
如果通知用户成功了, 后面的消费者服务挂了, 没成功怎么办:
没事,消息还在mq里面, 大不了加班, 最终事件还是能完成,不会丢, 只是异步的时间更久
缓冲
缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，
对于秒杀业务来说尤为重要。
伸缩性
通过不断向集群中加入服务器的
来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
不要了 ,可以拆掉
具体使用
- 异步,让用户减少等待
- 应用解耦, 不会一个挂全部挂
-
日志系统
- 高效通讯: 纯的消息通讯。点对点消息队列，或者聊天室(同一个生产者)
-
削峰
不是mq,DB就撑不住挂了
和RPC 区别
这是RPC
对开发人员,看起来好像和单体调用本进程的方法是一样的
不同:
mq异步
-
RPC依赖性,mq松耦合
相同:
都是分布式下的 的通信方式
