小五的个人杂货铺

消息队列在使用过程中，面临着很多实际问题需要思考： 消息可靠性消息从发送，到消费者接收，会经理多个过程： 其中的每一步都可能导致消息丢失，常见的丢失原因包括： 发送时丢失： 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机，queue将消息丢失 consumer接收到消息后未消费就宕机 针对这些问题，RabbitMQ分别给出了解决方案： 生产者确认机制 mq持久化 消费者确认机制 失败重试机制 1.生产者消息确认RabbitMQ提供了publisher...

单机部署我们在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 \...

...

惰性队列消息堆积问题当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。 解决消息堆积有两种思路： 增加更多消费者，提高消费速度。也就是我们之前说的work queue模式 扩大队列容积，提高堆积上限 要提升队列容积，把消息保存在内存中显然是不行的。 惰性队列从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下： 接收到消息后直接存入磁盘而非内存 消费者要消费消息时才会从磁盘中读取并加载到内存 支持数百万条的消息存储 基于命令行设置lazy-queue而要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列： 1rabbitmqctl set_policy Lazy "^lazy-queue$"...

死信初识死信交换机什么是死信交换机什么是死信？ 当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）： 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false 消息是一个过期消息，超时无人消费 要投递的队列消息满了，无法投递 如果这个包含死信的队列配置了x-dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，检查DLX）。 如果创建的死信交换机的类型是direct路由，或者topics主题模式，那么需要指定消息的x-dead-letter-routing-key，将被投递到哪个队列中，因为交换机下可能绑定了多个队列，交换机与队列之间绑定了一个key...

Bigkey 是指当 Redis 的字符串类型过大，非字符串类型元素过多。 危害| 内存空间不均匀（平衡）例如在 Redis Cluster 中，大量 bigkey 落在其中一个 Redis 节点上，会造成该节点的内存空间使用率比其他节点高，造成内存空间使用不均匀。 | 请求倾斜对于非字符串类型的 bigkey 的请求，由于其元素较多，很可能对于这些元素的请求都落在 Redis cluster 的同一个节点上，造成请求不均匀，压力过大。 | 超时阻塞由于 Redis 单线程的特性，操作 bigkey 比较耗时，也就意味着阻塞 Redis 可能性增大。这就是造成生产事故的罪魁祸首！导致 Redis 间歇性卡死、影响线上正常下单！ | 网络拥塞每次获取 bigkey 产生的网络流量较大，假设一个 bigkey 为 1MB，每秒访问量为 1000，那么每秒产生 1000MB 的流量，对于普通的千兆网卡（按照字节算是 128MB/s）的服务器来说简直是灭顶之灾。 而且一般服务器会采用单机多实例的方式来部署，也就是说一个 bigkey...

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 ...

规则持久化-代码仓库地址 现在，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> ...

首先，Optional是一个容器，用于放置可能为空的值，它可以合理而优雅的处理null。 不合适的使用方式 直接使用 isPresent() 进行 if 检查 -- isPresent()一般用于流处理的结尾，用于判断是否符合条件。 在方法参数中使用 Optional public void getUser(long uid, Optional<> userType); -- X 直接使用 Optional.get -- 和不做任何空判断一样，十分危险 使用在 POJO 中 -- 给序列化带来麻烦 记录一些API12345678910111213141516171819202122232425261. empty()返回一个Optional容器对象，而不是 null。建议常用⭐⭐⭐⭐2. of(T value)创建一个Optional对象，如果 value 是 null，则抛出 NPE。不建议用⭐⭐3. ofNullable(T value)同上，创建一个Optional对象，但 value...

问题记录 最后的结果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,...