消息中间件MQ之ActiveMQ学习总结(中)

昨天简单总结了看资料了解的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环境,这么干巴巴的写也没意思,剩丢丢知识点明天刷完

原文发布于微信公众号 - 赵KK日常技术记录(gh_cc4c9f1a9521)

原文发表时间:2019-06-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券