昨天简单总结了看资料了解的MQ基本知识点，实际操作以后，会有地方与预想不一致，多次试验后解决，为了加强记忆，需要根据官网文档继续整理，并尽可能实践，没有什么特殊平台要求，不要跟我说直接读官网吗，读源码，你咋那能呢？专业名词那么多，语义表达逻辑又不一样，你要说你专业级口语畅通交谈，我自闭了！
MQ在Linux中主要为了搭配后期的服务高可用，现在的技术部跟高可用，持久化，分布式，集群沾点边，都不好意思在这泱泱子民的华夏露面了，总的来说你就发现用法不一样，但逻辑，理念一个样。
呼！根据刷面试题总结实践来看，动不动是手写Spring框架，手写Tomcat，手写MQ的，看把你能的，什么网易云课堂，腾讯享学课堂我都跟着刷过，你咋不手写了Java呢，能离开基本理念算我输！
不废话，还得手把手把MQ的整合，特性等测试完，但家里现在电脑没有Linux，只能多写理论知识了，回头周末再补。
MQ的发布模式主要为Queue，Topic，简单理解一下-
Queue:就相当于synchronize，串行，一对一，这种理念，你发给我一条消息，先传到腾讯服务器，再转发给我，我手机关机，消息也不会丢失。
Topic:翻译是主题，但是在官网中可以看到，点击Subscribers(订阅)
才显示细节消息，相当于，并发，一对多，微信公众号，你在未订阅之前的消息，是不被接收的，当你订阅后，我一个人发布消息到公众号，到服务器，订阅者为多人，那么这些订阅者都会收到消息。
JMS的组成结构：消息服务，可理解为Http请求，你发布消息，和发送请求，关注的除了消息本身，更多关注的是消息头，消息体，消息属性等；
角色分为消息的提供者(Procvider)----MQ服务器
生产者( Producer)----发布消息客户端
消费者(consumer)----消费消息
消息(message)
虽然英文专业名词不行，但是我会翻译啊！
但是你看看
好好的broker应为MQ的实例，结果给翻译成3个结果，你说看官网文挡，哪能简单就理解么！
消息先订阅 再发布 订阅后取关的再关注 历史消息还会推送
消息重复消费
消费者事务为true 但是未提交
session.commit()提交后，正常
MQ的持久化
说到持久化，第一个想起的就是redis的持久化特性，RDB,AOF
把消息放入数据库，物理内存的方式最为有效，但是频繁读写的就影响IO，说道IO就得说什么哦空间复杂度！！！
割！
1.0：mq的持久化
①：AMQ
②：KahaDb（默认）事务日志 索引
③：JDBC ：MQ MySql
④：LevelDB（开启5G时代）
⑤：JDBCPlus（Journal）先访问journal，在访问JDBC，避免频繁读写
2.0:高可用 redis zookeeper 主从集群
今天到此为止，早上起的有点早，天气现在有热，有没有Linux环境，这么干巴巴的写也没意思，剩丢丢知识点明天刷完
