rabbitmq的安装(单机,集群)
单机部署我们在Centos7虚拟机中使用Docker来安装。 下载镜像1docker pull rabbitmq:3-management 安装MQ执行下面的命令来运行MQ容器: 123456789docker run \ -e RABBITMQ_DEFAULT_USER=itcast \ -e RABBITMQ_DEFAULT_PASS=123321 \ --name mq \ --hostname mq1 \ -p 15672:15672 \ -p 5672:5672 \ -d \ rabbitmq:3-management MQ集群集群分类RabbitMQ的是基于Erlang语言编写,而Erlang又是一个面向并发的语言,天然支持集群模式。RabbitMQ的集群有两种模式: •普通集群:是一种分布式集群,将队列分散到集群的各个节点,从而提高整个集群的并发能力。 •镜像集群:是一种主从集群,普通集群的基础上,添加了主从备份功能,提高集群的数据可用性。 镜像集群虽然支持主从,但主从同步并不是强一致的,某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本...
rabbitmq消息可靠性
消息队列在使用过程中,面临着很多实际问题需要思考: 消息可靠性消息从发送,到消费者接收,会经理多个过程: 其中的每一步都可能导致消息丢失,常见的丢失原因包括: 发送时丢失: 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机,queue将消息丢失 consumer接收到消息后未消费就宕机 针对这些问题,RabbitMQ分别给出了解决方案: 生产者确认机制 mq持久化 消费者确认机制 失败重试机制 1.生产者消息确认RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后,会返回一个结果给发送者,表示消息是否处理成功。 返回结果有两种方式: publisher-confirm,发送者确认 消息成功投递到交换机,返回ack 消息未投递到交换机,返回nack publisher-return,发送者回执 消息投递到交换机了,但是没有路由到队列。返回ACK,及路由失败原因。 注意: 1.1.修改...
学习rabbitmq
1.初识MQ1.1.同步和异步通讯微服务间通讯有同步和异步两种方式: 同步通讯:就像打电话,需要实时响应。 异步通讯:就像发邮件,不需要马上回复。 两种方式各有优劣,打电话可以立即得到响应,但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件,但是往往响应会有延迟。 1.1.1.同步通讯我们之前学习的Feign调用就属于同步方式,虽然调用可以实时得到结果,但存在下面的问题: 总结: 同步调用的优点: 时效性较强,可以立即得到结果 同步调用的问题: 耦合度高 性能和吞吐能力下降 有额外的资源消耗 有级联失败问题 1.1.2.异步通讯异步调用则可以避免上述问题: 我们以购买商品为例,用户支付后需要调用订单服务完成订单状态修改,调用物流服务,从仓库分配响应的库存并准备发货。 在事件模式中,支付服务是事件发布者(publisher),在支付完成后只需要发布一个支付成功的事件(event),事件中带上订单id。 订单服务和物流服务是事件订阅者(Consumer),订阅支付成功的事件,监听到事件后完成自己业务即可。 为了解除事件发布者与订阅者之间的耦合,两者并不...
惰性队列
惰性队列消息堆积问题当生产者发送消息的速度超过了消费者处理消息的速度,就会导致队列中的消息堆积,直到队列存储消息达到上限。之后发送的消息就会成为死信,可能会被丢弃,这就是消息堆积问题。 解决消息堆积有两种思路: 增加更多消费者,提高消费速度。也就是我们之前说的work queue模式 扩大队列容积,提高堆积上限 要提升队列容积,把消息保存在内存中显然是不行的。 惰性队列从RabbitMQ的3.6.0版本开始,就增加了Lazy Queues的概念,也就是惰性队列。惰性队列的特征如下: 接收到消息后直接存入磁盘而非内存 消费者要消费消息时才会从磁盘中读取并加载到内存 支持数百万条的消息存储 基于命令行设置lazy-queue而要设置一个队列为惰性队列,只需要在声明队列时,指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列: 1rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy&...
死信及延迟队列
死信初识死信交换机什么是死信交换机什么是死信? 当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter): 消费者使用basic.reject或 basic.nack声明消费失败,并且消息的requeue参数设置为false 消息是一个过期消息,超时无人消费 要投递的队列消息满了,无法投递 如果这个包含死信的队列配置了x-dead-letter-exchange属性,指定了一个交换机,那么队列中的死信就会投递到这个交换机中,而这个交换机称为死信交换机(Dead Letter Exchange,检查DLX)。 如果创建的死信交换机的类型是direct路由,或者topics主题模式,那么需要指定消息的x-dead-letter-routing-key,将被投递到哪个队列中,因为交换机下可能绑定了多个队列,交换机与队列之间绑定了一个key ,即BindingKey,投递消息时指定一个RoutingKey,只有BindingKey与RoutingKey匹配成功,该条消息才会被交换机投递到相应BindingKey的队列 如图,一个消息被消费者拒绝了,变成了死信: ...
bigkeys处理方案
Bigkey 是指当 Redis 的字符串类型过大,非字符串类型元素过多。 危害| 内存空间不均匀(平衡)例如在 Redis Cluster 中,大量 bigkey 落在其中一个 Redis 节点上,会造成该节点的内存空间使用率比其他节点高,造成内存空间使用不均匀。 | 请求倾斜对于非字符串类型的 bigkey 的请求,由于其元素较多,很可能对于这些元素的请求都落在 Redis cluster 的同一个节点上,造成请求不均匀,压力过大。 | 超时阻塞由于 Redis 单线程的特性,操作 bigkey 比较耗时,也就意味着阻塞 Redis 可能性增大。这就是造成生产事故的罪魁祸首!导致 Redis 间歇性卡死、影响线上正常下单! | 网络拥塞每次获取 bigkey 产生的网络流量较大,假设一个 bigkey 为 1MB,每秒访问量为 1000,那么每秒产生 1000MB 的流量,对于普通的千兆网卡(按照字节算是 128MB/s)的服务器来说简直是灭顶之灾。 而且一般服务器会采用单机多实例的方式来部署,也就是说一个 bigkey 可能会对其他实例造成影响,其后果不堪设想...
DOCKER部署sftp,ftp
sftp搭建,拉取镜像1docker pull docker.io/atmoz/sftp //也可不拉取,在执行docker run命令时会自动拉取 持久化上传的文件12345docker run --name sftp -v /opt/sftp:/home/admin/upload -p 23:22 -d atmoz/sftp admin:admin:::upload--name sftp 容器名称admin:admin:::upload 其中admin为用户名,admin为密码,upload为上传的文件会保存到容器里面的/home/admin/upload目录里面-p 23:22 将宿主机的23端口映射到容器的22端口,这样方位宿主机的23端口则会转发到容器的22端口上-d atmoz/sftp 使用dockup hub中的atmoz/sftp镜像创建容器 12# 远程登录sftp -P portNum user@sftpServerIP ftp搭建,拉取镜像1docker pull fauria/vsftpd 查看端口占用12netstat -an...
sentinel规则持久化到nacos
规则持久化-代码仓库地址 现在,sentinel的所有规则都是内存存储,重启后所有规则都会丢失。在生产环境下,我们必须确保这些规则的持久化,避免丢失。 1.规则管理模式规则是否能持久化,取决于规则管理模式,sentinel支持三种规则管理模式: 原始模式:Sentinel的默认模式,将规则保存在内存,重启服务会丢失。 pull模式 push模式 1.1.pull模式pull模式:控制台将配置的规则推送到Sentinel客户端,而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询,更新本地规则。 1.2.push模式push模式:控制台将配置规则推送到远程配置中心,例如Nacos。Sentinel客户端监听Nacos,获取配置变更的推送消息,完成本地配置更新。 2.实现push模式1.引入依赖引入sentinel监听nacos的依赖: 1234<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>se...
记录gitbook部署github pages
安装node(目前测试高于10的版本会有问题,安装10即可)这里使用nvm安装及配置安装路径不能有空格和中文 安装gitbook-cli1npm --registry https://registry.npm.taobao.org install gitbook-cli -g gitbook初始化,SUMMARY(可选,可以将现有文件copy至此)1gitbook init 编写SUMMARY文档,book.json,执行构建编译1gitbook install 在gitbook 的项目里点击 settings ,找到 GitHub Pages 在本地环境中先将编译文档到 docs 目录(这里我新增了一个 Blog.md 文件) ,在 SUMMARY.md 中添加访问链接后可直接在左侧的目录树显示命令行中键入gitbook build . docs,将文件都编译到 docs 目录下 然后将编译好的文件 PUSH 到远端仓库123$ git add *$ git commit -m"Inital commit"$ git push orgin mas...
hexo博客展示git提交记录
hexo-githubcalendar方式(推荐)博客参考链接: https://zfe.space/post/hexo-githubcalendar.html github地址: https://github.com/Zfour/hexo-github-calendar hexo-filter-gitcalendar方式(此方式已被弃用)安装1npm install hexo-filter-gitcalendar --save 自建API部署新建项目,fork项目打开dashboard点击新建项目的New Project按钮。点击导入第三方库。 填入Zfour提供的自建 API 项目地址:1https://github.com/Zfour/python_github_calendar_api.git 进入下一步后,点击create, 之后会自动进行deploy, 如整合waline中介绍, 会生成DOMAIN 修改主题配置文件配置文件可参考: https://akilar.top/posts/1f9c68c9/
