mq

前言：测试服的一台kafka好久没有接收到消息了，看了下日志，maybe disk full。。。。。 问题分析： 提示很明确嘛，磁盘占用问题。想来配置broker的时候有个占比参数 diskMaxUsedSpaceRatio=75%，应该是说 磁盘占用到这个比例就开始报警了。 一开始我以为是 消息数据占到了磁盘的75%， df -h 命令 看下磁盘的占用情况 storePathRootDir=/home/rocket 看了下归属，/目录确实占用了 96%。想当然的改了存储数据的根路径到 还有41G剩余空间的/mnt目录下，重启测试写消息 还是不行， 然后立马想到 ，获取的可能是程序所在磁盘的占比，程序也在 /目录下，遂转移程序到 /mnt目录下，重启 nameserver 和 broker，写消息成功了 总结： diskMaxUsedSpaceRatio=75% 磁盘占比判断的是MQ程序所在磁盘的占比， 部署时应该将程序和数据都放在剩余空间足够的磁盘中。 后记： 刚写完博客，回去一看，又报错了，查了查还有个 storePathCommitLog 路径忘记改了， 啪啪打脸，所以记得 rocketmqHome、storePathRootDir、storePathCommitLog 都要放在空间足够的磁盘下的目录里面。。。 最后再研究，其实关注的是 commitLogDiskRatio

目标 在业务处理上经常需要使用MQ作为消息流转和分发的渠道,但不同MQ产品其提供的操作方式都有着不同的差异性存在,这样会使开发人员使用起来就相对比较麻烦;MQ Client Agent的设计目的就是提供一个统一的MQ写入规则,让开发人忽略具本MQ操作的细节,即使在更换MQ产品的时候也可以在不修改现有逻辑代码的前提下轻易达到切换不同的MQ产品能力. 功能 提供消息统一写入规则功能库 支持可配置的MQ Connection Provider 支持可以的Message Handler 结构 功能类 使用 [TestMethod] public void TestRegister() { Register register = new Register(); register.EMail = "henryfan@msn.com"; register.Name = Guid.NewGuid().ToString("N"); mClient.Enqueue(register); } [TestMethod] public void TestContact() { Contact contact = new Contact(); contact.Country = "zh"; contact.Address = Guid.NewGuid().ToString("N"); contact.City

MQ框架非常之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka。这几种MQ到底应该选择哪个？要根据自己项目的业务场景和需求。下面我列出这些MQ之间的对比数据和资料。 TPS 比较 ZeroMq 最好， RabbitMq 次之， ActiveMq 最差。这个结论来自于一下这篇文章。 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html 3 、持久化消息比较 zeroMq 不支持 ， activeMq 和 rabbitMq 都 支持 。 持久化消息主要是指： MQ down 或者 MQ 所在的服务器 down 了，消息不会丢失的机制。 4 、技术点：可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区 RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的： 持久性 、 投递确认 、 发布者证实 和 高可用性 。 所以在可靠性和可用性上， RabbitMQ 是首选，虽然 ActiveMQ 也具备，但是它性能不及 RabbitMQ 。 5 、高并发 从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的 erlang 语言。 总结

目前业界有很多MQ产品，我们作如下对比： RabbitMQ 是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。 Redis 是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战

RocketMQ是我们常用的消息中间件，在运行单元测试时，我们可能不需要真正发送消息（除非是为了测试发送消息），也不想因为连结不上RocketMQ的Broker,NameServer而影响单元测试运行。 那我们该如何Mock RocketMQ消息生产者呢？ 请看例子： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 //RocketMQ消息生产者 Mock public class RocetMQProducerMockingTest { // 把RocketMQ的生产者mock @BeforeClass public static void mockRocketMQ() { new RocketMQProducerMockUp(); } @Test public void testSendRocketMQMessage() throws Exception { DefaultMQProducer producer = new DefaultMQProducer( "test_producer" ); producer.setNamesrvAddr( "192.168.0.2:9876;192.168.0.3:9876" ); producer.start(); for ( int i = 0 ; i <

I am trying to set the Accounting Token on the a message which my system received from inbound queue. I am setting this token using the following. msg.setObjectProperty(JmsConstants.JMS_IBM_MQMD_ACCOUNTINGTOKEN,value) Also I have the following properties in my JmsSUpport class ((JmsDestination) dest).setBooleanProperty(WMQConstants.WMQ_MQMD_READ_ENABLED, true); ((JmsDestination) dest).setBooleanProperty(WMQConstants.WMQ_MQMD_WRITE_ENABLED, true); ((MQDestination) dest).setMQMDWriteEnabled(true); ((MQDestination) dest).setMQMDReadEnabled(true); ((MQDestination) dest).setTargetClient(JMSC.MQJMS

问题14--镜像发布进度一直为0，报“Error finding address for http://<ip>:9292/v2/images/<uuid>/file: [Errno 32] broken pipe” 解：1、查看/var/log/glance中的日志 2、查看glance服务状态 systemctl list-units | grep glance 3、从报错信息分析是管道端口，<ip>为一个vip，通常和rabbitmq有关，需要查mq的服务是否正常；我这里的问题是因为mq的第三个节点在调整，glance访问的时候恰好走的是第三个mq，登录api节点将/etc/glance/glance-api.conf中的rabbitmq_hosts中的第三个mq IP去掉，重启glance相关服务，就恢复正常了； 来源： CSDN 作者： wangerzheng 链接： https://blog.csdn.net/wangerzheng/article/details/88041795