学习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...
Reactive编程学习记录(长期)-知识及编程技巧
问题记录 最后的结果Flux、Mono一定要作为方法返回值,因为响应式编程的异常信息保存在这些结果中(而不是在方法调用时抛出),所以这些结果必须作为方法返回值,否则Spring无法知道方法是否报错 常用api记录 如果要操作数据,并返回一个Mono的时候,使用flatMap 一般如果不操作数据,仅数据转换,使用map 订阅者是由Spring框架去完成,我们(开发)写发布者代码 zipWith方法可以组合两个Mono/Flux,并返回新的Mono/Flux类型 take(x)适合取flux中前x个,而当flux就一个元素的适合,可以使用next()将flux转为mono flatMapMany适合将Mono<数组/集合>转换为Flux 当希望合并多个流操作的时候,可以使用Mono.zip/Flux.zip Mono.zip(memberLevelMono, giftCardMono, couponMono).map... zipWith方法会同时请求待合并的两个Mono数据,而zipWhen方法则会阻塞...
Reactive编程学习记录总结
webmvc和webflux的一些区别组件 执行过程webmvc webflux 写法(返回一个视图)webmvc webflux(路由式写法),webflux也支持了mvc的注解使得一般项目可以无压力替换为webflux框架 思想webmvc(命令式编程)1假如有一个式子a=b+c,这就意味着a的值是由b和c计算出来的。如果b或者c后续有变化,不会影响到a的值 webflux(响应式编程)123式子a:=b+c,这就意味着a的值是由b和c计算出来的。但如果b或者c的值后续有变化,会影响到a的值--变化传递 例子(3y) 1234567private String createStr() { try { TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { } return "some string";} webmvc123456private String get1() &...
记录RouterFunction方式如何实现全局异常拦截
在使用mvc编程方式下,全局异常拦截可使用如下方式123456789101112131415/** * @author 小五 */@Slf4j@RestControllerAdvice@RequiredArgsConstructorpublic class DefaultExceptionHandlerConfig { @ExceptionHandler(BeHappyException.class) //@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ResponseEntity beHappyExceptionHandler(BeHappyException e){ log.error("BeHappy Exception: {}",e.getMsg()); return ResponseEntity.internalServerError().body(e); }} 在使用路由...
记录Reactive编程模式下如何方便的debug
通过打开全局 Operator 堆栈追踪 未开启之前 开启之后 这种方法同等与在方法内部输出以下代码1234//打开Hooks.onOperatorDebug();//关闭Hooks.resetOnOperatorDebug();
