一开始以为是服务本身导致的问题，但是最近一个礼拜都没有提交记录，所以应该不是因为异常提交导致的，只能先重启服务，看看能不能恢复过来。但是重启服务之后还是报类似的错误，而且不只一个服务报错，所以可以确定应该是mq本身的问题。
分布式事务学习项目：流量充值中心 git地址：https://github.com/barrywangmeng/data-refill-center
Spring Cloud Bus是Spring Cloud体系内的消息总线，支持RabbitMQ和Kafka两种消息中间件。所谓消息总线，简单理解就是一个消息中心，众多微服务实例都可以连接到总线上，实例可以往消息中心发送或接收信息(通过监听)。例如：实例A发送一条消息到总线上，总线上的实例B可以接收到信息(实例B订阅了实例A),消息总线充当一个中间者的角色，使得实例A和实例B解耦，如下图所示。
一、rabbitMQ是什么： RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上。 学过websocket的来理解rabbitMQ应该是非常简单的了，websocket是基于服务器和页面之间的通信协议，一次握手，多次通信。 而rabbitMQ就像是服务器之间的socket，一个服务器连上MQ监听，而另一个服务器只要通过MQ发送消息就能被监听服务器所接收。 但是MQ和socket还是有区别的，socket相当于是页面直接监听服务器。而
上篇文章，王子通过一个小案例和小伙伴们一起分析了一下消息是如何丢失的，但没有提出具体的解决方案。
我们知道rabbitMq是Erlang语言写的。那么，我们想要安装mq的话，就需要安装Erlang环境。不同版本的mq对应的erlang不同。那么怎么知道mq与erlang的版本关系呢？我们在下载页面的右侧，可以看到有个Erlang Versions的。如下图：
一位读者跟我说，最近去某个公司面试，面试官非得问他MQ挂了如何处理？这位读者说当时也比较懵，因为在日常工作中也没去想过这样的问题，就回答：挂了就报错了呗，马上重启呗，还能咋处理。
下图是一个非常典型的生产环境的问题，很多公司都会在生产系统里使用MQ，即消息队列。
IPC的意思是“ 进程间通信机制”，Linux内核有三种常用IPC对象可以拿来做进程间通信--消息队列，共享内存，信号量。这三种IPC对象在Linux内核中都以链表的形式存储，它们都有特定的ID来标识（消息队列标识符msqid、共享内存标识符shmid，信号量标识符semid）。
一、写在前面 二、可靠消息最终一致性方案的核心流程 二、可靠消息最终一致性方案的高可用保障生产实践
在Linux中cookie的位置一般在 /var/lib/rabbitmq/.erlang.cookie
消息重复和幂等问题是很常见的问题，这俩问题基本可以放在一起。 既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题即实际生产上的系统设计问题。
问题 现象：消费者接收不到MQ的消费数据，MQ管理后台数据阻塞。 排查 发现阻塞的队列(queue)找不到消费者(consumer)服务器。报错：… no consumers … 解决 删除队列，点击删除按钮(Delete) 结果 队列(queue)找到消费者(consumer)服务器，大功告成。 注意 本方式只适用非生产环境，目的是熟悉rabbitMQ管理后台，具体生产环境问题具体分析。
提供轻量级服务发现和路由。 每个名称服务器记录完整的路由信息，提供相应的读写服务，并支持 快速存储扩展。
一篇文章，想了很久，Spring-data-jpa，Spring-secuity都是想写的，不过由于代码量和深度都不小，最近又在使用mq，就想写一些关于mq的使用和看法，等mq结束，就准备Spring-data-jpa的编写。下班晚，家离的又远，常常回家就快11点了，所以就利用晚上回家的一点时间，以及早上5点钟左右起来写文章，想一边写，一边知识的积累，一边给大家一些干货的分享，文章是自己写，所以可能会有一些代码或者是架构，知识点上的问题，希望大家多多见谅，能多多的反馈。 RabbitMQ是一个消息代理。 官
最近在培训压测平台中，因为需要使用到消息队列，考虑到很多同学的电脑windows不支持很多开源消息队列的原因，加上复杂繁重的那些中间件大家部署安装总是出错。所以自研了一个超轻量级的小工具：django-task-mq
opendevops是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。 opendevops前端基于Vue iview开发、为用户提供友好的操作界面，增强用户体验。 opendevops后端基于Python Tornado开发，其优势为轻量、简洁清晰、异步非阻塞。 opendevops开源多云管理平台为用户提供多功能：ITSM、基于RBAC权限系统、Web Terminnal登陆日志审计、录像回放、强大的作业调度系统、CMDB、监控报警系统等
首先我们想一下，两个公司之间如果有互相调用接口的业务需求，如果没有引入中间件技术，是怎么实现的呢？
在去年编写自动化测试平台的时候，因为存在发送邮件、异步执行自动化任务、执行定时任务、模块解耦等需求。需要使用MQ，我选择的是RabbitMQ。
MQ全称（MessageQueue）又名消息队列，是一种异步通讯的中间件。可以将它理解成邮局，发送者将消息传递到邮局，然后由邮局帮我们发送给具体的消息接收者（消费者），具体发送过程与时间我们无需关心，它也不会干扰我进行其它事情。常见的MQ有 kafka、 activemq、 zeromq、 rabbitmq 等等，各大MQ的对比和优劣势可以自行 Google
现在网上很多面试题，主要是针对技术本身的提问，比如：你聊聊对Dubbo的理解？你说说分布式事务是什么？
公司缓存设计： 1. 希望启动后就进行缓存相关的加载,更新等操作,所以定义了一个继承ApplicationRunner的静态类,在其中写了一些启动后刷新的逻辑,同时用scheduleAtFixedRate做一个定时任务,进行相关的定时刷新.还有主动的刷新方法load,供实时数据的刷新使用 2. 数据要求有一定的实时性,故加了一组消息队列,在其他业务对数据产生变更时,发送mq消息,展示端门户收到mq消息后,主动刷新 第一次产生问题: 经常有一些缓存的时间存活很长,或者当缓存失效后,直接查询数据库 解决方案:
在Java开发环境中JDK内置了java.util.Properties类用于读取.properties文件,在Java应用开发时广泛用于读取参数配置文件。 最近在C++环境下做一个项目设计，也希望能通过读取.properties文件来获取参数配置文件.在github上找到了这个C++11实现的读取.properties文件的项目github.com/glywk/cpp_properties 。完全支持Java properteis语法。 cpp_properties使用起来很简单,全部源码都是用C++11模板类实现。没有.cpp文件，只要include进来就可以用了。但是需要boost的头文件支持。 我看到这个项目时只有2个星，非常不起眼，但代码质量是不错误的，经测试可用，因为项目的README.md写得不太完善，入手时还是摸索了些时间----后续我帮助作者更新了README.md，增加了调用示例.
rabbitmq基础概念常见应用场景导入依赖属性配置具体编码定义队列实体类控制器消息消费者主函数测试总结说点什么
本文主要探讨了Linux消息队列的发送、接收以及异步通知机制。首先介绍了消息队列的发送和接收过程，然后详细描述了异步通知的方式，最后通过一个示例展示了如何使用epoll机制实现异步通知。
之前装过3.7.x的，最新的已经到了3.8.5，RabbitMQ恶心的一点就是版本太混乱，而且每隔几个版本，安装方式都略有不同，这次再来更新一下吧。
那天我和同事一起吃完晚饭回公司加班，然后就群里就有人@我说xxx商户说收不到推送，一开始觉得没啥。我第一反应是不是极光没注册上，就让客服通知商户，重新登录下试试。这边打开极光推送的后台进行检查。后面反应收不到推送的越来越多，我就知道这事情不简单。
看这样的业务场景，A系统发送数据到 B、C、D 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果C系统现在不需要了呢？A系统负责人几乎崩溃......
一项技术的产生必然是为了解决问题而生，了解了一项技术解决的问题，就能够很轻松的理解这项技术的设计根本，从而更好地理解与使用这项技术。 消息中间件和RPC从根本上来说都是为了解决分布式系统的服务间通信问题，我们的服务从最初的单体应用发展到SOA架构到现在的微服务架构，必不可少的就是服务间通信，但从最初的设想，服务间通信仅仅就是一次请求响应调用而已，为什么发展出如此多的消息中间件与RPC技术，我们是否真的需要学习这么多的消息中间件技术？ 答案是肯定的，接下来我们将分析我们为什么要了解及使用如此多的服务间通信技术，以及他们究竟都解决了哪些问题，在什么场景下他们是必不可少的。
最近在开发中遇到一个Protostuff序列化问题，在这记录一下问题的根源；分析一下Protostuff序列化和反序列化原理；以及怎么样避免改bug。
下载地址：https://www.ibm.com/developerworks/cn/downloads/ws/wmq/
MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-activemq/2.3.1.RELEASE
最近做个小项目，基本单体应用就能满足要求。项目虽然小，但是需求可一点都不少，真是麻雀虽小，要求五脏俱全。这里面有个业务场景是需要给相应的人员发送消息通知。
jmeter可以针对MQ消息中间件进行压测。本篇讲的是activeMQ的Point-to-Point模式 Point-to-Point在MQ中称之为点对点模式。这种模式的特点是，消息只能被消费一次，阅后即焚
前言 循环依赖分为2类: RPC服务间（dubbo、http）循环依赖 应用间循环依赖 Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，防止Spring初始化完成。这种情况我们就叫做RPC服务间循环依赖。出现了循环依赖，必须有一方先启动。所以这种问题是一定需要解决的。 应用间循环依赖大致情况如下: A应用调用B应用的服务，B应用也会调用A应用的服务，无论是间接调用还是直接调用。 这种循环依赖刚开始不会出现问题 ，但随着代码变更，有可能会发展为RPC服务间循环依赖。 可以通过check=
公司为了保证系统的稳定性，加了很多监控，比如：接口响应时间、cpu使用率、内存使用率、错误日志等等。如果系统出现异常情况，会邮件通知相关人员，以便于大家能在第一时间解决隐藏的系统问题。此外，我们这边有个不成文的规定，就是线上问题最好能够当日解决，除非遇到那种非常棘手的问题。
记得我在之前某一篇博文里讲到过一个案例：使用java的守护线程来模拟redis缓存的过期时间设定。
线程并不适用于每种场景， 因此并不要求使用线程。 但是pika并不禁用线程， 对于
前段时间与大家分享了定时任务调用平台xxl-job，也简单地讲了讲平台的结构模式、调度方法。
springBoot使用gradle版本管理，在整合activeMQ的时候容易出现一个错误，那就是找不到JmsMessagingTemplate，无法匹MessagingTemplateConfiguration，全部报错信息如下：
什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。
前提：三个节点都主机映射，关防火墙网络，配好yum（后边出错，主机名和映射要对应）
若这是用MQ传递非常核心的消息，如计费系统，就是很重的业务，操作很耗时，设计上经常将计费做成异步化，就是用MQ。
很多知识细节都来自生产事故，只有经历过，才能记得住。今天的故事，也源于一次线上事故。
某天，做完产品的业务升级后，还是比较放松的。刚想搞点别的事，用户群就有用户反馈有问题。真的是不让人省心，先看问题吧。如下图，用户在添加卡片时，提示错误，无法新增，但是列表里又多出了一些数据。点击查看详情时，又提示空白。
由于本人的码云太多太乱了，于是决定一个一个的整合到一个springboot项目里面。
{"code":6000,"message":"(10050)server internal error","requestId":"2077840488935586962","clientRequestId":1231231231}
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
