崔安兵的博客

docker-compose中有两种方式可以暴露容器的端口：ports和expose。 1 portsports暴露容器端口到主机的任意端口或指定端口，用法： 1234ports: - "80:80" # 绑定容器的80端口到主机的80端口 - "9000:8080" # 绑定容器的8080端口到主机的9000端口 - "443" # 绑定容器的443端口到主机的任意端口，容器启动时随机分配绑定的主机端口号 不管是否指定主机端口，使用ports都会将端口暴露给主机。 2 exposeexpose暴露容器给link到当前容器的容器，用法： 1234expose: - "3000" - "8000" 以上指令将当前容器的端口3000和8000暴露给link到本容器的容器。 和ports的区别是，expose不会将端口暴露给主机。

1、编辑docker.server文件1vi /usr/lib/systemd/system/docker.service 找到 [Service] 节点，修改 ExecStart 属性，增加 -H tcp://0.0.0.0:2375 1ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock -H tcp://0.0.0.0:2375 这样相当于对外开放的是 2375 端口，当然也可以根据自己情况修改成其他的。 注意：这里一定要注意安全的问题，这样本身docker没有鉴权，建议修改为内网的IP地址，例如192.168.6.6:2375 2、重新加载Docker配置生效1systemctl daemon-reload systemctl restart docker 通过浏览器访问 2375 测试一下，格式为：http://ip:2375/version 如果无法访问的话，可以尝试一下开放防火墙2375端口，具体命令如下： 1firewall-cmd --zone...

背景在本地创建了项目并使用git进行跟踪，在远程仓库创建了项目，并进行了一些初始化，例如生成了README.md Linces等文件的时候，关联远程仓库并推送的时候会出现下面的报错： 1* branch master -> FETCH_HEAD = [up to date] master -> origin/master fatal: refusing to merge unrelated histories 核心报错原因该错误是 Git 的安全机制拦截：本地仓库和远程 origin/master 分支被判定为 两个完全独立、无血缘关系 的仓库（无共同的初始提交），Git 默认拒绝合并这类「无关历史」，避免仓库数据混乱。 ✅ 你的场景补充：up to date 仅代表分支提交记录数量一致，不代表历史同源，核心矛盾是「历史无关」而非「版本不一致」。 方案 1：【最优推荐】强制合并无关历史（一行命令解决，99% 场景适用）这是 Git 官方提供的专属解决方案，直接添加参数允许合并无血缘关系的仓库，保留双方所有提交记录，是最便捷、最常用的方法： 核心命令（直接执行，一...

在 Spring MVC 中，HandlerInterceptor 是一种常用的拦截器，用于在处理请求的不同阶段插入逻辑（如认证、日志记录等）。多个拦截器的执行顺序由它们的配置顺序决定。以下是配置和执行顺序的完整指南。 拦截器的执行阶段 preHandle: 在请求被处理之前调用。 返回 true 表示继续执行，返回 false 表示中断请求。 postHandle: 在请求处理之后，但在生成视图之前调用。 可以修改返回的数据。 afterCompletion: 在整个请求完成后调用（包括视图渲染）。 拦截器的执行顺序 preHandle： 按照拦截器的添加顺序执行。 postHandle 和 afterCompletion： 按照拦截器的添加顺序 倒序 执行。 完整配置步骤1. 创建拦截器类实现 HandlerInterceptor 接口或继承 HandlerInterceptorAdapter（已过时，推荐直接实现接口）。 123456789101112131415161718192021222324import org.springf...

1.适用范围MYSQL 8.0 2.问题概述普通业务用户，在自己用户下创建了表和视图，表可以正常访问，而访问视图却报ERROR 1356 (HY000)错误，测试如下： 12345678910111213141516171819202122mysql> desc asher_test ;+-----------+-------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-----------+-------------+------+-----+---------+-------+| name | varchar(50) | YES | | NULL | || purchased | date | YES | | NULL | |+-----------+-------------+------+-----+---------+-------+2 ...

当我们在一台服务器上 启动多个服务时, 因为在 http 协议下默认端口是 80 端口， https 下默认是 443 端口,为了好记和美观我们 只能对外暴漏这两个端口。 以 http 协议 为例假设我 有个后台服务在 127.0.0.1:3000这个服务里面有个接口 /aaa/bbb如果你的 后台服务启动到 3000 端口http://xxxx.com:3000/aaa/bbb 这样也是可以访问的但是，不好记也不美观.访问时 希望http://xxxx.com/api/aaa/bbb或http://api.xxxx.com/aaa/bbb所以我们得 让 Nginx 启动到 80 端口上, 然后 Nginx 通过 /api 前缀 或 二级域名 来进行代理到 目标服务 nginx.conf 配置123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657...http { ... server { ...

WebSocket 和HTTP虽然是不同协议，但是两者“握手”方式兼容。通过HTTP升级机制，使用HTTP的Upgrade和Connection协议头的方式可以将连接从HTTP升级为WebSocket。Websocket 使用 ws 或 wss 的统一资源标志符，类似于 HTTPS，其中 wss 表示在 TLS 之上的 Websocket。如： 12ws://example.com/wsapiwss://secure.example.com/ Websocket 使用和 HTTP 相同的 TCP 端口，可以绕过大多数防火墙的限制。默认情况下，Websocket 协议使用 80 端口；运行在 TLS 之上时，默认使用 443 端口。 一个典型的Websocket握手请求如下： 客户端请求： 1234567GET / HTTP/1.1Upgrade: websocketConnection: UpgradeHost: example.comOrigin: http://example.comSec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==Sec...

在SpringBoot集成RocketMQ实现顺序消费时，实现RocketMQListener接口并指定ConsumeMode.ORDERLY 与 直接实现MessageListenerOrderly接口 本质上都是基于RocketMQ的顺序消费机制，但两者在编程模型、封装层级和使用场景上存在区别，具体如下： 1. 所属框架与封装层级不同 RocketMQListener + ConsumeMode.ORDERLY是Spring Cloud Alibaba RocketMQ对原生API的封装，属于Spring生态的编程模型。它通过@RocketMQMessageListener注解的consumeMode属性（设置为ConsumeMode.ORDERLY）声明顺序消费，底层会自动适配RocketMQ的顺序消费逻辑，简化了开发者对原生API的直接操作。 MessageListenerOrderly接口是RocketMQ客户端原生API（org.apache.rocketmq.client.consumer.listener包下）的接口，属于更底层的编程模型。开发者需要直接对接Roc...

为了防止消息重复消费导致业务处理异常，云消息队列 RocketMQ 版的消费者在接收到消息后，有必要根据业务上的唯一Key对消息做幂等处理。本文介绍消息幂等的概念、适用场景以及处理方法。 什么是消息幂等当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费者的处理过程就是幂等的。 例如，在支付场景下，消费者消费扣款消息，对一笔订单执行扣款操作，扣款金额为100元。如果因网络不稳定等原因导致扣款消息重复投递，消费者重复消费了该扣款消息，但最终的业务结果是只扣款一次，扣费100元，且用户的扣款记录中对应的订单只有一条扣款流水，不会多次扣除费用。那么这次扣款操作是符合要求的，整个消费过程实现了消息幂等。 适用场景在互联网应用中，尤其在网络不稳定的情况下， RocketMQ 版的消息有可能会出现重复。如果消息重复会影响您的业务处理，请对消息做幂等处理。 消息重复的场景如下： 发送时消息重复 当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此...

前言​ 本篇将介绍Spring Cloud Alibaba使用OpenFeign和RestTemplate进行RPC调用，并且将介绍两种RPC工具如何集成Sentinel进行系统保护。 OpenFeignOpenFeign介绍​ OpenFeign是一种声明式、模板化的HTTP客户端。 在Spring Cloud中使用OpenFeign，可以做到使用HTTP请求访问远程服务，就像调用本地方法一样的，开发者完全感知不到这是在调用远程方法，更感知不到在访问HTTP请求。 OpenFeign使用​ 编写两个服务，一个provider服务account-svc一个consumer服务order-svc。 Provider代码 pom依赖 123456789101112131415161718192021222324252627<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" x...