topic

nodejs的异步io和事件编程对高并发访问编程很有意思。 可以看看下面的文章分析的比较透彻。 <a target=_blank href="https://cnodejs.org/topic/55145859e26684ed7ff21bd3">一道nodejs面试题对其编程的了解</a> <a target=_blank href="https://cnodejs.org/topic/533d6edbc2621e680800e0ea">深入理解node.js异步编程：基础篇 </a> 来源： CSDN 作者： iylei 链接： https://blog.csdn.net/iylei/article/details/44876035

目录 1、发送消息轨迹流程 1.1 DefaultMQProducer构造函数 1.2 SendMessageTraceHookImpl钩子函数 1.3 TraceDispatcher实现原理 2、 消息轨迹数据如何存储 2.1 使用系统默认的主题名称 2.2 用户自定义消息轨迹主题 本文沿着 《RocketMQ消息轨迹-设计篇》 的思路，从如下3个方面对其源码进行解读： 发送消息轨迹 消息轨迹格式 存储消息轨迹数据 @(本节目录) 1、发送消息轨迹流程 首先我们来看一下在消息发送端如何启用消息轨迹，示例代码如下： public class TraceProducer { public static void main(String[] args) throws MQClientException, InterruptedException { DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName",true); // @1 producer.setNamesrvAddr("127.0.0.1:9876"); producer.start(); for (int i = 0; i < 10; i++) try { { Message msg = new Message("TopicTest",

一、起航 本着从无到有，从有到优的原则，所以计划先通过web实现功能，然后再优化改写为socket的形式。 1、关于技术选型 web框架使用了之前写的gmvc框架（ 手写MVC框架（一）-再出发 ），消息存储采用存在数据库的方式，使用的框架也是前段时间写的gdao（ 手写DAO框架（一）-从“1”开始 ）。 2、项目搭建 项目本来是单项目的形式，但是考虑到将服务端、客户端分开不是很友好，所以采用了maven父子模块的形式。 其中，父pom配置如下： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.shuimutong</groupId> <artifactId>gmq</artifactId> <version>${global.version}<

consumer 消费失败，会把消息重新发往 %RETRY% + consumerGroup，这个 retry 消息会在一定时间后，真实送到 retry topic。 broker 处理发送到 retry topic 的消息： org.apache.rocketmq.broker.processor.SendMessageProcessor#consumerSendMsgBack 消息消费超过最大次数或者客户端配置了直接发送到死信队列，则把消息发送到死信队列，否则把消息发送 retry topic，虽然看起来是把消息直接写入 %RETRY% + consumerGroup 但其实在 putMessage 的时候，会把消息写入 SCHEDULE_TOPIC_XXXX // org.apache.rocketmq.store.CommitLog#putMessage if (msg.getDelayTimeLevel() > 0) { if (msg.getDelayTimeLevel() > this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel()) { msg.setDelayTimeLevel(this.defaultMessageStore.getScheduleMessageService(

分布式消息队列中间件作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性，其复杂性可见一斑，作为核心组件，有必要去深入了解学习 前言 分布式消息队列中间件主要具有以下优势： 削峰填谷 （主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦 （解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能 （当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测 （线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 笔者为什么要深入rocketmq，一方面是因为公司目前已经在线上使用了rocketmq，另一方面也是因为笔者是主要的维护人员，需要对其有个深入的了解，并且测试环境的集群之前出现了问题，虽然最终解决，但是发生的原因依旧没有找到，感觉还是需要去深入了解下，对架构和源码进行一个整体的学习以应对之后可能出现的问题 rocketmq的相关中文文档在github上应该算非常详细了，初学者应该经常去看一看，每一句思考下，能收获不少，而且其中涉及到不少概念，还是需要去理解的，不明白的话也无法深入的学习下去，地址如下： https://github.com/apache/rocketmq/tree/master/docs/cn 对于与其他中间件的比较和起源发展可参考 阿里中间件博客 了解

什么是 MQ Message Queue（MQ），消息队列中间件。很多人都说：MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是 HTTP，要么是自己开发的 TCP，但是这两种协议其实都是原始的协议。HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上 WebServer，而且还不支持长连接（HTTP 2.0 的库根本找不到）。TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。它定义了两个对象——发送数据的叫生产者；接收数据的叫消费者， 提供一个 SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议 有 Broker 的 MQ 这个流派通常有一台服务器作为 Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消费者主动轮询） 重 Topic kafka、JMS

输入数据 控制台输入 python manage.py shell进入虚拟环境 1、save插入 >>>from firstApp.models import Topic,Comment >>>from django.contrib.auth.models import User #save插入方法 >>>user=User.objects.get(username='xym') >>>topic=Topic(title='four topic',content='this is the four topic',user=user) >>>topic.save() >>>comment=Comment(content='so bad',up=123,down=321,topics_id=topic) >>>comment.save() 2、create插入 >>> user1=User.objects.get(username='xym') >>> topic_2=Topic.objects.create(title='second topic',content='this is the second topic',user=user1) >>> coment=Comment.objects.create(content='so good!',up=99,down=33

Kafka是由Apache软件基金会开发的一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 特性： （1）通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。 （2）高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。 （3）支持通过Kafka服务器和消费机集群来分区消息。 （4）支持Hadoop并行数据加载。 相关术语： （1）Broker Kafka集群包含一个或多个服务器，这种服务器被称为broker。 （2）Topic 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） （3）Partition Partition是物理上的概念，每个Topic包含一个或多个Partition. （4）Producer 负责发布消息到Kafka broker （5）Consumer 消息消费者，向Kafka broker读取消息的客户端。 （6）Consumer Group 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group

KafKa 博客教程-1 博客教程-2 kafka简介 kafka起源 Kafka是由LinkedIn开发并开源的分布式消息系统，2012年捐赠给Apache基金会，采用Scala语言，运行在JVM中，最新版本2.0.1 下载地址 kafka设计目标 Kafka是一种分布式的，基于发布/订阅的消息系统 设计目标： 以时间复杂度O(1)的方式提供消息持久化能力，对TB级别的数据也能保证常数时间复杂度的访问性能； 高吞吐率。在低配机器上也能保证每秒10万条以上消息的传输； 支持kafka server间的消息分区，分布式消费，同时保证每个Partition内消息的顺序传输； 支持离线数据和实时数据处理 scale out，支持在线水平扩展，无需停机即可扩展机器 使用消息系统的好处 解耦，冗余，扩展性，灵活性&峰值处理能力，可恢复性，顺序保证，缓冲，异步通信 对比常用消息中间件 ActiveMQ RabbitMQ Kafka produce容错，是否丢失数据 有ack模型，也有事务模型，保证至少不会丢失数据。ack模型可能会有重复消息，事务模型保证完全一致 批量形式下可能会丢失数据；非批量形式下：1.使用同步模式可能会有重复数据，2.使用异步模式可能会丢失数据 consumer容错，是否丢失数据 有ack模型，数据不会丢失，但可能会有重复数据 批量形式下可能会丢数据。非批量形式下

kafka 如何保证数据不丢失 https://www.cnblogs.com/MrRightZhao/p/11498952.html 一般我们在用到这种消息中件的时候，肯定会考虑要怎样才能保证数据不丢失，在面试中也会问到相关的问题。但凡遇到这种问题，是指3个方面的数据不丢失，即：producer consumer 端数据不丢失 broker端数据不丢失下面我们分别从这三个方面来学习，kafka是如何保证数据不丢失的 一.producer 生产端是如何保证数据不丢失的 　　1.ack的配置策略 　　acks = 0　　　　生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志。　　　　acks = 1(默认值)