李昊轩的博客

等信息，且获取订单、推荐、物流信息分别有 500 毫秒、400 毫秒、700 毫秒的超时限制。在 Golang 并发和分布式系统中不可或缺，掌握它有助于开发高效应用。各分支任务要有超时控制，且单个分支超时时不能影响整体流程；再看自定义场景，有一个查询接口需在 1 秒内完成，要传递。在此过程中，存在诸多问题：需在。并传值，子函数中也根据需求设置超时和获取值。分别处理订单详情、推荐商品和物流信息，且这些。这里设置 1 毫秒超时，超时会输出。子goroutine。子goroutine。子goroutine。

相同消费者组内, 消费者数 > partition如上图，向test发送消息：1，2， 3，4，5，6，7，8，9只有C1能接收到消息，C2则不能接收到消息，即同一个partition内的消息只能被同一个组中的一个consumer消费。当消费者数量多于partition的数量时，多余的消费者空闲。也就是说如果只有一个partition你在同一组启动多少个consumer都没用，partition的数量决定了此topic在同一组中被可被均衡的程度，例如partition=4，则可在同一组中被最多

RocketMQ消费端有两种获取消息的方式，Push方式和Pull方式。但这两种方式都有一定的缺陷，后来采用了一种折中的方法，采用”长轮询“的方式，它既可以拥有Pull的优点，又能达到保证实时性的目的。长轮询的思想：服务端接收到新消息请求后，如果队列里没有新消息，并不急于返回，通过一个循环不断查看状态，每次waitForRunning一段时间（默认是5秒），然后再Check。Broker默认最长阻塞时间为15秒，默认情况下当Broker一直没有新消息，第三次Check的时候，等待时间超过最长阻塞时间，就

Ribbon超时与Hystrix超时问题，为了确保Ribbon重试的时候不被熔断，我们就需要让Hystrix的超时时间大于Ribbon的超时时间，否则Hystrix命令超时后，该命令直接熔断，重试机制就没有任何意义了。从上面的配置来说，ribbon超时配置为1800，请求超时后，该实例会重试1次，更新实例会重试1次。ribbon: eager-load: enabled: true # 饥饿加载(eager-load)模式 MaxAutoRetries: 1 # 对当前实例的重试次数

修改配置文件, 在配置文件加入如下:vi nacos/conf/application.propertiesspring.datasource.platform=mysqldb.num=1db.url.0=jdbc:mysql://`数据库地址`:3306/`你自定义的数据库名字`(将要执行sql恢复语句的)?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=truedb

ELK全称(elasticsearch, logstash, kibana)先下载以下三个依赖 (本文选择5.6.4版本):网速慢的话可以看我上传的连接https://download.youkuaiyun.com/download/qq_33709508/13061142kibana 下载: https://www.elastic.co/downloads/past-releases/kibana-5-6-4elasticsearch 下载:https://www.elastic.co/downloads/

NameServer简介NameServer是整个消息队列中的状态服务器，集群的各个组件通过它来了解全局的信息 。 同时，各个角色的机器都要定期向 NameServer上报自己的状态，超时不上报的话， NameServer 会认为某个机器出故障不可用了，其他的组件会把这个机器从可用列表里移除 。看下阿里中间件团队对NameServer特点总结：Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。Name Server 源码总共1000+ 行 说明了是一个非常轻量级的协调中

消息偏移量 Offsetmessage queue 是无限长的数组，一条消息进来下标就会涨1，下标就是 offset，消息在某个 MessageQueue 里的位置，通过 offset 的值可以定位到这条消息，或者指示 Consumer 从这条消息开始向后处理。message queue 中的 maxOffset 表示消息的最大 offset，maxOffset 并不是最新的那条消息的 offset，而是最新消息的 offset+1，minOffset 则是现存在的最小 offset。fileRese

RocketMQ 消费者核心配置consumeFromWhere 配置（某些情况失效：参考https://blog.youkuaiyun.com/a417930422/article/details/83585397）这个配置基本不用改，采用默认配置即可。CONSUME_FROM_FIRST_OFFSET： 初次从消息队列头部开始消费，即历史消息（还储存在 broker 的）全部消费一遍，后续再启动接着上次消费的进度开始消费。CONSUME_FROM_LAST_OFFSET： 默认策略，初次从该队列最尾开始消费

生产者常见核心配置compressMsgBodyOverHowmuch ：消息超过默认字节4096后进行压缩retryTimesWhenSendFailed : 失败重发次数maxMessageSize : 最大消息配置，默认128ktopicQueueNums : 主题下面的队列数量，默认是4autoCreateTopicEnable : 是否自动创建主题Topic, 开发建议为true，生产要为falsedefaultTopicQueueNums : 自动创建服务器不存在的topic，默认

FLUSH_DISK_TIMEOUT如果设置了 FlushDiskType=SYNC_FLUSH (默认是 ASYNC_FLUSH)，并且 Broker 没有在 syncFlushTimeout （默认是 5 秒）设置的时间内完成刷盘，就会收到此状态码。FLUSH_SLAVE_TIMEOUT如果设置为 SYNC_MASTER，并且 slave Broker 没有在 syncFlushTimeout 设定时间内完成同步，就会收到此状态码。SLAVE_NOT_AVAILABLE如果设置为 SYNC_M

Topic首先需要提到的概念是Topic。Topic是RocketMQ中的一个重要概念，RocketMQ的各组件都是围绕着Topic建立起对应关系的。在RocketMQ官方文档和本文中， Topic在不同的语境下被赋予了两种不同的语义：消息的Topic属性值在描述Consumer的订阅设置信息或消息的属性时。Topic属性为某个值的消息(单个消息或消息集合)在描述Broker，Producer和Consumer的对应关系，Queue以及负载均衡策略时。为了实现消息队列的水平扩展和

RocketMQ 介绍简介RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点：能够保证严格的消息顺序提供丰富的消息拉取模式高效的订阅者水平扩展能力实时的消息订阅机制亿级消息堆积能力选用理由：强调集群无单点，可扩展，任意一点高可用，水平可扩展。海量消息堆积能力，消息堆积后，写入低延迟。支持上万个队列消息失败重试机制消息可查询开源社区活跃成熟度（经过双十一考验）安装步骤(这里只示范单机模式)1. 上传解压安装包tar -xvf apache-rocke

死信队列死信队列：DLX，dead-letter-exchange利用DLX，当消息在一个队列中变成死信 (dead message) 之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX消息变成死信有以下几种情况消息被拒绝(basic.reject / basic.nack)，并且requeue = false消息TTL过期队列达到最大长度死信处理过程DLX也是一个正常的Exchange，和一般的Exchange没有区别，它能在任何的队列上被指定，

什么是生产端的可靠性投递保障消息的成功发出保障MQ节点的成功接收发送端收到MQ节点(Broker)确认应答完善的消息进行补偿机制生产端-可靠性传递常见解决方案：消息落库，对消息状态进行打标BIZ DB:订单数据库(或其他具体业务)MSG DB：消息数据库第1步：将订单入库，创建一条MSG(状态为0) 入MSG DB库第2步：将消息发出去第3步：监听消息应答(来自Broker)第4步：修改消息的状态为1(成功)第5步：分布式定时任务抓取状态为0的消息第6步：将状态为0的消

queueDeclarequeueDeclare 有两个重载方法Queue.DeclareOk queueDec1are() throws IOException;第一种不带任何参数的queueDeclare 方法默认创建一个由RabbitMQ 命名的(类似这种amq.gen-LhQzlgv3GhDOv8PIDabOXA 名称，这种队列也称之为匿名队列〉、排他的、自动删除的、非持久化的队列。Queue.DeclareOk queueDeclare (String queue , boolea

Massage 消息它是服务器和应用程序间传输的数据，我们在前面的样例代码种可以看到发送消息的样例；Channel.basicPublish 方法，它有几个重载方法void basicPublish (String exchange , String routingKey, BasicProperties props ,byte[) body) throws IOException ;void basicPublish (String exchange , String routingKey,

Direct Exchange (暴力匹配 routingkey 和 queueName)使用频率最高, 处理路由键。需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键 “abc”，则只有被标记为“abc”的消息才被转发，不会转发abc.def，也不会转发dog.ghi，只会转发abc。Topic Exchange(*#模式匹配)使用频率也非常高, 将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。# 匹配一个或多

虚拟机的hostname 没有正确配置会导致虚拟机的连接速度变慢 , 在RabbitMQ中格外明显 , 会导致其延迟极高查看hostnamehostnamebestkslvim /etc/sysconfig/networkNETWORKING=yesHOSTNAME=bestksl打开 hosts文件将hostname 指向 localhost问题解决!...

AMQP的出现原因和历史背景：AMQP(Advanced Message Queuing Protocol, 高级消息队列协议)出现之前，有很多的消息中间件，各个消息中间件的接口协议不一样，客户端需要根据不同的消息中间件接口，编写不同的逻辑，这就造成了应用与中间件的耦合，限制产品的选择。为了统一消息中间件的接口，就出现了AMQP。AMQP逻辑架构:我们可以看到这个是分层的, broker -> virtual host -> exchange -> queue 类似省市县的结构,