小五的个人杂货铺

Spring boot集成mongodb1、集成简介spring-data-mongodb提供了MongoTemplate与MongoRepository两种方式访问mongodb，MongoRepository操作简单，MongoTemplate操作灵活，我们在项目中可以灵活适用这两种方式操作mongodb，MongoRepository的缺点是不够灵活，MongoTemplate正好可以弥补不足。 2、搭建开发环境2.1 初始化工程使用 Spring Initializr 快速初始化一个 Spring Boot 工程 2.2 引入依赖修改pom.xml 12345678910111213141516171819202122232425262728293031323334<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-...

foreach元素的属性主要有collection，item，index，open，separator，close。 123456789101112131415161718- collection: 要做foreach的对象，作为入参时，List对象默认用"list"代替作为键，数组对象"array"代替作为键，Map对象没有默认的键。在作为入参时可以使用@Param("keyName")来设置键，设置keyName后，list,array将会失效。除了入参这种情况外，还有一种作为参数对象的某个字段的时候。举个例子：如果User有属性List ids。入参是User对象，那么这个collection = "ids".如果User有属性Ids ids;其中Ids是个对象，Ids有个属性List id;入参是User对象，那么collection = "ids.id"- item：集合中元素迭代时的别名，该参数为必选。- index：在list和数组中,index是元素的序号，在m...

服务器A的IP 服务器B的IP 192.168.56.110 192.168.56.111 创建持久化文件夹 1234#在192.168.56.110上执行命令mkdir -p /home/rabbitmq/cluster/rabbitmq01#在192.168.56.111上执行命令mkdir -p /home/rabbitmq/cluster/rabbitmq02 启动RabbitMQ 1234#在192.168.56.110上执行docker run -d --hostname rabbitmq01 --name rabbitmq01 --add-host=rabbitmq01:192.168.56.110 --add-host=rabbitmq02:192.168.56.111 -v /home/rabbitmq/cluster/rabbitmq01:/var/lib/rabbitmq --privileged=true -p 15672:15672 -p 5672:5672 -p 5671:5671 -p 4369:4369 -p 25672:2...

消息队列在使用过程中，面临着很多实际问题需要思考： 消息可靠性消息从发送，到消费者接收，会经理多个过程： 其中的每一步都可能导致消息丢失，常见的丢失原因包括： 发送时丢失： 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机，queue将消息丢失 consumer接收到消息后未消费就宕机 针对这些问题，RabbitMQ分别给出了解决方案： 生产者确认机制 mq持久化 消费者确认机制 失败重试机制 1.生产者消息确认RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。 返回结果有两种方式： publisher-confirm，发送者确认 消息成功投递到交换机，返回ack 消息未投递到交换机，返回nack publisher-return，发送者回执 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。 注意： 1.1.修改...

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

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的队列 如图，一个消息被消费者拒绝了，变成了死信： ...

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