Albert World

GoAdmin框架实现的后台应用遇到的鉴权跳转问题

2024-12-28T16:58:05.000Z

前言

GoAdmin是一个基于 golang 面向生产的数据可视化管理平台搭建框架，可以让你使用简短的代码在极短时间内搭建起一个管理后台，虽然我也会去修改和新增一些功能页面，但是它给我的感觉总像一个黑盒子，大概是我对Web开发的知识了解甚少，总是照葫芦画瓢的完成一些工作，最近在鉴权和会话过期的处理上遇到了一点点问题，直接GET访问页面在会话过期时会自动跳转到登录页面，而点击按钮提交表单时如果已经会话过期了却没有任何反应，我觉得是少设置了一些东西，绕了一大圈才算勉强解决，但这应该不是最优的方案，先记录一下，后续找到好的解决方案再优化。

问题的发现与解决

使用GoAdmin搭建的后台网站，如果长时间停留在一个页面，点击菜单中的其他页面时会自动跳转到登录页面，但是点击页面表单上的提交按钮却没有反应，这种情况会让人迷惑，不知道刚刚这个操作到底有没有执行成功，要解决这个问题就先查代码吧？实际上时候发现，这时点击提交按钮时报了一个js错误，只有在浏览器的控制台才能看到，起初没发现也是走了一些弯路。

一开始我认为两种情况一个表现正常、一个表现不正常是因为GET和POST的缘故，所以我对比了两种请求处理从注册路由开始的逻辑代码，尽最大可能保持一样，但没有解决。

注册路由的方式，GoAdmin开源项目中有相关代码

authRoute.POST("/menu/edit", admin.guardian.MenuEdit, admin.handler.EditMenu).Name("menu_edit")
authRoute.POST("/menu/order", admin.handler.MenuOrder).Name("menu_order")
authRoute.GET("/menu", admin.handler.ShowMenu).Name("menu")
authRoute.GET("/menu/edit/show", admin.handler.ShowEditMenu).Name("menu_edit_show")

我简单的理解就是，告诉框架当访问到前面这个路径的时候，依次调用后面的处理函数就行了，当然这也是我这两天跟踪代码时领取的，最后的 Name 函数是为这个路由命令，而我的应用不管是GET路由还是POST路由都使用了 auth.Middleware(admin.Conn) 这个鉴权函数，按道理说肯定都进行了鉴权处理，不应该有差异的，最开始有一些包装函数逻辑顺序的差异，我调整成一样的依旧不生效。

我使用断点，单步调试查看GET和POST的区别，但是没有发现差异，两者都返回了302状态码表示重定向，但是GET成功跳转了，而POST没有变化

// Middleware is the default auth middleware of plugins.
func Middleware(conn db.Connection) context.Handler {
    return DefaultInvoker(conn).Middleware()
}

// DefaultInvoker return a default Invoker.
func DefaultInvoker(conn db.Connection) *Invoker {
    return &Invoker{
        prefix: config.Prefix(),
        authFailCallback: func(ctx *context.Context) {
            if ctx.Request.URL.Path == config.Url(config.GetLoginUrl()) {
                return
            }
            if ctx.Request.URL.Path == config.Url("/logout") {
                ctx.Write(302, map[string]string{
                    "Location": config.Url(config.GetLoginUrl()),
                }, ``)
                return
            }
            param := ""
            if ref := ctx.Referer(); ref != "" {
                param = "?ref=" + url.QueryEscape(ref)
            }

            u := config.Url(config.GetLoginUrl() + param)
            _, err := ctx.Request.Cookie(DefaultCookieKey)
            referer := ctx.Referer()

            if (ctx.Headers(constant.PjaxHeader) == "" && ctx.Method() != "GET") ||
                err != nil ||
                referer == "" {
                ctx.Write(302, map[string]string{
                    "Location": u,
                }, ``)
            } else {
                msg := language.Get("login overdue, please login again")
                ctx.HTML(http.StatusOK, ``)
            }
        },
        permissionDenyCallback: func(rawCtx *context.Context) {
            if rawCtx.Headers(constant.PjaxHeader) == "" && rawCtx.Method() != "GET" {
                rawCtx.JSON(http.StatusForbidden, map[string]interface{}{
                    "code": http.StatusForbidden,
                    "msg":  language.Get(errors.PermissionDenied),
                })
            } else {
                page.SetPageContent(rawCtx, Auth(rawCtx), func(ctx interface{}) (types.Panel, error) {
                    return template2.WarningPanel(rawCtx, errors.PermissionDenied, template2.NoPermission403Page), nil
                }, conn)
            }
        },
        conn: conn,
    }
}

两种方式函数最终都走到了下面这个分支，结果却不相同

if (ctx.Headers(constant.PjaxHeader) == "" && ctx.Method() != "GET") ||
    err != nil ||
    referer == "" {
    ctx.Write(302, map[string]string{
        "Location": u,
    }, ``)
}

没办法，这时我只能打开浏览器按下F12开始调试，渐渐发现了一些端倪，无论是点击菜单还是点击提交按钮，都收到了302也进行了跳转，但是点提交按钮这种情况收到302后虽然跳转成功了，但是页面没有切换，赶紧问了一下ChatGPT，他告诉我很可能是Ajax的锅。

Ajax究竟是个啥，虽然之前听过，但是我却说不上来，继续搜索吧。

AJAX（Asynchronous JavaScript and XML）是一种用于创建快速动态网页的技术。通过使用 AJAX，网页能够与服务器进行异步交互，而无需重新加载整个页面。AJAX 允许在后台与服务器进行通信，并使用 JavaScript 更新网页的部分内容。

使用 AJAX 的优势很多，比如：

提高用户体验：AJAX 允许在后台加载数据，从而使网页更流畅，用户不需要等待整个页面重新加载。
减少服务器负载：只请求所需的数据，而不是重新加载整个页面，降低了数据传输量。
更快的响应时间：通过部分更新页面内容，用户能够更快地看到更新结果。

常见的 AJAX 应用场景如下：

表单提交：在用户提交表单时，AJAX 可以异步提交数据，避免页面刷新。
动态内容加载：在用户滚动或点击时加载更多内容，例如无限滚动。
实时数据更新：如聊天应用、股票价格更新等实时信息。

这里的表单提交我确实使用了AJAX，这就导致它没有正确处理302状态码，我当时是这么想的，也是朝着这个方向努力的

找到页面上中设置Ajax回调函数的逻辑

panel.EnableAjaxData(types.AjaxData{
    SuccessTitle: "success",
    DisableJump:  true,
})

aform := components.Form().
    SetId("cmd-form").
    SetUrl("/admin/cmd").
    SetAjax(panel.AjaxSuccessJS, panel.AjaxErrorJS)

我开始拿 panel.AjaxErrorJS 开刀，我分析了前面的代码，以为这个字段是空的，准备替换成如下代码：

function(data) {
    if (data.status === 302) {
            // 处理重定向
            const redirectUrl = data.headers.get('Location');
            if (redirectUrl) {
                window.location.href = redirectUrl;
            }
        } else {
            consle.log(data.responseText);
    }
}

很遗憾不太好用，有时好使有时不好使，并且页面一直在上方显示着加载中的进度条，没办法继续问ChatGPT吧，有一项相关提醒：

错误处理逻辑：确保在 error 函数中正确处理请求失败的情况。如果没有适当地处理错误，进度条可能会一直显示。

所以我又看了一下控制台，发现错误提醒，告诉我没有函数名：

1	Uncaught SyntaxError: Function statements require a function name

所以我改成了下面这样

function alala(data) {
    if (data.status === 302) {
...
    }
}

但这次一点也不好使了，我查看页面源码一看，原来变成了下面这样，能好使才怪了

function (data) {
    function alala(data) {
        if (data.status === 302) {
    ...
        }
    }
}

进一步分析我发现 panel.AjaxSuccessJS 和 panel.AjaxErrorJS 都不是空的，不能简单覆盖，需要做一步调整，这两个变量的初始化代码在 EnableAjaxData 函数

func (f *FormPanel) EnableAjaxData(data AjaxData) *FormPanel {
    f.Ajax = true
    if f.AjaxSuccessJS == template.JS("") {
        successMsg := modules.AorB(data.SuccessTitle != "", `"`+data.SuccessTitle+`"`, "data.msg")
        errorMsg := modules.AorB(data.ErrorTitle != "", `"`+data.ErrorTitle+`"`, "data.msg")
        jump := modules.AorB(data.SuccessJumpURL != "", `"`+data.SuccessJumpURL+`"`, "data.data.url")
        text := modules.AorB(data.SuccessText != "", `text:"`+data.SuccessText+`",`, "")
        wrongText := modules.AorB(data.ErrorText != "", `text:"`+data.ErrorText+`",`, "text:data.msg,")
        jumpURL := ""
        if !data.DisableJump {
            if data.JumpInNewTab != "" {
                jumpURL = `listenerForAddNavTab(` + jump + `, "` + data.JumpInNewTab + `");`
            }
            jumpURL += `$.pjax({url: ` + jump + `, container: '#pjax-container'});`
        } else {
            jumpURL = `
        if (data.data && data.data.token !== "") {
            $("input[name='__go_admin_t_']").val(data.data.token)
        }`
        }
        f.AjaxSuccessJS = template.JS(`
    if (typeof (data) === "string") {
        data = JSON.parse(data);
    }
    if (data.code === 200) {
        swal({
            type: "success",
            title: ` + successMsg + `,
            ` + text + `
            showCancelButton: false,
            confirmButtonColor: "#3c8dbc",
            confirmButtonText: '` + language.Get("got it") + `',
        }, function() {
            $(".modal-backdrop.fade.in").remove();
            ` + jumpURL + `
            ` + data.SuccessJS + `
        });
    } else {
        if (data.data && data.data.token !== "") {
            $("input[name='__go_admin_t_']").val(data.data.token);
        }
        swal({
            type: "error",
            title: ` + errorMsg + `,
            ` + wrongText + `
            showCancelButton: false,
            confirmButtonColor: "#3c8dbc",
            confirmButtonText: '` + language.Get("got it") + `',
        })
    }
`)
    }
    if f.AjaxErrorJS == template.JS("") {
        errorMsg := modules.AorB(data.ErrorTitle != "", `"`+data.ErrorTitle+`"`, "data.responseJSON.msg")
        error2Msg := modules.AorB(data.ErrorTitle != "", `"`+data.ErrorTitle+`"`, "'"+language.Get("error")+"'")
        wrongText := modules.AorB(data.ErrorText != "", `text:"`+data.ErrorText+`",`, "text:data.msg,")
        f.AjaxErrorJS = template.JS(`
    if (data.responseText !== "") {
        if (data.responseJSON.data && data.responseJSON.data.token !== "") {
            $("input[name='__go_admin_t_']").val(data.responseJSON.data.token)
        }
        swal({
            type: "error",
            title: ` + errorMsg + `,
            ` + wrongText + `
            showCancelButton: false,
            confirmButtonColor: "#3c8dbc",
            confirmButtonText: '` + language.Get("got it") + `',
        })
    } else {
        swal({
            type: "error",
            title: ` + error2Msg + `,
            ` + wrongText + `
            showCancelButton: false,
            confirmButtonColor: "#3c8dbc",
            confirmButtonText: '` + language.Get("got it") + `',
        })
    }
`)
    }
    return f
}

仿照着它的逻辑，在设置Ajax回调函数时我直接写function之中的内容，反正最后function和大括号它会自动生成，改完AjaxErrorJS后满心欢喜的测试，心想马上就解决了，但是发现居然没有什么效果，打开控制台一开又报错了

VM4407:2 Uncaught SyntaxError: Unexpected token '<', "
    
    at JSON.parse ()
    at Object.success (eval at globalEval (all.min.8425540791.js:1:2618), :14:13)
    at j (all.min.8425540791.js:1:27005)
    at Object.fireWith [as resolveWith] (all.min.8425540791.js:1:27818)
    at x (all.min.8425540791.js:1:75367)
    at XMLHttpRequest. (all.min.8425540791.js:1:78879)

什么意思呢？分析过后其实是调用Ajax回调函数 AjaxSuccessJS 时，执行 data = JSON.parse(data); 这一句报了错，这里有点奇怪，起初以为302会调用到error的回调函数，现在一看跑到success函数中去了

大概分析原因如下：

302 是一个重定向状态码，表示所请求的资源临时位于不同的 URI。通常，响应中会包含一个 Location 头，指示新位置。当 AJAX 请求收到 302 状态码时，浏览器会处理重定向，通常会自动跟随新的 URL。

如果重定向的目标是一个 HTML 页面（如登录页面），浏览器会将该页面的内容返回给 AJAX 请求的 success 回调，而不是将其处理为错误。换句话说，AJAX 请求会成功接收到重定向目标的 HTML 内容，因为 HTTP 状态码 302 仍被视为“成功”请求的一部分（尽管它表示需要重定向）。

知道了这些就明白怎么去解决问题了，既然返回的是登录界面的HTML不是json数据，那么我就先判断，如果是登录界面的时候跳转就可以了，为了提升体验，可以加一个弹窗提示和延迟跳转

if (data.includes("!DOCTYPE html") && data.includes("登录")) {
    swal({
        title: "会话已过期",
        text: "请重新登录，即将跳转到登录页面……",
        icon: "warning",
        button: false,
        timer: 2000
    });
    setTimeout(function() {
        window.location.href = "/login";
    }, 2000);
} else {
    data = JSON.parse(data);
}

关于这个问题我又问了一下ChatGPT，得到的答案是这样的：

为什么浏览器已经收到了跳转而来的登录界面的内容，却没有跳转，而是继续保持在过期的页面呢

当浏览器发出 AJAX 请求并收到 302 重定向时，通常的行为是浏览器会自动向新的 URL 发起请求。但是，如果在 AJAX 请求的上下文中出现以下情况，可能导致浏览器没有自动跳转，而是显示重定向目标页面的内容，可能的原因如下：

AJAX 请求的响应处理：
- 当 AJAX 请求收到 302 响应时，浏览器会自动请求新的 URL，但这个行为通常不影响当前页面的 URL。相反，它只是在 AJAX 请求的上下文中更新了响应内容。
- 如果服务器返回的 302 重定向是指向一个 HTML 页面（如登录页面），并且这个 HTML 内容被返回到 AJAX 的 success 回调中，那么浏览器会将这个内容显示在当前页面，而不会自动进行 URL 更改。
AJAX 的特性：
- AJAX 的目的就是异步加载数据，而不影响页面的整体加载。因此，即使 AJAX 请求收到重定向，浏览器的行为是将新的内容注入到当前页面中，而不是直接改变当前页面的 URL。
浏览器行为：
- 在某些情况下（尤其是在使用 JavaScript 进行页面更新时），浏览器可能不会进行页面跳转，因为页面的 JavaScript 处理了新的 HTML 内容。开发者可以在 AJAX 请求的 success 回调中自定义如何处理这种情况。

总结

GoAdmin是一个用 golang 编写的前后端一体的面向生产的数据可视化管理平台搭建框架
AJAX是一种用于创建快速动态网页的技术，能够实现与服务器进行异步交互，更新网页的部分内容
swal 是 SweetAlert 库的一个函数，用于创建漂亮的弹出框（模态窗口）以显示消息、警告、提示等
SweetAlert有1和2两个版本，SweetAlert 2 的返回值支持 Promise，可以使用 then() 方法
当使用Ajax发送请求时入股遇到重定向返回给ajax回调函数success的数据是新页面的HTML内容

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

我饮人间二两酒，一饮无奈一饮空！我欠人间二两墨，一笔相思，一笔错！也许人生就是这样，不品人间酒，不知其中醉，不陷世间情，怎知其中泪。永远不用幻想着另一条路是美好的，那只是我们内心美化后的结果，经历过的才是真实~
2024-12-26 22:07:26

Windows下使用adb实现在模拟器中ping

2024-12-28T16:42:07.000Z

前言

有时在模拟器中测试应用不像在Windows这种开发环境中那么方便，毕竟Windows或者Linux下的工具五花八门，可以满足各种测试需求，比如应用在模拟器中无法登录时，想测试模拟器的网络情况，如果是在Windows或者Linux下各种网络工具任君挑选，但是在模拟器中运行个命令行下的ping命令的都费劲，但方法还是有的，我就找个不那么费劲的方法吧，记录在此方便查阅。

安装adb

adb（Android Debug Bridge）是一个命令行工具，用于与 Android 设备或模拟器进行交互。它是 Android SDK 的一部分，广泛用于开发、调试和管理 Android 应用程序和设备，如果我们仅是简单使用，不必安装完整的 Android SDK，直接下载Google提供的adb工具包，下载后解压即可使用。

Windows版本：https://dl.google.com/android/repository/platform-tools-latest-windows.zip
Linux版本：https://dl.google.com/android/repository/platform-tools-latest-linux.zip
Mac版本：https://dl.google.com/android/repository/platform-tools-latest-darwin.zip

Windows中下载解压后需要将加压后的文件夹添加到Path环境变量，按键windows+i打开设置界面搜索“环境变量”回车。

在选项 环境变量 -> 系统变量 -> Path 输入解压后端的文件夹，比如 D:\platform-tools\ 确定后保存

打开CMD命令行工具输入验证，显示如下类似信息证明工具已经就位

C:\Users\Administrator>adb --version
Android Debug Bridge version 1.0.41
Version 35.0.2-12147458
Installed as D:\ProgramNoBlank\platform-tools\adb.exe
Running on Windows 10.0.18363

执行adb命令

有了adb就可以和连接了电脑的Android设备通信，Android模拟器也可以看成是安装设备，首先要找到模拟器设备id

查找模拟器设备

C:\Users\Administrator>adb devices
List of devices attached
C:\Users\Administrator>adb devices
List of devices attached
emulator-5554   device

链接模拟器命令行

1 2	C:\Users\Administrator>adb -s emulator-5554 shell OP564B:/ $

执行ping命令

OP564B:/ $ ping 008ct.top
PING 008ct.top (198.18.0.152) 56(84) bytes of data.
64 bytes from 198.18.0.152: icmp_seq=1 ttl=64 time=0.636 ms
64 bytes from 198.18.0.152: icmp_seq=2 ttl=64 time=1.13 ms
64 bytes from 198.18.0.152: icmp_seq=3 ttl=64 time=1.39 ms
64 bytes from 198.18.0.152: icmp_seq=4 ttl=64 time=1.57 ms
64 bytes from 198.18.0.152: icmp_seq=5 ttl=64 time=1.51 ms
^C
--- 008ct.top ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4009ms
rtt min/avg/max/mdev = 0.636/1.251/1.579/0.344 ms

总结

adb 是一个命令行工具，属于 Android SDK 的一部分，用于与 Android 设备或模拟器进行交互
借助 adb 工具可以实现在宿主机上调试和处理Android设备或模拟器上的应用
查询机器连接的Android设备列表命令 adb devices
连接Android模拟器中的命令行工具的命令 adb -s emulator-5554 shell

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

曾国藩、左宗棠、洪秀全分别相差1岁，命运却迥然不同，左宗棠第一次见曾国藩的评价居然是“才具稍欠开展”，命运戏人啊
2024-11-12 17:52:57

简单整理下protobuf中常用的几个工具函数

2024-12-25T15:30:00.000Z

前言

游戏项目中使用protobuf作为双端协议通讯的方式，算是一种中规中矩的方法了，偶尔会需要查看序列化后的消息占用空间大小，一直都是用序列化后的字符串来查看，即使临时测试一个结构占用空间也要序列化后才能调用 .size() 函数，最近偶然间发现有个 ByteSizeLong() 可直接用于BP结构上，这倒是简单了一点点，所以把常用的几个函数列举总结一下，免的自己时间太长忘记了。

使用示例

定义message结构

在调用函数之前先定义一个结构文件吧

syntax = "proto3";
package ProtoMsg;
option go_package = "./;ProtoMsg";

message Address {                  // 地址结构
    string city = 1;
    string street = 2;
}

message Person {
    int32 age = 1;                 // 年龄
    string name = 2;               // 姓名
    bool student = 3;              // 学生
    Address address = 4;           // 地址
    map tags = 5;  // 标签信息
    repeated int64 lucky_nums = 6; // 幸运数字
}

结构体赋值

接着我们使用C++语言给这个结构赋值，然后尝试在此基础上调用不同的函数

ProtoMsg::Person person;
person.set_age(18);
person.set_name("albert");
person.set_student(true);
person.mutable_address()->set_city("beijing");
person.mutable_address()->set_street("soho");
(*person.mutable_tags())["hobby"] = "reading";
(*person.mutable_tags())["family"] = "warm";
person.add_lucky_nums(1);
person.add_lucky_nums(9);

ByteSizeLong()

这是一个获取protobuf结构大小的函数，起初我找到的是 ByteSize()，但是这个函数返回值是int，现在已经不建议使用了，所以之后请直接使用 ByteSizeLong() 来获取结构大小，就像下面这样：

std::cout << "show person size [" << person.ByteSizeLong() << "] and address size [" << person.address().ByteSizeLong() << "].";

// 输出结果
// show person size [67] and address size [15].

GetTypeName()

这个函数可以获取结构的名字，有一点点元数据的意思，在输出日志时可以使内容更清晰：

std::cout << "show person type name [" << person.GetTypeName() << "] and address type name [" << person.address().GetTypeName() << "].";

// 输出结果
// show person type name [ProtoMsg.Person] and address type name [ProtoMsg.Address].

DebugString()

这个函数看名字就知道和调试信息有关，它可以打印整个结构的数据：

std::cout << "show person debug string [" << person.DebugString() << "]."

// 输出结果
// show person debug string [age: 18
// name: "albert"
// student: true
// address {
//   city: "beijing"
//   street: "soho"
// }
// lucky_nums: 1
// lucky_nums: 9
// tags {
//   key: "family"
//   value: "warm"
// }
// tags {
//   key: "hobby"
//   value: "reading"
// }
// ].

ShortDebugString()

我们发现 DebugString() 输出的内容换行较多，虽然看起来更清晰，但是不便于存入日志按行查找，要想存储日志文件中，ShortDebugString() 函数是更好的选择:

std::cout << "show person short debug string [" << person.ShortDebugString() << "].";

// 输出结果
// show person short debug string [age: 18 name: "albert" student: true address { city: "beijing" street: "soho" } lucky_nums: 1 lucky_nums: 9 tags { key: "family" value: "warm" } tags { key: "hobby" value: "reading" }].

CopyFrom(const MessageLite& other)

这个结构用于结构的拷贝，比如你已经有了一个地址结构对象，再创建新的 Person 时就不必对address字段一一赋值，而是可以直接使用CopyFrom函数完成：

    ProtoMsg::Address addr;
    addr.set_city("shanghai");
    addr.set_street("nanjinglu");
    person.mutable_address()->CopyFrom(addr);

    std::count << "show person short debug string [" << person.ShortDebugString() << "].";

// 输出结果
// show person short debug string [age: 18 name: "albert" student: true address { city: "shanghai" street: "nanjinglu" } lucky_nums: 1 lucky_nums: 9 tags { key: "family" value: "warm" } tags { key: "hobby" value: "reading" }].

Clear()

清空当前消息的所有字段，重置为默认状态，这个我倒是不太常用，但是测试时偶尔会用到：

    person.Clear();

    std::cout << "show person size [" << person.ByteSizeLong() << "] and short debug string [" << person.ShortDebugString() << "].";

// 输出结果
// show person size [0] and short debug string [].

Ohters

其他还有一些函数属于使用protobuf的常见函数，我就不再举例了，简单列举下函数作用：

MergeFrom(const MessageLite& other) 合并另一个消息的内容到当前消息中（可能会覆盖现有字段）
SerializeToString(std::string* output) 将消息序列化为字符串格式，并将结果存储在提供的 std::string 对象中
ParseFromString(const std::string& data) 从给定的字符串解析出消息数据
std::string SerializeAsString() const 将消息序列化为字符串格式并返回
bool SerializeToArray(void* data, int size) const 直接将消息序列化到用户提供的缓冲区中
google::protobuf::MessageLite::ParseFromArray(const void *data, int size) 将给定的二进制数据解析为 Protocol Buffers 消息对象

总结

ByteSizeLong() 可以用来获取一个protobuf结构的大小
GetTypeName() 可以用来返回一个结构的名字
ShortDebugString() 可以用返回一个结构的数据内容
protobuf 这种经典的开源库挖一挖总会有惊喜

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

慢就是快，每个人都有不同的解读，曾经有那么两次我好像都能顿悟了，可思绪闪现了那么一刻就消失了；稳稳地慢是幸运的，最近总是听人讲到控制回撤这个词，尽管他喊得声嘶力竭，起初我却不以为意，但经历的多了以后开始理解他所说的价值，才理解慢慢变富的含义，既然是概率游戏，只要能保证胜率在51%，那么最后一定会赢的，我们要做的只是按照自己的节奏不断地重复，不断地重复就好~
2024-12-25 13:38:19

使用mysqlx操作MySQL8.0数据库时遭遇CDK Error: Connection refused (generic:111)错误

2024-12-20T16:00:00.000Z

前言

游戏服务器一个配置存储服务，使用 mysql-connector-c++ 8.0 连接 MySQL 8.0 数据库，使用 MySQL X Protocol，它是 MySQL 8.0 引入的一种新的通信协议，它是为了支持现代应用程序开发需求而设计的。除了关系型数据存储外，MySQL X Protocol 可以方便地处理文档存储，允许存储和检索 JSON 等文档类型的数据，使其更适合现代的 NoSQL 风格的开发模式。该协议支持异步操作，提高了性能，允许更高效的并发处理，特别是在处理大量请求时。支持更丰富的数据操作，包括 CRUD 操作、事务处理、SQL 语句执行，并且可以处理复杂的查询，例如对文档存储的查询。

mysqlx 是 MySQL 提供的用于与 MySQL 服务器进行交互的 C++ 客户端库，基于 MySQL X Protocol 开发。它提供了一组 C++ API，使开发人员可以在 C++ 程序中使用 MySQL 服务器的功能。而我就是用这套API是遇到了问题，本来这套功能在本地测试时很顺畅，没有发现问题，但是放到线上环境时就发现无法存储数据，调试线上环境还是有一些难度的。

因为线上程序编译为release版本，几乎没有可以调试的符号，起初还怀疑是release版本有问题，但是本地编译成release版本依旧正常，所以我就迅速用一个debug版本的so库替换了线上的release版本库，结果废了半天劲就找到了 CDK Error: Connection refused (generic:111) 这个错误，对于这个问题的处理还查了很多解决办法，但回过头来看，这个提示已经很明显了，就是不让连接呗，应该第一时间想到连接权限问题的，但是这有点马后炮，关于这个问题还是走了不少弯路，不过也学到了很多，总结一下做个备忘录。

问题现场

查找object时的示例代码:

mysqlx::Session sess = sqlClient->getSession();
mysqlx::DocResult result = sess
    .getDefaultSchema()
    .getCollection(collectionName)
    .find(searchPattern)
    .execute();

mysqlx::DbDoc doc;
while (doc = result.fetchOne())
{
    // ...
}

添加新object时的实例代码：

mysqlx::Session sess = sqlClient->getSession();
mysqlx::Result result = sess
    .getDefaultSchema()
    .createCollection(collectionName, true)
    .add(jsonString)
    .execute();

return result.getAffectedItemsCount() > 0;

报错的函数主要集中在上面两段逻辑，实际上通过debug库断点，已经能定位到 mysqlx::Session sess = sqlClient->getSession(); 这一句就开始报异常了，异常类型 catch (const mysqlx::Error& err) { ... }，打印信息也就是标题中看到的 CDK Error: Connection refused (generic:111)。

这里的Collection相当于关系数据库中的一个表，实际上可以通过关系数据库导出的方式，将Collection导出或者导出，仅导出表结构的命令

1	mysqldump -u username -p --no-data source_database table_name > table_structure.sql

导出的 table_structure.sql 内容示例

-- MySQL dump 10.13  Distrib 8.0.24, for Linux (x86_64)
--
-- Host: localhost    Database: source_database
-- ------------------------------------------------------
-- Server version       8.0.24

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!50503 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `GlobalConfig`
--

DROP TABLE IF EXISTS `GlobalConfig`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `GlobalConfig` (
  `doc` json DEFAULT NULL,
  `_id` varbinary(32) GENERATED ALWAYS AS (json_unquote(json_extract(`doc`,_utf8mb4'$._id'))) STORED NOT NULL,
  `_json_schema` json GENERATED ALWAYS AS (_utf8mb4'{"type":"object"}') VIRTUAL,
  PRIMARY KEY (`_id`),
  CONSTRAINT `$val_strict_64BAB193F9193856B3219B21CF70823072B92EB1` CHECK (json_schema_valid(`_json_schema`,`doc`)) /*!80016 NOT ENFORCED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
/*!40101 SET character_set_client = @saved_cs_client */;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2024-12-19 23:03:52

简单的导入命令

1	mysql -u username -p target_database < table_name.sql

解决问题

有经验之后可以从提示 CDK Error: Connection refused (generic:111) 推断出是连接权限问题，但要准确找到问题点还需要逐步排查

MySQL绑定的IP地址是多少？允许哪些主机访问
MySQL监听的端口是多少？允许通过哪些端口访问
MySQL中定义了哪些用户？哪些用户可以访问
MySQL中定义的用户绑定了哪些主机？已存在的用户可以通过哪些主机访问
MySQL中绑定了主机的用户有哪些权限？可以访问的用户是否有指定的操作权限，比如增加、删除等

这么一看还真是挺麻烦的，不过不用担心，当处理的次数多了自然而然就理解了，先看前两个问题，MySQL绑定的IP和端口吧

MySQL绑定IP和端口

他们配置在文件 /etc/mysql/mysql.conf.d/mysqld.cnf 中，这里面文件名很相似，我的环境是在Ubuntu20.04，版本目录结构如下：

# tree /etc/mysql
/etc/mysql
├── conf.d
│   ├── mysql.cnf
│   └── mysqldump.cnf
├── debian.cnf
├── debian-start
├── my.cnf -> /etc/alternatives/my.cnf
├── my.cnf.fallback
├── mysql.cnf
└── mysql.conf.d
    ├── mysql.cnf
    └── mysqld.cnf

部分文件内容

[mysqld]
#
# * Basic Settings
#
user            = mysql
# pid-file      = /var/run/mysqld/mysqld.pid
# socket        = /var/run/mysqld/mysqld.sock
port            = 3306
# datadir       = /var/lib/mysql


# If MySQL is running as a replication slave, this should be
# changed. Ref https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmpdir
# tmpdir                = /tmp
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1
mysqlx-bind-address     = 127.0.0.1

无论是传统的mysql协议还是新的mysqlx协议，都默认允许本机回环地址 127.0.0.1 连接，mysql协议默认端口3306，mysqlx默认端口33060，如果想修改在文件 mysqld.cnf 修改后重启MySQL服务 sudo systemctl restart mysql 既可以了，可以查询MySQL变量看看目前生效的配置值。

mysql> SHOW VARIABLES LIKE '%bind%';
+---------------------+-----------+
| Variable_name       | Value     |
+---------------------+-----------+
| bind_address        | 127.0.0.1 |
| mysqlx_bind_address | 127.0.0.1 |
+---------------------+-----------+
2 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE '%port%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| mysqlx_port              | 33060 |
| port                     | 3306  |
+--------------------------+-------+

对于 MySQL 服务绑定地址 0.0.0.0、192.168.1.100、127.0.0.1 和 localhost 有一些差异，其中192.168.1.100为本机内网地址，对比结果整理如下：

对比维度	0.0.0.0	192.168.1.100	127.0.0.1	localhost
含义	监听所有网络接口（本机、内网、外网）。	监听特定的本机网络接口，仅允许特定 IP 连接。	仅监听本机回环接口，仅限本机访问。	通常解析为 Unix Socket 或 `127.0.0.1`。
访问范围	所有来源（包括本地和远程）。	仅允许通过指定的网络接口访问（如内网 IP）。	仅限本机访问，无法从外部访问。	仅限本机访问，无法从外部访问。
使用协议	强制使用 TCP/IP 协议。	强制使用 TCP/IP 协议。	强制使用 TCP/IP 协议。	优先使用 Unix Socket，无法使用时退回到 TCP/IP 协议。
性能	可能因监听所有接口稍有性能影响。	仅监听单个接口，性能略高于 `0.0.0.0`。	受限于网络栈处理效率。	使用 Unix Socket 时性能最高；TCP/IP 时与 `127.0.0.1` 相同。
安全性	最不安全，需防火墙限制来源以防外网暴露。	较为安全，仅允许指定接口连接，适合内网使用。	高安全性，仅限本机访问，不暴露给外部网络。	高安全性，仅限本机访问，Unix Socket 更加安全。
适用场景	内网/外网连接，需严格配置防火墙规则。	局域网访问，仅需特定网络接口的连接。	单机应用或本地调试环境，仅限本机访问。	本地高频操作，优先使用更高效的 Unix Socket。
配置方法	`bind-address = 0.0.0.0`	`bind-address = 192.168.1.100`	`bind-address = 127.0.0.1`	`bind-address = 127.0.0.1`（间接实现）。
访问示例	所有主机（如 `mysql -h <任意IP>`）。	指定内网 IP（如 `mysql -h 192.168.1.100`）。	本机访问（如 `mysql -h 127.0.0.1`）。	本机访问（如 `mysql -h localhost`）。

MySQL用户和绑定的主机

在MySQL中不仅定义了用户和对应权限，还规定了用户绑定的主机，也就是说权限不仅仅分配给一个用户的，而是分配给通过指定机器访问的用户的，单单这么说对于没有操作的人来说可能有些懵，我们可以实际操作一下：

通过 SELECT DISTINCT CONCAT('User: ''',user,'''@''',host,''';') AS query FROM mysql.user; 可以查询用户

mysql> SELECT DISTINCT CONCAT('User: ''',user,'''@''',host,''';') AS query FROM mysql.user;
+---------------------------------------+
| query                                 |
+---------------------------------------+
| User: 'webview'@'%';                  |
| User: 'comm'@'192.168.1.100';         |
| User: 'comm'@'localhost';             |
| User: 'debian-sys-maint'@'localhost'; |
| User: 'admin'@'localhost';            |
| User: 'mysql.infoschema'@'localhost'; |
| User: 'mysql.session'@'localhost';    |
| User: 'mysql.sys'@'localhost';        |
| User: 'root'@'localhost';             |
| User: 'zone0001'@'localhost';         |
+---------------------------------------+
11 rows in set (0.00 sec)

用户名加上后面的主机名才是权限授予的主体，可以看到comm这个用户名可以通过localhost本机访问，也可以通过 192.168.1.100 这台机器访问，如果还需要通过 192.168.1.200，那么还需要创建一个 'comm'@'192.168.1.200' 的用户并授予权限才可以。

如果想要一个用户可以在任何主机上登录访问MySQL，主机部分用 % 代替，就比如 'webview'@'%' 这个用户，不过不建议这样做，安全性明显降低。

MySQL授予和回收权限

查询权限可以通过 show grants for 用户 查询，测试如下：

mysql> show grants for 'comm'@'localhost';
+----------------------------------------------------------+
| Grants for comm@localhost                                |
+----------------------------------------------------------+
| GRANT USAGE ON *.* TO `comm`@`localhost`                 |
| GRANT ALL PRIVILEGES ON `mycomm`.* TO `comm`@`localhost` |
+----------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> show grants for 'root'@'localhost';
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO `root`@`localhost` WITH GRANT OPTION                                                                                                                                                                                                                                                                                                                                                                                     |
| GRANT APPLICATION_PASSWORD_ADMIN,AUDIT_ABORT_EXEMPT,AUDIT_ADMIN,AUTHENTICATION_POLICY_ADMIN,BACKUP_ADMIN,BINLOG_ADMIN,BINLOG_ENCRYPTION_ADMIN,CLONE_ADMIN,CONNECTION_ADMIN,ENCRYPTION_KEY_ADMIN,FIREWALL_EXEMPT,FLUSH_OPTIMIZER_COSTS,FLUSH_STATUS,FLUSH_TABLES,FLUSH_USER_RESOURCES,GROUP_REPLICATION_ADMIN,GROUP_REPLICATION_STREAM,INNODB_REDO_LOG_ARCHIVE,INNODB_REDO_LOG_ENABLE,PASSWORDLESS_USER_ADMIN,PERSIST_RO_VARIABLES_ADMIN,REPLICATION_APPLIER,REPLICATION_SLAVE_ADMIN,RESOURCE_GROUP_ADMIN,RESOURCE_GROUP_USER,ROLE_ADMIN,SENSITIVE_VARIABLES_OBSERVER,SERVICE_CONNECTION_ADMIN,SESSION_VARIABLES_ADMIN,SET_USER_ID,SHOW_ROUTINE,SYSTEM_USER,SYSTEM_VARIABLES_ADMIN,TABLE_ENCRYPTION_ADMIN,TELEMETRY_LOG_ADMIN,XA_RECOVER_ADMIN ON *.* TO `root`@`localhost` WITH GRANT OPTION |
| GRANT PROXY ON ``@`` TO `root`@`localhost` WITH GRANT OPTION                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

创建用户和授予权限的方法

1
2
3

CREATE USER 'comm'@'192.168.1.200' IDENTIFIED BY 'mypassword';
GRANT ALL PRIVILEGES ON *.* TO 'comm'@'192.168.1.200';
FLUSH PRIVILEGES;

这样就创建了一个 'comm'@'192.168.1.200' 用户，并授予用户 comm 在 192.168.1.200 主机上对所有数据库和表的所有权限，如果允许用户将自己拥有的权限授予其他用户，可以加上 WITH GRANT OPTION 语句，完整命令如下：

1	GRANT ALL PRIVILEGES ON . TO 'comm'@'192.168.1.200' WITH GRANT OPTION;

回收权限的的命令如下：

1 2	REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'comm'@'192.168.1.200'; FLUSH PRIVILEGES;

总结

CDK Error: Connection refused (generic:111) 表示目标数据库拒绝连接，查询MySQL配置和权限分配是否正确
导出MySQL指定表结构 mysqldump -u username -p --no-data source_database table_name > table_structure.sql
查询MySQL用户 SELECT DISTINCT CONCAT('User: ''',user,'''@''',host,''';') AS query FROM mysql.user;
查询指定用户的权限 show grants for 'root'@'localhost';

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

程序是很单纯很单纯的，哪里能有什么坏心思，如果不能按照预期的情况表现，99.99%的情况下是使用方法不对，程序单纯到只会按照指令形式，如果表现不好，一定是指令不好~
2024-12-20 19:50:50

Redis查询占用空间最大的10个key

2024-12-17T15:45:00.000Z

前言

最近电脑性能告急，所有磁盘变红无空间，C盘更是剩下0字节，内存90%+，CPU占用90%+，使用spacesniffer查询哪些文件可以删除，优先被我干掉的是休眠功能自动生成的 hiberfil.sys 文件，然后这个内存分页文件 pagefile.sys 我没动，本来我的内存就不够用，删除了情况会更糟糕，然后映入眼帘是的 dump.rdb 文件，这个redis的持久化文件怎么这么大，足足有6个G，不仅占用了我6个G的C盘，还占用了我6个G的内存，不会是上次测试存储的大数据没删除吧，赶紧去瞅瞅。

查找Redis大key

查找的思路很简单粗暴，利用redis的API，将所有的key的大小查找出来，然后从大到小排序，找出最大的10个key。

需要注意的是，我这是本地的测试环境，为了方便所以使用了 keys 这个令人闻风丧胆的命令来阻塞获取了所有的key，如果是在生产环境中可千万不要这么写，使用 scan 是一个很好的替代方案，查询代码如下：

#!/usr/bin/python3.6
# -*- coding: utf-8 -*-
# 查询redis中占用空间最大的10个key

import redis

# game redis
redis_pool = redis.ConnectionPool(host='127.0.0.1', password='myword', port=6379)
redis_server = redis.Redis(connection_pool=redis_pool)

# 获取所有键
keys = redis_server.keys('*')

# 获取每个键的内存使用情况
key_sizes = []
for key in keys:
    size = redis_server.memory_usage(key)
    key_sizes.append((key, size))

# 按内存使用大小排序，取前10个
top_keys = sorted(key_sizes, key=lambda x: x[1], reverse=True)[:10]

# 输出结果
for key, size in top_keys:
    print(f"Key: {key}, Size: {size} bytes")
    #redis_server.delete(key)

果然不出所料，内存占用前几名的key都是之前我做测试时使用的超大key，赶紧使用 redis_server.delete(key) 函数删除掉，因为当时测试使用了统一的AAA前缀，为了提高后续查找效率，我把获取key的代码改成了 keys = redis_server.keys('AAA*')，这样查找前10个key速度就快很多了

使用Scan命令优化

前面提到 keys 命令不要在生产环境使用，如果要遍历key最好使用 scan 来代替，所以优化后的代码如下：

import redis

# 连接 Redis
redis_pool = redis.ConnectionPool(host='127.0.0.1', password='myword', port=6379)
redis_server = redis.Redis(connection_pool=redis_pool)

# 存储键和它们的内存使用情况
key_sizes = []

# 使用 SCAN 命令遍历所有键
cursor = 0
while True:
    cursor, keys = redis_server.scan(cursor, count=1000)  # 每次扫描最多返回 1000 个键
    for key in keys:
        size = redis_server.memory_usage(key)
        key_sizes.append((key, size))

    # 如果游标返回为 0，说明遍历完所有键
    if cursor == 0:
        break

# 按内存使用大小排序，取前10个
top_keys = sorted(key_sizes, key=lambda x: x[1], reverse=True)[:10]

# 输出结果
for key, size in top_keys:
    print(f"Key: {key}, Size: {size} bytes")
    # 如果需要删除键，可以在这里调用 redis_server.delete(key)

总结

Windows电脑磁盘不足时，如果不使用休眠功能，可以把C盘根目录的 hiberfil.sys 文件删掉
获取所有可以的命令是 keys，但这是个阻塞命令，不要轻易在生产环境下使用，必要时使用 scan 命令代替
使用 redis_server.memory_usage(key) 命令可以获取key占用内存大小，删除key使用 redis_server.delete(key)

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

体系决定交易盈亏，规则决定交易生死，格局决定交易高度。真正的亏钱，源于贪婪，常常出现在看到别人盈利而担心自己赚不到这一波的时候~
如果一直谨小慎微并不会亏多少，而当人因为一些外部原因获取超额盈利却把它作为自身能力时，也就逐步拉开了亏损的大幕
2024-12-17 15:45:32

linux内存相关命令的尝试

2024-12-14T15:00:00.000Z

前言

菜就多练，昨天看了一篇有关剖析 RocksDB 内存超限问题的文章，里面用了多种内存分析工具，看到那些貌似熟悉的名字，却一时也想不起怎么来用，当然像 free 和 top 这种命令还是比较熟的，但是像 vmstat 和 pidstat 这些就比较模糊了，翻了翻之前的总结也简单的描述过使用方法，但是对于这种已经忘记的实时也是不可回避的，菜就多练，今天就再练一练。

俗话说熟能生巧，有时候见的多了自然而然的就能发现规律了，比如 stat 这个词可是Linux命令中常见的面孔，它是单词 statistics 的缩写，也就统计的意思，所以就会出现类似 iostat、vmstat、netstat、pidstat、mpstat 等命令，相似的还有各种 ps 和各种 top 相关的命令，今天此文因内存而起，我们就先看看内存相关的 free、vmstat、pidstat、sar 这几个命令。

free

free 命令是我最常用的内存命令，通常我使用时会加上 -h 参数更易读一些，命令虽简单，但是想完全理解却不易，并且不同的系统对于各列的参数实现还不完全相同，而我作为实用派，不愿想个学究一样去深挖各个参数的含义，还是以实用主义为主，明白各参数的基本含义即可

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          7.3Gi       5.8Gi       377Mi        40Mi       1.1Gi       1.2Gi
Swap:         9.0Gi       5.2Gi       3.7Gi

free -h 的输出显示了系统内存和交换空间的使用情况，在我看来total≈used+available，buff/cache的空间可能一部分属于used，又有一部分属于available，free应该总是小于available的，大体就是这些规则，精确的公式我是给不出的，对于常用的判断够用了：

Mem 部分的解释

total: 总的物理内存容量（7.3Gi）。
used: 已被使用的物理内存，包括应用程序和系统缓存（5.8Gi）。
free: 尚未分配的空闲物理内存（377Mi）。
shared: 共享内存，主要用于 tmpfs 和其他共享内存用途（40Mi）。
buff/cache: 用于缓冲区（buffer）和缓存（cache）的内存（1.1Gi）。
- 缓冲区用于临时存储写入磁盘的数据。
- 缓存用于存储从磁盘读取的数据，以便更快地访问。
available: 可供应用程序使用的内存（1.2Gi）。
- 这个值是对系统内存的综合估算，它考虑了缓存中可以释放的部分。

Swap 部分的解释

total: 系统的交换空间总大小（9.0Gi）。
used: 已被使用的交换空间（5.2Gi）。
free: 尚未使用的交换空间（3.7Gi）。

vmstat

vmstat 是 Linux 和类 Unix 系统上的一个命令，用于实时监控系统性能，包括 CPU、内存、分页、磁盘 I/O 和上下文切换等信息。它非常适合用于分析系统瓶颈或性能问题。

$ vmstat 2 5 -S M
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   5351    526    152   1062    0    0    11    21    2    2  3  1 96  0  0
 0  0   5351    526    152   1062    0    0     0     0 14509 35013  2  1 97  0  0
 0  0   5351    525    152   1063    0    0     0    86 14671 35064  2  1 97  0  0
 0  0   5351    525    152   1062    0    0     0    68 14692 35164  2  1 97  0  0
 2  0   5351    525    152   1063    0    0     0   122 14504 35142  2  1 96  0  0

这个命令表示每2秒刷新一次，共刷新显示5次，单位用M，接下来以第一行数字为例，解释数据含义：

Procs (进程)

r: 正在运行队列中等待 CPU 的进程数。0 表示当前没有需要 CPU 的进程在排队。
b: 处于等待 I/O 的阻塞进程数。0 表示没有进程因等待 I/O 阻塞。

Memory (内存)

swpd: 使用的交换空间大小（单位：MB）。5351 表示已使用 5351 MB 的交换空间。
free: 空闲内存大小（单位：MB）。526 表示当前系统有 526 MB 的空闲内存。
buff: 用于缓冲区的内存大小（单位：MB）。152 表示 152 MB 的内存被用作缓冲区。
cache: 用于缓存的内存大小（单位：MB）。1062 表示 1062 MB 的内存被用作文件缓存。

Swap (交换)

si: 从磁盘交换到内存的数据速率（单位：MB/s）。0 表示当前没有从交换分区加载到内存的数据。
so: 从内存交换到磁盘的数据速率（单位：MB/s）。0 表示当前没有将内存数据写入交换分区。

IO (磁盘 I/O)

bi: 每秒从块设备（磁盘等）读取的数据量（单位：块）。11 表示每秒读取了 11 块数据。
bo: 每秒写入块设备的数据量（单位：块）。21 表示每秒写入了 21 块数据。

System (系统)

in: 每秒中断数（硬件和软件中断）。 2 表示每秒发生了 2 次中断。
cs: 每秒上下文切换次数。 2 表示每秒进行了 2 次上下文切换。

CPU (处理器)

us: 用户态进程占用 CPU 时间的百分比。 3 表示 CPU 时间的 3% 用于运行用户进程。
sy: 内核态进程占用 CPU 时间的百分比。 1 表示 CPU 时间的 1% 用于运行内核进程。
id: CPU 空闲时间的百分比。 96 表示 CPU 时间的 96% 是空闲的。
wa: CPU 等待 I/O 完成的时间百分比。 0 表示 CPU 没有时间在等待 I/O 操作完成。
st: 被虚拟机（如 KVM）偷走的时间百分比。 0 表示没有 CPU 时间被虚拟机消耗。

这个命令可以用来监控系统性能瓶颈：

如果 r 的值过高，说明 CPU 短缺。
如果 si 和 so 的值大，说明系统内存不足，频繁使用交换空间。
如果 wa 的值高，说明 I/O 操作是瓶颈。

pidstat

pidstat 是 Linux 系统中 sysstat 工具集的一部分，用于监控和报告单个进程的性能指标。它可以提供有关 CPU、内存、I/O、线程等的详细信息，帮助分析系统性能瓶颈。

$ pidstat -p 242285 -r 2 5
Linux 5.4.0-200-generic (ThinkPad-X390)     2024年12月14日  _x86_64_        (8 CPU)

15时10分47秒   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
15时10分49秒  1000    242285      0.00      0.00  302184   79776   1.05  Game10010601
15时10分51秒  1000    242285      0.00      0.00  302184   79776   1.05  Game10010601
15时10分53秒  1000    242285      0.00      0.00  302184   79776   1.05  Game10010601
15时10分55秒  1000    242285      0.00      0.00  302184   79776   1.05  Game10010601
15时10分57秒  1000    242285      0.00      0.00  302184   79776   1.05  Game10010601
Average:     1000    242285      0.00      0.00  302184   79776   1.05  Game10010601

这个命令监控242285这个进程内存情况，每2秒刷新一次，共刷新显示5次，单位用M，接下来以第一行数字为例，解释数据含义：

标题行解释

Linux 5.4.0-200-generic：运行的内核版本。
ThinkPad-X390：主机名。
2024年12月14日：当前日期。
_x86_64_：处理器架构。
(8 CPU)：系统中有 8 个 CPU 核心。

数据列解释

时间：采样的时间戳。
UID：用户 ID，显示运行进程的用户（1000 表示非 root 用户）。
PID：进程 ID，这里是 242285。
minflt/s：每秒次要缺页错误数（无需从磁盘加载内存页）。
majflt/s：每秒主要缺页错误数（需要从磁盘加载内存页）。
VSZ：虚拟内存大小（以 KB 为单位）。这里是 302184 KB，即约 302 MB。
RSS：驻留内存大小（以 KB 为单位），即实际使用的物理内存。这里是 79776 KB，即约 78 MB。
%MEM：进程使用的物理内存百分比。这里是 1.05%。
Command：进程的名称或命令，这里是 Game10010601。

这些行展示了每次采样的统计数据。这里看到该进程的 minflt/s 和 majflt/s 均为 0.00，表示没有发生缺页错误，内存访问性能良好。虚拟内存大小 (VSZ) 和驻留内存大小 (RSS) 都是恒定的，说明该进程的内存使用稳定。

sar

sar（System Activity Report）命令是一个用于收集、报告和保存系统活动信息的工具，通常在 Linux 和 Unix 系统中使用。它是 sysstat 软件包的一部分，提供了对系统性能的详细监控和分析。

$ sar -r 2 5
Linux 5.4.0-200-generic (ThinkPad-X390)     2024年12月14日  _x86_64_        (8 CPU)

15时26分06秒 kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
15时26分08秒    455724   1363580   5547036     72.86    160416    859272  23892108    140.53   4759984   1552228       428
15时26分10秒    455684   1363544   5547052     72.86    160416    859280  23886860    140.50   4760760   1552232       436
15时26分12秒    455456   1363320   5547276     72.87    160416    859284  23890572    140.53   4760420   1552236       476
15时26分14秒    455456   1363324   5547272     72.87    160416    859288  23890572    140.53   4760476   1552240       480
15时26分16秒    454700   1362572   5548028     72.88    160420    859284  23873744    140.43   4762228   1552244       480
Average:       455404   1363268   5547333     72.87    160417    859282  23886771    140.50   4760774   1552236       460

这个命令表示每2秒刷新一次内存信息，共刷新显示5次，接下来以第一行数字为例，解释数据含义：

字段含义解释

时间戳（如 15时26分08秒）：表示采集数据的时间。
kbmemfree：可用内存（以 KB 为单位）。表示系统中尚未被使用的内存量。
kbavail：可用内存（即使在缓存和缓冲区中也可用的内存，以 KB 为单位）。这个值通常比 kbmemfree 更准确，因为它考虑了系统可以回收的缓存和缓冲区内存。
kbmemused：已使用内存（以 KB 为单位）。计算公式为：总内存 - 可用内存。
%memused：已使用内存的百分比。计算公式为：(kbmemused / 总内存) * 100。
kbbuffers：用于文件系统缓存的内存（以 KB 为单位）。这是 Linux 内核用于存储未写入硬盘的数据的缓存。
kbcached：用于缓存的内存（以 KB 为单位）。这些是存储在内存中的文件数据，Linux 会尽量使用这部分内存来加快读取速度。
kbcommit：提交内存（以 KB 为单位）。表示可以分配给进程的内存总量，达到该值时会导致内存不足。
%commit：提交内存的百分比。表示已提交内存与可用内存的比例。
kbactive：活动内存（以 KB 为单位）。表示最近被访问的内存页。
kbinact：非活动内存（以 KB 为单位）。表示不再被访问的内存页。
kbdirty：脏页内存（以 KB 为单位）。表示已被修改但尚未写入硬盘的内存。

示例分析

kbmemfree 在 455724 KB 左右，表示系统还有相当数量的可用内存，说实话也不算多了，才400多M。
kbmemused 的值为 5547036 KB，表示大约 5.5 GB 的内存已被使用，且 %memused 为 72.86%，表明内存使用率较高。
kbbuffers 和 kbcached 的值相对较小，这可能表示系统正在利用可用内存缓存数据，从而优化性能。
kbcommit 和 %commit 的值显示系统的内存承诺也在一个相对健康的范围。

总结

free -h 最常用的内存查看工具，可以方便快捷知晓内存总体情况，查看总量与可用内存值
vmstat 2 5 -S M 可用于监控内存，分析系统瓶颈或性能问题，r 的值过高说明 CPU 短缺。si 和 so 的值大，说明系统内存不足，频繁使用交换空间
pidstat -p 242285 -r 2 5 可提供单个进程的内存使用信息，分析缺页情况
sar -r 2 5 可分析内存总体情况，查看活动内存、非活动内存、脏页内存等信息
因统计口径的不同，可能会遇到两个命令查出来的值不同，这些不必强求，熟悉各个命令的特点，遇到问题多方比较就可以了

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

我熬的不是夜，而是短暂的自由。因为我知道，一旦睡着了，再次醒来时我便不再属于我自已~
2024-12-14 16:04:22

日常应用开发遇到的小问题二三则

2024-11-29T12:21:48.000Z

前言

这两天的工作又相对杂乱一些，处理一下A事情，又要搞一搞B事情，需要盯着C事情，还要尝试一下D事情，所以这篇总结没有什么主线，主要目的是记录一下最近解决的问题，先不展开讨论，当类似的问题积累一些再展开描述，我就先记录一下流水账了。

Redis问题

本来是一个常规清理数据，Redis回收内存碎片的操作，但是因redis-server版本问题被迫切换解决方案

启用碎片自动回收失败

1
2
3

127.0.0.1:6379> config set activedefrag yes
(error) ERR Active defragmentation cannot be enabled: it requires a Redis server compiled with
a modified Jemalloc like the one shipped by default with the Redis source distribution

开启主动碎片整理机制失败，提示错误大概意思是说，当前的 Redis 服务器未使用支持主动碎片整理（Active Defragmentation）的 Jemalloc 分配器，因为Redis 的主动碎片整理功能依赖于 Jemalloc 分配器，如果 Redis 是使用其他分配器（如 libc malloc）编译的，或者当前的 Jemalloc 缺乏必要的功能，就会导致该功能无法启用。

可以通过Redis命令 redis-cli INFO memory | grep allocator 来查询，如果显示 mem_allocator:jemalloc，则表示启用了 Jemalloc。如果显示 mem_allocator:libc，则说明当前未使用 Jemalloc，需要重新安装或编译 Redis。

我运行一看当然是 mem_allocator:libc 了，看来没办法进行碎片整理了，幸好是个slave节点，所以我干脆保存数据后重启一下吧。

启动Redis未脱离终端

首先关闭redis服务

1	shutdown SAVE

这个过程会进行同步存储，所以会给你一种卡死了的状态，因为我这里有90G数据，存储大概用了10多分钟，Redis服务成功关闭

然后按配置文件启动Redis

1	/usr/local/bin/redis-server ./redis.conf

启动完终端就停在这个了，难道我起了个前台程序？我记得之前都是这么启动的啊，总不能为了脱离终端我还要使用 nohup 和 & 来配合吧，有点low啊，主要是日志是不是就放到nohup.out文件里了，找找有没有配置吧，打开redis.conf文件发现daemonize no，我的天啊，这个redis-server为什么这么与众不同，守护进程模式居然是关着的，虽然说把配置文件改成 daemonize yes 再启动就好了，但是我好奇的是之前是怎么启动的。

我决定不修改配置文件了，保持原来的样子，直接在启动时指定 --daemonize yes 好了，这样可以达到目的，在Linux系统中使用Redis时，命令行参数和配置文件参数（也称为Redis配置）具有不同的优先级。如果同一个配置选项在配置文件和命令行参数中被设置，那么命令行参数将覆盖配置文件中的设置。

Vercel问题

之前简单聊过将Nextjs框架编写的网站部署到Vecel有天然的适应性，因为Vercel背后的团队就是开发出Nextjs框架的那群人，部署到Vercel以后绑定一个域名就可以使用了，不需要自己安装运行环境，不需要配置DN缓存，不需要配置SSL证书，真是方便极了，但免费的账户是有资源限制的，特别是要团队开发的话需要购买付费版本。

未在Vecel团队的人提交无法触发自动部署

用过Vercel就会发现，当通过github导入项目之后，以后每次推送到github后都能自动触发Vercel的网站发布功能，但是未添加到Vercel团队的账号提交时无法触发自动部署，提示

Vercel - No GitHub account was found matching the commit author email address

一种办法就是把所有可能提交的账号都添加到Vercel团队，但是这是要花钱的，每添加一个成员每月$20，还有就是找已经在团队的成员再提交一次，触发自动部署就行了，这个成本也很低，也就是仓库记录不那么干净了而已

1	git commit --allow-empty -m"trigger redeployment"

更新package.json后部署Vercel时报错

因为我使用 npm install 初始化完项目后，启动时有两个警告

Module not found: Can't resolve 'bufferutil' in 'E:\WorkSpace\nodeweb\qxweb\node_modules\ws\lib'

Import trace for requested module:
./node_modules/ws/lib/buffer-util.js
./node_modules/ws/lib/websocket.js
./node_modules/ws/index.js
./node_modules/@supabase/realtime-js/dist/main/RealtimeClient.js
./node_modules/@supabase/realtime-js/dist/main/index.js
./node_modules/@supabase/supabase-js/dist/main/index.js
./store/SupabaseStore.tsx

./node_modules/ws/lib/validation.js
Module not found: Can't resolve 'utf-8-validate' in 'E:\WorkSpace\nodeweb\qxweb\node_modules\ws\lib'

Import trace for requested module:
./node_modules/ws/lib/validation.js
./node_modules/ws/lib/websocket.js
./node_modules/ws/index.js
./node_modules/@supabase/realtime-js/dist/main/RealtimeClient.js
./node_modules/@supabase/realtime-js/dist/main/index.js
./node_modules/@supabase/supabase-js/dist/main/index.js
./store/SupabaseStore.tsx

所以我就手动安装了这两个库 npm isntall bufferutil utf-8-validate，这就导致我的 package.json 文件更新内容里增加了这两个库的引用版本，提交代码部署Vercel时报错

Running build in Washington, D.C., USA (East) – iad1
Cloning github.com/2338-AI/quantum-solutions-web (Branch: main, Commit: 96249d1)
Previous build cache not available
Cloning completed: 2.607s
Running "vercel build"
Vercel CLI 39.1.1
Detected `pnpm-lock.yaml` version 9 generated by pnpm@9.x
Installing dependencies...
 ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with /package.json
Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
    Failure reason:
    specifiers in the lockfile ({"@douyinfe/semi-ui":"^2.44.0","@react-spring/web":"^9.7.5","@supabase/supabase-js":"^2.38.1","accept-language":"^3.0.18","classes-names":"^1.0.0","emailjs-com":"^3.2.0","i18next":"^23.5.1","i18next-browser-languagedetector":"^7.1.0","i18next-resources-to-backend":"^1.1.4","is-mobile":"^5.0.0","next":"13.5.4","react":"^18","react-dom":"^18","react-google-recaptcha":"^3.1.0","react-i18next":"^13.3.0","swiper":"^11.1.14","tailwind-merge":"^2.5.4","@types/node":"^20","@types/react":"^18","@types/react-dom":"^18","@types/react-google-recaptcha":"^2.1.7","@typescript-eslint/eslint-plugin":"^6.3.0","@typescript-eslint/parser":"^6.3.0","autoprefixer":"^10","eslint":"^8","eslint-config-airbnb":"^19.0.4","eslint-config-airbnb-typescript":"^17.1.0","eslint-config-next":"13.5.4","postcss":"^8","postcss-pxtorem":"^6.1.0","prettier":"^3.3.3","prettier-plugin-tailwindcss":"^0.6.8","tailwindcss":"^3","typescript":"^5"}) don't match specs in package.json ({"@types/node":"^20","@types/react":"^18","@types/react-dom":"^18","@types/react-google-recaptcha":"^2.1.7","@typescript-eslint/eslint-plugin":"^6.3.0","@typescript-eslint/parser":"^6.3.0","autoprefixer":"^10","eslint":"^8","eslint-config-airbnb":"^19.0.4","eslint-config-airbnb-typescript":"^17.1.0","eslint-config-next":"13.5.4","postcss":"^8","postcss-pxtorem":"^6.1.0","prettier":"^3.3.3","prettier-plugin-tailwindcss":"^0.6.8","tailwindcss":"^3","typescript":"^5","@douyinfe/semi-ui":"^2.44.0","@react-spring/web":"^9.7.5","@supabase/supabase-js":"^2.38.1","accept-language":"^3.0.18","bufferutil":"^4.0.8","classes-names":"^1.0.0","emailjs-com":"^3.2.0","i18next":"^23.5.1","i18next-browser-languagedetector":"^7.1.0","i18next-resources-to-backend":"^1.1.4","is-mobile":"^5.0.0","next":"13.5.4","react":"^18","react-dom":"^18","react-google-recaptcha":"^3.1.0","react-i18next":"^13.3.0","swiper":"^11.1.14","tailwind-merge":"^2.5.4","utf-8-validate":"^6.0.5"})
Error: Command "pnpm install" exited with 1

这个错误提示说明 Vercel 在部署过程中使用 pnpm 安装依赖时，遇到了 pnpm-lock.yaml 和 package.json 文件中的依赖不匹配问题。具体来说，pnpm-lock.yaml 文件中的依赖版本与 package.json 中声明的版本范围不一致，导致 pnpm 无法继续安装。

看到这时我才意识到我的项目里有个 pnpm-lock.yaml，而我使用的 npm 安装，本地有个 package-lock.json 文件，这样一看是我工具用错了呀，我说这个项目怎么没提交 package-lock.json 文件呢

清理模块重新安装吧

1 2	rm -rf .node_modules package-lock.json pnpm install

输出如下

PS E:\WorkSpace\nodeweb\qxweb> pnpm install

   ╭──────────────────────────────────────────────────────────────────╮
   │                                                                  │
   │                Update available! 9.5.0 → 9.14.2.                 │
   │   Changelog: https://github.com/pnpm/pnpm/releases/tag/v9.14.2   │
   │                Run "pnpm add -g pnpm" to update.                 │
   │                                                                  │
   │         Follow @pnpmjs for updates: https://x.com/pnpmjs         │
   │                                                                  │
   ╰──────────────────────────────────────────────────────────────────╯

Lockfile is up to date, resolution step is skipped
Packages: +423
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 WARN  GET https://registry.npmmirror.com/next/-/next-13.5.4.tgz error (ECONNRESET). Will retry in 10 seconds. 2 retries left.
Downloading @next/swc-win32-x64-msvc@13.5.4: 36.94 MB/36.94 MB, done
Downloading next@13.5.4: 16.80 MB/16.80 MB, done
Downloading typescript@5.2.2: 7.23 MB/7.23 MB, done
Progress: resolved 423, reused 184, downloaded 239, added 423, done
node_modules/.pnpm/es5-ext@0.10.62/node_modules/es5-ext: Running postinstall script, done in 43.1s
node_modules/.pnpm/utf-8-validate@5.0.10/node_modules/utf-8-validate: Running install script, done in 52.3s
node_modules/.pnpm/bufferutil@4.0.8/node_modules/bufferutil: Running install script, done in 52.3s

dependencies:
+ @douyinfe/semi-ui 2.44.0
+ @react-spring/web 9.7.5
+ @supabase/supabase-js 2.38.1
+ accept-language 3.0.18
+ classes-names 1.0.0
+ emailjs-com 3.2.0
+ i18next 23.5.1
+ i18next-browser-languagedetector 7.1.0
+ i18next-resources-to-backend 1.1.4
+ is-mobile 5.0.0
+ next 13.5.4
+ react 18.2.0
+ react-dom 18.2.0
+ react-google-recaptcha 3.1.0
+ react-i18next 13.3.0
+ swiper 11.1.14
+ tailwind-merge 2.5.4

devDependencies:
+ @types/node 20.8.6
+ @types/react 18.2.28
+ @types/react-dom 18.2.13
+ @types/react-google-recaptcha 2.1.7
+ postcss-pxtorem 6.1.0
+ prettier 3.3.3
+ prettier-plugin-tailwindcss 0.6.8
+ tailwindcss 3.3.3
+ typescript 5.2.2

Done in 21m 2.3s

这次再启动项目 pnpm run dev 就不报缺失模块的警告了

简单说下 npm 和 pnpm 的关系，npm 是 Node.js 的默认包管理工具，用于安装、管理和共享 JavaScript 包。安装 Node.js 时会自带 npm，不需要额外安装。pnpm 是一种兼容 npm 和 yarn 的包管理工具。它与 npm 类似，也用来管理 JavaScript 包，但通过优化磁盘使用和依赖解析性能解决了 npm 的一些问题。

再简单说下 package.json、package-lock.json 和 pnpm-lock.yaml 的关系

package.json 描述项目的基本信息（如项目名称、版本号），声明项目的依赖项、脚本命令和配置，是项目中最重要的依赖描述文件，是开发者直接编辑的文件，但不包含依赖的具体版本信息
package-lock.json 是 npm 包管理工具生成的锁定文件，记录依赖的具体版本号和结构，确保不同环境中安装的依赖版本一致。不需要手动编辑，由 npm 自动生成和管理。
pnpm-lock.yaml 是 pnpm 包管理工具生成的锁定文件，用于精确记录依赖的版本号和安装结构。确保团队或 CI/CD 环境在安装依赖时，所有人使用的依赖版本完全一致。不需要手动编辑，由 pnpm 自动生成和管理。

可以看到package-lock.json 和 pnpm-lock.yaml是互斥的，平时 npm 和 pnpm 选择一个就行，别混着用。

Android问题

Apple推送选择APNs就好了，而Android推送一直就是老大难，因为FCM对谷歌框架的依赖，国内基本是不可用的，所以在之前的蛮荒年代，真是八仙过海各显其能，相互拉起、定时检测等等搞得手机卡顿的不行，后来各家厂商基本都实现了自己的通道，比如华为、小米、OPPO、Vivo等等，所以找个聚合的SDK也是能办到的，但是国外还是主要依赖FCM。

但随着Android版本的提升，推送的要求越来越严，一旦应用被强制杀死，FCM消息虽然能达到手机，但是不允许拉起应用，导致消息无法触及到用户，这也是目前国外环境要实现推送所面临的难点。

要想能收到FCM的推送消息，就得保证应用不被杀死，可能得方向有提高优先级、定时检测重启、杀死后立即重启、采用其他的推送通道等等，但是效果都不理想，之前好用的方式升级版本或者切换一个手机厂商就不太好使了，没有什么通用的解决办法。

后来发现，真对国内手机只要给应用开启自启动权限，那么即使被强杀后也能收到FCM通知，或许这是一个可以努力的方向，但这个权限不是通用的逻辑，每个手机厂商都有自己的白名单，大厂APP出生就在白名单里，而我们自己开发的APP需要经过复杂的引导操作才能加入其中，虽然很难，但终归是第一条可行的路。

主动请求通知权限

在 Android 13 (API 33) 及以上版本，应用需要 主动请求通知权限，以便能够发送通知。对于之前的版本，应用只需要在 AndroidManifest.xml 中声明 POST_NOTIFICATIONS 权限即可。然而，从 Android 13 开始，仅在声明权限的基础上，还需要在运行时申请此权限。

步骤1：修改 AndroidManifest.xml

首先，在 AndroidManifest.xml 文件中声明权限：

1	<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

步骤2：在应用中请求通知权限

从 Android 13 开始，你需要在运行时请求通知权限。你可以使用 NotificationManagerCompat 来检查和请求权限。

import android.os.Build;
import android.widget.Toast;
import androidx.core.app.NotificationManagerCompat;
import androidx.appcompat.app.AppCompatActivity;
import android.os.Bundle;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // 检查 Android 13 及以上版本是否需要请求通知权限
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            NotificationManagerCompat notificationManagerCompat = NotificationManagerCompat.from(this);
            // 检查通知权限是否已被授权
            if (!notificationManagerCompat.areNotificationsEnabled()) {
                // 如果没有授权，可以弹出提示或者引导用户
                requestNotificationPermission();
            } else {
                // 如果已授权，可以继续执行相关逻辑
                Toast.makeText(this, "通知权限已授权", Toast.LENGTH_SHORT).show();
            }
        }
    }

    private void requestNotificationPermission() {
        // 你可以在这里引导用户到设置页面手动授权
        Toast.makeText(this, "请在设置中授权通知权限", Toast.LENGTH_LONG).show();
    }
}

步骤3：引导用户授权

如果用户没有授权通知权限，你通常需要提供一个方法引导他们到设置页面，在该页面中手动授权。因为从 Android 13 开始，权限只能通过系统设置进行手动授权，而不是通过应用内弹窗。

private void goToSettings() {
    Intent intent = new Intent(Settings.ACTION_APP_NOTIFICATION_SETTINGS)
            .putExtra(Settings.EXTRA_APP_PACKAGE, getPackageName());
    startActivity(intent);
}

网络状态变化的监听不能使用静态注册

从 Android 7.0 (API 24) 开始，网络状态变化的监听不能使用静态注册 ( 标签在 AndroidManifest.xml 中注册)，必须通过动态注册来实现。这是出于优化电池和性能的考虑，Android 不再允许应用通过静态注册的方式来监听系统广播（如网络变化、屏幕开关等），尤其是对敏感的系统事件。

静态注册 (AndroidManifest.xml)

静态注册会在 AndroidManifest.xml 中声明广播接收器，并且会在整个应用运行期间自动接收系统广播。对于网络状态变化（如 CONNECTIVITY_ACTION）的静态注册从 Android 7.0 开始被限制。

AndroidManifest.xml 中的静态注册示例（在 Android 7.0 之前是有效的）：

<receiver android:name=".NetworkChangeReceiver">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
    intent-filter>
receiver>

这种方式在 Android 7.0 及以后会被限制，无法接收到网络状态变化的广播。

动态注册 (代码中注册)

动态注册意味着在应用运行时，通过 Context.registerReceiver() 来注册接收器，这样可以选择性地在需要时注册，并在不需要时取消注册。这样做的好处是，可以更灵活地控制接收器的生命周期，避免不必要的电池消耗。

动态注册的示例：

public class MainActivity extends AppCompatActivity {
    private NetworkReceiver networkReceiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 初始化网络广播接收器
        networkReceiver = new NetworkReceiver();
        IntentFilter filter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);

        // 动态注册接收器
        registerReceiver(networkReceiver, filter);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // 注销接收器
        unregisterReceiver(networkReceiver);
    }
}

public class NetworkReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        // 获取网络连接状态
        ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
        NetworkInfo activeNetwork = cm.getActiveNetworkInfo();

        if (activeNetwork != null && activeNetwork.isConnected()) {
            Log.d("NetworkReceiver", "网络已连接");
        } else {
            Log.d("NetworkReceiver", "网络未连接");
        }
    }
}

在这个示例中，使用 registerReceiver() 动态注册了一个监听网络状态变化的广播接收器 NetworkReceiver，并在 onCreate() 中进行注册，在 onDestroy() 中进行注销，以避免内存泄漏。

各种Service介绍和对比

在 Android 中，Service 是一种后台组件，用于在应用中执行长时间运行的任务。根据服务的用途和生命周期，Android 提供了不同类型的服务。以下是 Android 中常见的 Service 类型和 BroadcastReceiver 的介绍及对比：

普通 Service (Normal Service) 没有前台 UI 组件。通常用于执行后台任务，不与用户交互，可以在应用的任何地方启动，并在后台运行，直到它完成工作或被显式停止，生命周期为 onCreate() → onStartCommand() → onDestroy()，适用执行短时间的后台任务，如数据同步、文件下载等场景。

前台服务 (Foreground Service) 在运行时必须显示一个持续的通知（通知栏），因此它会在用户和系统资源管理中被认为是一个“重要”的服务，不容易被系统杀死。生命周期为 onCreate() → onStartCommand() → onDestroy() (服务必须调用 startForeground() 来显示通知)，适用执行长期任务，如播放音乐、导航、实时更新等场景。

Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
    .setContentTitle("My Foreground Service")
    .setContentText("Service is running in the foreground")
    .setSmallIcon(R.drawable.ic_notification)
    .build();
startForeground(1, notification);

JobService 是一种特殊类型的服务，它用于执行计划任务（即 JobScheduler），在特定条件下（如网络连接、充电等）启动。JobService 适合用于执行延迟任务或条件任务，如周期性数据同步、定时上传等，与 JobScheduler 配合使用，可以在设备的空闲时间或在设备满足某些条件时执行任务。生命周期为 onCreate() → onStartJob() → onStopJob()，适用执行定期任务，延迟任务，或者需要满足某些条件（如网络连接、充电等）的任务场景

public class MyJobService extends JobService {
    @Override
    public boolean onStartJob(JobParameters params) {
        // 执行任务
        return true; // 返回 true 表示任务正在进行中
    }

    @Override
    public boolean onStopJob(JobParameters params) {
        // 停止任务
        return true; // 返回 true 表示任务被取消
    }
}

BroadcastReceiver 是 Android 中用于接收广播的组件。它通过监听系统广播或自定义广播来响应事件（如网络状态变化、电池电量变化等）。BroadcastReceiver 不会启动一个独立的线程，它只会在接收到广播时执行相应的代码。onReceive() 方法在接收到广播时调用。适用监听和响应系统广播，如网络连接变化、设备开关机、短信接收、系统更新等场景

public class NetworkChangeReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (ConnectivityManager.CONNECTIVITY_ACTION.equals(intent.getAction())) {
            // 处理网络变化
        }
    }
}

服务类型	生命周期	适用场景	优缺点
普通 `Service`	`onCreate()` → `onStartCommand()` → `onDestroy()`	短时间的后台任务	简单易用，但容易被系统杀死，适用于短时间的任务
前台 `ForegroundService`	`onCreate()` → `onStartCommand()` → `onDestroy()`	长时间运行的任务，如播放音乐、导航	不容易被杀死，但需要显示通知，可能影响用户体验
`JobService`	`onCreate()` → `onStartJob()` → `onStopJob()`	执行定期任务、延迟任务，或者需要满足某些条件的任务	适用于需要在特定条件下执行的任务，延迟执行，但不能精确控制执行时机
`BroadcastReceiver`	`onReceive()`	响应广播事件，如网络状态变化、电池状态变化等	适合处理广播事件，不能执行长时间操作，执行时间受限制

总结

Redis如果未使用Jemalloc无法开启主动的碎片回收，通过 redis-cli INFO memory | grep allocator 可查询内存分配器
启动Redis的方法 /usr/local/bin/redis-server ./redis.conf --daemonize yes
管理node模块时可以选择 nmp 或者 pnmp，不要混用，总的来说后者更优秀一点
管理Nextjs项目时最好吧 package.json 和 package-lock.json(pnpm-lock.yaml)都上传，便于安装出相同的运行环境
触发Vercel重新部署的命令 git commit --allow-empty -m"trigger redeployment"
Android的服务有很多种，普通服务Service、前台服务ForegroundService，定时服务JobService等等

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

在自己的世界里独善其身，在别人的世界里顺其自然~
2024-11-29 15:50:46

git克隆报错时The project you were looking for could not be found...

2024-11-20T17:45:00.000Z

Ps D:>git clone http://gitlab.yyy.com/project/xxx.git
Cloning into ‘xxx’..
remote: The project you were looking for could not be found or you don’t have permission to view it.
fatal: repository ‘http://gitlab.yyy.com/project/xxx.git/'not found

前言

问题如上，使用 git clone 命令克隆一个仓库的时候，提示我项目找不到或者没有权限，一开始我还以为路径拼错了，核对了两遍确认仓库地址正确的，访问仓库的权限肯定也有的，我使用账号和密码可以成功登录gitlab网站并且看到这个项目，网上查询方案大概原因是电脑的git自动保存了其他的用户名密码信息，与当前项目的用户名密码与之前的发生冲突，处理掉这种情况就行了。

解决方案

清理或者避开这种冲突的情况：

临时方案

克隆的时候在远程地址加上用户名及密码

1	git clone http://username:password@gitlab.yyy.com/project/xxx.git

永久方案

清除本地保存git账户，下次再进行git clone操作时，在弹出窗口中输入用户名密码

1	git config --system --unset credential.helper

如果是 Linux 或 Mac系统改为下面的命令

1	git config --global --unset credential.helper

总结

临时用户克隆仓库的命令 git clone http://username:password@gitlab.yyy.com/project/xxx.git
清理本地git账户的命令 git config --system --unset credential.helper

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

国王们以世俗的权柄和虚名让你下跪，只有你可以让自己站起来，满嘴的仁义道德，不过是国王统治下的壁垒，几千年根深蒂固~
2024-11-20 21:15:33

会打字就能建网站的广告词是否夸大其词呢

2024-11-18T15:30:00.000Z

前言

首先声明这不是一篇广告文，只是我最近用了一款建站的产品，在使用过程中也遇到了一些问题，所以总结一下避免以后继续踩坑，其中“会打字就能建网站”的广告词还是挺吸引人的，给人一种“有手就行”的既视感。

这款产品的名字叫 “云·速成美站”，是一种典型的SaaS（软件即服务）产品，也是一款自助型网站建设产品。

这广告词听听就好了，我一开始并没有拿到这么明确的产品规格，放到我手里的是一个完成了ICP备案的域名和一台ECS实例，目的是访问域名返回一个简约的企业网站，所以我一开始的想法是为了显示网站我干脆在ECS搭建一个算了，放个静态页面或者用Python自动生成个简易的首页，再把域名解析到ECS的服务器就完活了，后来觉得態简陋了，那干脆安装个WordPress，正好前段时间一直在忙这些事情，也算是有一些经验了，搭建起来应该会很快的。

发现ECS实例的秘密

后来渐渐发现不对劲，这台ECS的操作系统是 Alibaba Cloud Linux 3.2104 LTS 64位等保2.0三级版，而镜像是云·原生建站-容器版(m-2zedbkbwq1gwd41nysyv)，并且没有操作密码也没绑定密钥，这个ECS看起来不简单呀，应该是一个包含了建站产品的镜像，根本不是一个简简单单的的逻辑器，对于这点账号所有者并不清楚，只告诉我买了一个建站套餐，好吧，我继续翻一翻。

终于通过订单，在云市场 -> 已购买服务 中发现了 云·原生建站-容器版，同时还有一个 云·速成美站，果然是一个预制的建站产品，然后就找找教程吧，发现了这个云·原生建站-docker 版产品激活流程

教程中提到直接浏览器访问“ECS公网IP”，然后设置管理员手机号，然后绑定网站即可。一些相关的访问链接入下：

因为教程让直接访问ECS公网IP，浏览器默认会使用80端口，如果可以进行才做，说明这个ECS实例本身就带了一个web服务才对，再回想刚才实例的镜像名字应该就是定制的，包含一个Web服务应该很容易，正当我以为按教程操作就万事大吉时，得到的却是“地址无法访问”的提示。

如果是一个仅仅会打字的人到这里估计已经懵圈了，而我还是有点基础的，去查询了防火墙发现80端口没有放开，所以手动开启了80端口的入站规则，成功设置了管理员手机号，但是却无法理解绑定网站是怎么一个操作，也找不到可以绑定的网站产品，更无法理解这个ECS 云·原生建站-容器版和 云·速成美站 究竟是什么关系。

网站设计

后来还是在订单了找到 云·速成美站，通过“免登”方式进入了后台，俨然一副WP的画面，只是作为企业网站建站工具，他更加的具象化了，什么公司名啊、ICP备案号啊、公司电话啊、公司Logo等等，只要你在后台设置了，就可以在网站上直接显示，并且有上千套模板一键替换。

这个感觉就是像是你买完产品，他自动给你注册了一个WordPress账号，然后给你预制了一些企业官网的模板一样，我简单填写了信息，绑定了之前备过案的域名，因为域名也在阿里云上申请的，所以一键绑定会非常方便，否则就要自己去添加解析记录了。

绑定验证需要一点点时间，显示15分钟，但是我有一个子域名大概8小时才验证通过，验证完成之后就可以开启 HTTPS，可以用免费的，并且会自动续期，对于不爱折腾的小白来说还是非常方便的。

再次处理ECS实例

这时我的网站可以通过域名访问了，通过ping命令发现网站并不是我们之前提到的ECS的公网IP，那么要ECS还有什么用呢？这是一直困扰着我的问题，这时我再来到绑定页面发现感刚刚建站的那个产品出现了，激动的我赶紧点击绑定按钮，得到的却是“该ECS初始化失败，请重置ECS镜像后重试”的报错，提了工单，第二天得到反馈让我把实例的操作系统重新安装一下，当然在替换的过程中因为选错了镜像还把之前的预制系统给删没了，后来好不容易在镜像市场中找到 云·原生建站-容器版 又替换了回来。

重启安装好镜像的ECS，绑定时依旧报原来的问题，但是放了大概1个小时之后，再次尝试绑定就成功了，然后又迷迷糊糊的绑定了一次域名，开启了HTTPS，这次在Ping域名的时候，返回的就是ECS的公网IP，通过反复翻阅文档，然后与客服交流，终于弄懂了一些之前的疑问。

正确的操作步骤

通过后视镜来看这个建站过程走了很多弯路，正确的步骤如下：

购买备案建站套餐
在云市场 -> 已购买服务 中找到 云·速成美站，点击免登按钮进入网站设计后台，填写基本信息后发布
访问ECS的安全规则，开启80端口的入站规则
浏览器访问ECS公网IP，按照教程绑定网站和ECS
进入网站后台绑定域名，开启HTTPS

总结

IaaS (Infrastructure as a Service) - 基础设施即服务，提供最基础的计算资源，包括服务器、存储、网络和虚拟化环境等
PaaS (Platform as a Service) - 平台即服务，提供一个完整的开发和部署环境，允许用户专注于应用程序的开发，而不需要管理底层基础设施
SaaS (Software as a Service) - 软件即服务，是一种提供应用程序的服务模式，用户可以直接通过网络访问和使用应用软件，无需自己安装或维护任何硬件或软件
现在的建站真是太方便了，比我那时候专门做首页设计要快速多了，之前我还只是创建静态页面
云·速成美站已集成了服务器，建设过程中也无需任何额外费用。网站上线，仅需拥有一个域名
虽说这种产品建站很方便，但是却没有达到 “会打字就能建网站” 的这个口号

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

很多人生的选择不是深思熟虑就能选对的，还有一些运气在里面的，甚至是运气占了主要因素，总是觉得没选的那条路是精彩非凡的坦途，内心的美化罢了~
2024-11-18 17:28:28

Docker启动gitlab后22端口被占用如何解决

2024-11-07T16:30:00.000Z

前言

这两天一直在研究Docker启动gitlab的问题，邮件问题暂时告一段落，当真正开始使用gitlab克隆的时候发现，之前22端口被占用无法启动，我就用2022端口做了一个映射，但是在gitab界面上提供的克隆地址类似这样 git@gitlab.gameup.com:games/xxx.git，丝毫没有端口 2022 的影子，执行 git clone git@gitlab.gameup.com:games/xxx.git 果然不可下载，所以搜索了一圈解决方案总结在此，方便日后查找。

Docker启动参数

docker run --detach \
  --hostname gitlab.gameup.com \
  --publish 443:443 --publish 80:80 --publish 2022:22 \
  --name gitlab \
  --restart always \
  --volume /export/docker/gitlab/config:/etc/gitlab \
  --volume /export/docker/gitlab/logs:/var/log/gitlab \
  --volume /export/docker/gitlab/data:/var/opt/gitlab \
  registry.cn-hangzhou.aliyuncs.com/z5z/gitlab-ce:latest

这个在之前的文章中提到过，因为 80 和 443端口正常可用，所有采用HTTP方式的下载 git clone http://gitlab.gameup.com/games/xxx.git 是正常的，而 SSH下载的这种方式，因为修改了默认端口，导致提供的链接无法下载，即使我像这样 git clone git@gitlab.gameup.com:2022/games/xxx.git 加上了端口也无法正常克隆。

用一种比较笨的方法就是，关闭SSH服务或者将宿主机的SSH服务改个端口，但这是一台远程服务器，一般都通过SSH协议访问，关闭不太现实，修改端口的话倒是可行，可是之前这台机器上运行着多个任务，这意味着很多服务脚本都得修改，所以也不是很好的办法，不能因为加了个新服务就把原来的老脚本统统改一遍吧，尝试多次终于找到一个可以接收的方法。

解决方案

进入gitlab容器 docker exec -it gitlab
修改配置文件 /etc/gitlab/gitlab.rb 中的内容
1
gitlab_rails['gitlab_shell_ssh_port'] = 2022
注意这个设置只是修改了 GitLab 的显示信息，不会更改 GitLab 容器内的 SSH 服务端口
执行 gitlab-ctl reconfigure 即可
修改执行之后，再次查看gitlab下载地址发现改成了 ssh://git@gitlab.gameup.com:2022/games/xxx.git，不仅加了端口号，还在前面加上了 ssh://，怪不得我自己加端口号不能能用呢，关于这一点我也查到了相关解释：

GitLab 提供的 SSH 克隆地址（如 git@gitlab.gameup.com:2022/games/xxx.git）是一种简化格式，它没有指定协议前缀 ssh:// 和端口号。这是因为默认情况下，Git 使用 SSH 协议连接，并默认通过端口 22 来克隆和操作仓库。因此，这种简化格式省略了 ssh:// 前缀和端口号
对于标准端口（22），简化格式的地址是有效的，因为 Git 客户端会默认使用 SSH 协议并连接到 22 端口,但是，当你的 SSH 端口不同于 22（如使用 2022 时），Git 默认的简化格式就不适用了，需要显式指定端口号或配置 SSH，也就是写成 ssh://git@gitlab.gameup.com:2022/games/xxx.git 的形式

总结

使用docker启动gitlab遭遇22端口占用时可以选择其他端口映射 --publish 2022:22
修改映射端口后为了让下载地址显示正确，需要修改gitlab配置文件 gitlab_rails['gitlab_shell_ssh_port'] = 2022
git@gitlab.gameup.com:games/xxx.git 是一种ssh协议的简化形式，完整的地址应该为 ssh://git@gitlab.gameup.com:22/games/xxx.git

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

不要再抑郁下去了孩子，你要像一个，神经病一样活泼开朗，不要太在乎别人的目光，因为没人会注意你。
2024-11-7 19:21:48

使用 Let’s Encrypt 获取免费SSL证书

2024-11-06T15:45:00.000Z

前言

之前不太了解SSL免费证书，只研究过一点自签名SSL证书的知识，前几年的12306就是用的这种证书，访问网站时要求你下载安装并信任根证书，后来在腾讯云上薅了一个免费一年的SSL证书，过期后也就没有再更新，在我印象中SSL证书整的很贵，一般的不涉及隐私新的的交互也不需要非得 HTTPS。

从今年我开始接触到了更多的SSL证书知识，原来腾讯云上的SSL证书过期后还可以免费申请，AWS上也有可以自动续期的免费SSL证书，甚至还有 Let’s Encrypt、ZeroSSL、SSL For Free、Cloudflare、BuyPass 等众多可以提供免费证书的机构，本文我们来试试 Let’s Encrypt 怎么用。

Let’s Encrypt 是一个提供 免费 SSL/TLS 证书 的认证机构（CA），旨在通过简化证书申请和安装过程来普及 HTTPS 加密，提升互联网安全性。它由 Internet Security Research Group (ISRG) 运营，并在全球范围内免费提供数字证书，用于加密网站流量，防止数据在传输过程中被窃取或篡改。

Let’s Encrypt 是一个非常受欢迎且实用的工具，能够帮助网站管理员免费获得 SSL/TLS 证书并轻松安装，尤其适用于那些希望以低成本保障网站安全的小型网站和个人项目。然而，对于需要更高级别验证（如 EV 证书）的大型网站或企业来说，Let’s Encrypt 可能不完全符合需求。

申请需求

我的机器操作系统是 CentOS 7，因为本地还占用了80端口提供web服务，故不能使用HTTP-01验证方式，使用证书的是另一台机器，所以这里只需要申请获得证书文件即可，不需要自动部署和更新。

要在 CentOS 7 上使用 Let’s Encrypt 并通过 DNS 验证申请 SSL 证书，而不依赖 80 端口，可以选择 Certbot 的 DNS 验证模式。这种方法适用于可以访问域名的 DNS 管理，并手动添加验证记录。完成验证后，您可以手动将生成的证书文件复制到目标机器上进行安装。

详细步骤：

安装 Certbot

首先，在 CentOS 7 上安装 Certbot：

1 2	sudo yum install epel-release -y sudo yum install certbot -y

使用 DNS 验证生成证书

使用以下命令启动 DNS 验证模式：
1
sudo certbot certonly --manual --preferred-challenges dns -d api.moon.com
- --manual：表示手动输入 DNS 记录
- --preferred-challenges dns：指定使用 DNS 验证方式
- -d api.moon.com：需要申请证书的域名

Certbot 会提示创建一个特定的 DNS TXT 记录来验证域名。您会看到类似以下的提示信息：

Please deploy a DNS TXT record under the name
_acme-challenge.api.moon.com with the following value:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Before continuing, verify the record is deployed.

登录自己的 DNS 提供商控制台，在 api.moon.com 的 DNS 配置中添加一个 TXT 记录：
- 名称：_acme-challenge.api.moon.com
- 类型：TXT
- 值：Certbot 提供的值（如上所示的随机字符串）
等待几分钟，确保新添加的 DNS 记录已经传播。您可以使用以下命令确认 DNS 记录是否生效：
1
nslookup -type=TXT _acme-challenge.api.moon.com
一旦 DNS 记录生效并验证成功，返回到 Certbot 命令窗口并按下回车键继续。Certbot 会自动完成验证并生成 SSL 证书文件。

找到生成的证书文件

验证成功后，Certbot 会将证书文件存放在 /etc/letsencrypt/live/api.moon.com/ 目录下，包括以下文件：

fullchain.pem：完整的证书链
privkey.pem：私钥文件

将证书文件复制到目标服务器

使用 scp 或其他工具将生成的证书文件复制到目标服务器，比如：

1 2	scp /etc/letsencrypt/live/api.moon.com/fullchain.pem user@target_server:/path/to/nginx/ssl/ scp /etc/letsencrypt/live/api.moon.com/privkey.pem user@target_server:/path/to/nginx/ssl/

在目标服务器上配置 Nginx 使用证书

在目标服务器上，编辑 Nginx 配置文件以使用新的证书：

server {
    listen 443 ssl;
    server_name api.moon.com;

    ssl_certificate /path/to/nginx/ssl/fullchain.pem;
    ssl_certificate_key /path/to/nginx/ssl/privkey.pem;

    # 其他 Nginx 配置
}

保存文件并重新加载 Nginx 配置：

1	sudo nginx -s reload

注意更新证书

Let’s Encrypt 证书的有效期为 90 天。之后，可以在原服务器上再次申请新的证书，然后将新的证书文件传输到目标服务器进行更新。

本地操作实例

[root@VM-0-3-centos ssls]# sudo certbot certonly --manual --preferred-challenges dns -d 008ct.top
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Requesting a certificate for 008ct.top
Performing the following challenges:
dns-01 challenge for 008ct.top

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.008ct.top with the following value:

UYYkUEGZRuWX-2OfS2PcVwll7nmJurxjfqKhkRSxO9k

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Cleaning up challenges
Subscribe to the EFF mailing list (email: 347070901@qq.com).
Starting new HTTPS connection (1): supporters.eff.org

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/008ct.top/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/008ct.top/privkey.pem
   Your certificate will expire on 2025-02-04. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

[root@VM-0-3-centos ssls]#

总结

Let’s Encrypt 是一个提供免费 SSL/TLS 证书的认证机构（CA），旨在通过简化证书申请和安装过程来普及 HTTPS 加密，提升互联网安全性
同类型的机构还有 ZeroSSL、SSL For Free、Cloudflare、BuyPass 等等，腾讯云和AWS也有针对自己产品的SSL免费证书
使用Let’s Encrypt申请SSL证书非常简单，可以选择 DNS-01 验证或者 HTTP-01 验证
如果证书用于本机的 Nginx 或者 Apache，还可以设置自动更新，这样就免除了服务有可能中断的麻烦
生成证书的命令 sudo certbot certonly --manual --preferred-challenges dns -d api.xxx.com

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

无人扶我青云志，我自踏雪至山巅。单靠自己很难，单靠自己成功更难~
2024-11-6 19:21:14

若Git子模块的远端地址发生了变化本地应该怎么调整

2024-11-05T16:15:00.000Z

前言

这个问题复杂在既有Git又有子模块，本身Git的门槛就稍微高一点，再加上子模块的运用，一旦出现这种远端地址发生修改的情况会让人有些懵，不知道怎么处理，通常会乱改一通，有时候好使有时候不好使，并不清楚其中的缘由，退一步讲，如果是一个单一的Git库，如果远端地址发生了变化，使用 git remote set-url origin git@new_xxx 命令就可以就行修改，但是这个命令在子模块情况下行不通，为了说明子模块影响哪些配置文件，接下来会简单罗列下git子模块相关命令。

git submodule 相关命令

向一个项目中添加子模块：

1	git submodule add git@github.com:zzz/xxx.git xxx

执行之后会 clone 该子模块对应的远程项目文件到本地父项目目录下的同名文件夹中（./xxx/），父项目下也会多一个叫 .gitmodules 的文件，其内容大致如下：

1
2
3

[submodule "xxx"]
    path = xxx
    url = git@github.com:zzz/xxx.git

同时父项目下的 .git 目录中也会新增 modules/xxx/ 目录，里面的内容对应子模块仓库中原有的 .git 目录中的文件，此时虽然子模块目录下的 .git 依然存在，但是已经从一个文件夹变成了文件，内容如下：

1	gitdir: ../.git/modules/xxx

即指向了父项目的 .git/modules/xxx 目录，如果运行 git config --list 查看项目的配置选项，会发现多了类似下面两行的内容：

1 2	submodule.xxx.url=git@github.com:zzz/xxx.git submodule.xxx.active=true

如果修改 submodule.xxx.url 的值，则会覆盖 .gitmodules 文件中对应的 url 值；

这其实是主（父）工程 .git/config 文件中的内容，而在主工程的 .git/modules/xxx/config 文件中会有下面这些内容：

1
2
3

[remote "origin"]
    url = git@github.com:zzz/xxx.git
    fetch = +refs/heads/*:refs/remotes/origin/*

总结来说子模块的远端地址出现在三个文件中 .gitmodules、.git/config 和 .git/modules/xxx/config 记住这些地方，我们后续会用到，这就是让人迷惑的地方。

接下来按照以下命令查看当前项目下的子模块：

1	git submodule status

结果格式为:

1	b01bf0c72235aba2e92e5c5f5173dd4cae9b374c xxx (heads/master)

如果将父项目推送到远程仓库（如gitlab），在网页浏览该项目时子模块所在的目录会多一个类似 @b01bf0c 的后缀，即上面查看子模块命令输出内容的 hash 值的前面部分，点击这个目录会跳转到这个子模块对应的仓库地址。

如果执行以下删除了子模块的命令：

1	git submodule deinit

再次查看时输出会是这样的：

1	-b01bf0c72235aba2e92e5c5f5173dd4cae9b374c xxx

在取消初始化子模块后，子模块目录会变为空目录，避免该子模块的文件继续占用空间。

解决方案

聊了这么多，总要给出一个解决方案：

修改主工程下 .gitmodules 文件内的远端地址 url = git@newdomain.com:zzz/xxx.git，然后执行 git submodule sync 命令即可完成

这样操作之后 .git/config 和 .git/modules/xxx/config 文件中的远端的地址会一起被修改掉。

多说一点：

在执行 git submodule init 或 git submodule sync 命令时，Git 会将 .gitmodules 中的配置同步到 .git/config 中，以确保 .git/config 的信息是最新的。

而在执行 git submodule update 进行更新时，Git 主要使用 .git/config 中的子模块配置来操作子模块。

当进入子模块目录操作git时，Git使用的是 .git/modules/xxx/config 中的远端地址来进行更新和推送

怎么保存子模块的版本呢

了解了子模块的机制，我们知道主工程只是保存了一个子模块工程的版本号，但是前面看了这么多配置文件，里面只有子模块的本地路径和远端地址，没有看到版本号啊？接下来我们找一下：

首先查看最新的提交commit，得到 5c997695ed383ea52879a17f0ef6944bf99d374f

$ git log -1
commit 5c997695ed383ea52879a17f0ef6944bf99d374f (HEAD -> dev, origin/dev)
Author: demo 
Date:   Mon Nov 4 11:42:25 2024 +0800

    update cmake file

利用 cat-file -p 命令查看指定 commit id的仓库状态

$ git cat-file -p 5c997695ed383
tree 8499d7cb5c4811918bfc1341bb869d8bb38c40ef
parent b287b7783e1d44a6149de132142b88bf92b95bb3
author demo  1730691745 +0800
committer demo  1730691745 +0800

update cmake file

从结果中可以看出提交人的信息，父提交id b287b7783e1d44a6149de132142b88bf92b95bb3，以及一棵树tree 8499d7cb5c4811918bfc1341bb869d8bb38c40ef，怎么理解这棵树呢？其实可以类比文件系统中的文件夹，每一个commit id实际上对应着项目文件夹的版本，其中包含子文件夹版本和各个文件的版本，那么tree 8499d7cb5c4811918bfc1341bb869d8bb38c40ef 可以认为是项目文件夹内所有内容的Hash

接下来再利用 cat-file -p 命令来看看这棵tree 8499d7cb5c4811918bfc1341bb869d8bb38c40ef

$ git cat-file -p 8499d7cb5c4811918bfc1341bb869d8bb38c40ef
100644 blob 344bc6e4d42e8fbae98a8d808b177b6773f88d31    .gitattributes
100644 blob c634b5c2da75f0eed128c701530afa5b2b799c69    .gitignore
100644 blob ba0ab2fd274f219c0e007177ad861f77a57581b0    .gitmodules
040000 tree 90317b8c9672803678037d9f006ea6818d90210b    .vscode
040000 tree 0706cb16e4c162b194680972ab7605654a1541a1    cmake
160000 commit cec7534dcb171d38d46ba47217694261ad4c7b15  xxx
040000 tree 2c693865de8c02cd87f28fe85ba5e57a73617029    src

这里边有3类内容，分别是 blob、tree、commit，blob就是具体的文件，tree就是代表一个文件夹，而 xxx 的类型是一个commit，从上文我们知道 xxx 是包含了另一个项目的文件夹，如果是一个单纯的文件夹这里的类型应该是tree，但是因为是子模块，所以类型是记录另一个项目commit id，这样我们就找到了主工程引用子模块的版本存储的位置了。

总结

添加子模块的命令 git submodule add git@github.com:zzz/xxx.git xxx
初始子模块 git submodule init，查看子模块 git submodule status
注销子模块 git submodule deinit xxx，注销后文件夹清空，但是配置文件需要手动删除
子模块远端地址发生变化，手动修改 .gitmodules 文件中地址，然后执行 git submodule sync 再提交修改

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

放下助人情节，尊重他人命运，可怜之人必有可恨之处，子非鱼，安知鱼之经历与内心~
2024-11-5 19:49:42

Gitlab新建用户无法收到邮件的问题解决办法

2024-11-04T17:00:00.000Z

前言

这个问题网上解决的帖子很多，根本原因就是配置错误，修改好配置就可以了，我也没有其他的更加新奇的解决办法，之所以再总结一遍只是为了自己统一查找方便，同时把一些差异点记录一下，因为版本和运行环境的不同，可能跟网上的解决方案有一点点差异，先写答案再聊不同吧。

解决方案

开启企业微信邮箱（QQ邮箱、163邮箱亦可）的POP3/SMTP服务，获取授权码
修改gitlab的配置文件 /etc/gitlab/gitlab.rb 如下

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.exmail.qq.com"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "gitlab@gameup.com"
gitlab_rails['smtp_password'] = "授权码"
gitlab_rails['smtp_domain'] = "exmail.qq.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = false
gitlab_rails['smtp_tls'] = true

gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = 'gitlab@gameup.com'
gitlab_rails['gitlab_email_display_name'] = 'Gitlab'

重新加载配置生效 gitlab-ctl reconfigure，等待执行完成
利用gitlab测试配置是否成功
- 执行 gitlab-rails console进入控制台，我的机器性能较差，多等一会看到命令提示符
- 输入后面面的命令 Notify.test_email('收件人邮箱', '邮件标题', '正文').deliver_now 发送一封测试邮件
- 若成功过则收到测试邮件，失败则会在控制台显示错误消息，根据错误信息检查和修改配置即可

遇到的错误

我修改配置的旅程也不是一帆风顺的，期间也遇到的了几个错误，都是在 Notify.test_email 测试之后发现有问题，逐步修改的

域名解析问题

Notify.test_email('shz@gamegu.com', 'Test Email', 'This is a test email from GitLab').deliver_now
--------------------------------------------------------------------------------
 Ruby:         ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x86_64-linux]
 GitLab:       17.5.1 (e8dca573167) FOSS
 GitLab Shell: 14.39.0
 PostgreSQL:   14.11
------------------------------------------------------------[ booted in 61.07s ]
Loading production environment (Rails 7.0.8.4)
Delivered mail 67248a5c847e9_6f32fe445660@gitlab.gamegu.com.mail (20023.7ms)
/opt/gitlab/embedded/lib/ruby/3.2.0/socket.rb:231:in getaddrinfo': getaddrinfo: Temporary failure in name resolution (SocketError)
        from /opt/gitlab/embedded/lib/ruby/3.2.0/socket.rb:231:in foreach'
        from /opt/gitlab/embedded/lib/ruby/3.2.0/socket.rb:635:in tcp'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:643:in tcp_socket'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:656:in do_start'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:611:in start'
        from /opt/gitlab/embedded/service/gitlab-rails/config/initializers/mail_starttls_patch.rb:53:in start_smtp_session'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:2145:in do_delivery'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:253:in block in deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:588:in block in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in block in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications/instrumenter.rb:24:in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:586:in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:253:in deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/actionmailer-7.0.8.4/lib/action_mailer/message_delivery.rb:119:in block in deliver_now'
        ... 15 levels...
irb(main):002:0>

解决办法

修改 /etc/resolv.conf 来指定自己服务器的DNS，通用的可以使用 nameserver 8.8.8.8

邮箱认证问题

/opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:1076:in check_response': 501 mail from address must be same as authorization user (Net::SMTPSyntaxError)
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:1044:in getok'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:945:in mailfrom'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:767:in send_message'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp_connection.rb:53:in deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:101:in block in deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:612:in start'
        from /opt/gitlab/embedded/service/gitlab-rails/config/initializers/mail_starttls_patch.rb:53:in start_smtp_session'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:2145:in do_delivery'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:253:in block in deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:588:in block in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in block in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications/instrumenter.rb:24:in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:586:in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.2.0/gems/mail-2.8.1/lib/mail/message.rb:253:in deliver'
        ... 16 levels...

解决方案

smtp 配置中应该填写正确的邮箱和授权码，同时 /etc/gitlab/gitlab.rb 中设置 gitlab_rails['gitlab_email_from'] 与 gitlab_rails['smtp_user_name'] 一致

端口配置互斥

1	gitlab_rails['smtp_tls'] and gitlab_rails['smtp_enable_starttls_auto'] are mutually exclusive. Set one of them to false. SMTP providers usually use port 465 for TLS and port 587 for STARTTLS.

解决方案

这个错误表明在 GitLab 的配置文件中同时启用了 smtp_tls 和 smtp_enable_starttls_auto 选项，但它们是互斥的，只能选择其中一个设置为 true，如果使用 TLS（通常是端口 465）仅将 smtp_tls 选项设置为 true，如果使用 STARTTLS（通常是端口 587）只能将 smtp_enable_starttls_auto 设置为true。

关于gitlab的参数，有一个external_url 表示gitlab的访问域名，可以配置为 external_url 'http://gitlab.gameup.com'，而这个域名也可以在定义容器时通过 --hostname 指定

运行环境

我的Gitlab不是在服务器上直接安装的，而是通过Docker安装的gitlab镜像，服务器是CentOS7系统，gitlab组件相关版本如下：

Components
GitLab v17.5.1
GitLab Shell 14.39.0
GitLab Workhorse v17.5.1
GitLab API v4
GitLab KAS 17.5.1
Ruby 3.2.5p208
Rails 7.0.8.4
PostgreSQL (main) 14.11
PostgreSQL (ci) 14.11
Redis 7.0.15

正因为我是通过Dokcer安装的，所以上面的很多命令需要到容器中执行，也就是得先执行 docker exec -it gitlab /bin/bash

而通过Docker安装gitlab的命令也列举一下：

docker run --detach \
  --hostname gitlab.gameup.com \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume /export/docker/gitlab/config:/etc/gitlab \
  --volume /export/docker/gitlab/logs:/var/log/gitlab \
  --volume /export/docker/gitlab/data:/var/opt/gitlab \
  registry.cn-hangzhou.aliyuncs.com/z5z/gitlab-ce:latest

不要问我这个镜像名字为什么这样古怪，那么因为DockerHub镜像在当前的网络环境下实在难以下载，不得不借助Github的Actions和阿里云的镜像完成中转，可以利用这个开源项目进行中转

docker安装

上面说了镜像难装，实际上现在连Docker的安装也需要费点劲，我曾经在AWS上安装过一些Docker镜像，那丝滑的程度真的跟教科书写的一模一样，但是在我目前所处的网络注定要一波三折了，CentOS7的系统可以按照下面的步骤操作了。

# 备份源
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
# yum使用阿里云
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
sudo yum makecache

# 安装必要的一些系统工具
sudo yum install -y wget yum-utils device-mapper-persistent-data lvm2
# 添加软件源信息
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
# 修改源
sudo sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo

# 更新并安装Docker-CE
sudo yum makecache fast
sudo yum -y install docker-ce
# 开启Docker服务
sudo systemctl start docker

总结

gitlab的配置文件为 /etc/gitlab/gitlab.rb，发邮件需要配置 smtp 和 email 参数
smtp_tls 和 smtp_enable_starttls_auto 选项是互斥的，只能选择其中一个设置为 true
进入到docker镜像内部的命令为 docker exec -it gitlab /bin/bash

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

他时若遂凌云志，敢笑黄巢不丈夫。伟人可以被人们敬仰，也可以被用来作为登天的阶梯，借他人之成就，抒发自己之情怀~
2024-11-4 20:34:11

整个互联网发展de云里雾里

2024-11-01T15:45:00.000Z

背景

本来被腾讯云的配置调整折腾两天了，一个实例在不同的界面有不同的价格，调整配置前后我都弄不清到底便宜了多少，有些区域因老架构缺货不得不选择低配的新架构，结果费用反而上涨了，比如本来想把S2 32核 128G内存的机器降低的到 24核96G内存，但S2高内存实例已经下架了，只能使用选择S5，好家伙！新的 S5.6XLARGE96 比目前用的 S2.8XLARGE128 还贵，配置降了1/3，价格反而上去了，真是“降本”降了个寂寞。

各种云层出不穷

平时主要就用阿里云和腾讯云，很早之前用过一阵儿华为云，今天在搜腾讯云的解决方案时弹出个京东云的广告，还挺新鲜的，像天翼云、联通云这些虽然没用过，不过广告看的不少，但京东云这个确实是第一次听说，好奇心促使我搜了一下发现中国互联网，甚至物联网已经被“云”统治了。

国内云

目前中国的云服务器市场发展迅速，主要的云服务器提供商包括一些大型互联网企业和专注于云服务的公司。以下是国内主要的云服务器提供商列表：

阿里云：中国市场占有率最高的云服务商，提供全面的云计算服务，包括弹性计算、存储、大数据、人工智能等。
腾讯云：腾讯旗下的云计算平台，覆盖广泛的互联网场景，适合游戏、社交、视频、电商等领域。
华为云：华为推出的云服务平台，擅长于5G、人工智能、物联网和企业级解决方案，广泛应用于政企和大型制造业客户。
京东云：京东旗下的云服务品牌，专注于电商、物流和供应链解决方案，同时提供大数据和人工智能服务。
百度智能云：百度的云服务品牌，以人工智能和大数据分析见长，适用于智能客服、自动驾驶、深度学习等AI场景。
金山云：金山软件旗下的云计算品牌，广泛服务于互联网、游戏、视频等行业，提供计算、存储和网络加速服务。
中国电信天翼云：中国电信的云服务品牌，具有较强的政企客户基础，在基础设施和专属线路服务上具有优势。
中国联通沃云：中国联通的云计算品牌，提供云计算、边缘计算、物联网解决方案，在通信行业有较多应用。
中国移动云（移动云）：中国移动的云计算平台，结合5G和物联网服务，在智能城市、物联网等场景有较多应用。
UCloud：主要面向中小企业的独立云服务商，提供计算、存储和安全服务，较多应用于移动互联网、游戏和教育等行业。
青云QingCloud：以IaaS起家，逐步向PaaS和SaaS拓展，专注于企业级客户，提供多云管理平台和私有云方案。
七牛云：起初以对象存储和CDN见长，现在扩展至人工智能、数据处理和多媒体领域。
灵雀云（Alauda）：专注于容器云和Kubernetes，主要面向企业提供云原生解决方案。
浪潮云：浪潮集团的云计算品牌，主要提供政企客户和行业解决方案，尤其在政务和企业数字化转型方面有较多案例。
用友云：专注于企业管理软件的云服务商，提供财务、供应链、人力资源等企业服务云。
富通云腾：主要提供私有云、混合云服务，专注于金融、教育、医疗等行业的云解决方案。
紫光云：紫光集团旗下云服务平台，面向智慧城市、工业互联网等领域，擅长政企数字化解决方案。
晓通云：专注于为中小企业和政企客户提供公有云和私有云服务，涉及政务、教育和医疗等领域。

还好还好，只有6个公司没听过，都是一些技术公司，感觉是把自己没用完的服务器放云上了。

国际云

以下是国际上主要的云服务商，提供的服务范围广泛，涵盖计算、存储、网络、安全、人工智能、大数据等各个领域：

Amazon Web Services (AWS)：亚马逊旗下的云服务平台，也是全球市场占有率最高的云提供商之一。AWS 提供广泛的服务，包括计算、存储、数据库、机器学习等，应用于从小型初创公司到大型企业的各种业务需求。
Microsoft Azure：微软的云计算平台，提供包括计算、存储、网络和开发工具在内的广泛服务。Azure 对于 Windows 和企业应用有强大支持，适合与微软产品（如 Office 365、Dynamics 365）集成，企业级用户众多。
Google Cloud Platform (GCP)：谷歌的云服务平台，以数据分析、机器学习和人工智能服务见长，提供计算、存储、数据库、机器学习和物联网服务，适合大数据和 AI 场景。
IBM Cloud：IBM 的云服务平台，提供混合云和 AI 解决方案，擅长于企业级应用、金融和政府领域，特别在混合云和多云架构上具有优势。
Oracle Cloud：Oracle 的云平台，主要面向数据库、ERP系统和企业应用，广泛应用于金融、零售、制造等领域，提供强大的数据库即服务 (DBaaS) 和企业 SaaS 应用。
Alibaba Cloud (阿里云)：阿里巴巴集团旗下的云计算品牌，也是全球市场的主要云服务商之一。阿里云在电子商务和零售领域有显著优势，提供全球化的服务和解决方案。
Salesforce (Salesforce Cloud)：专注于客户关系管理 (CRM) 的云服务商，主要提供 SaaS 层服务，包括营销、销售、服务等云，广泛应用于各类企业的客户管理和数字营销。
Tencent Cloud (腾讯云)：腾讯旗下的云计算品牌，广泛应用于互联网、游戏、社交媒体等行业，在亚洲市场，尤其是中国市场有较大影响力。
SAP Cloud Platform：SAP 提供的云服务平台，擅长企业应用和ERP管理系统，面向制造业、零售业、金融业等企业级客户。
DigitalOcean：专注于开发者友好的云计算平台，提供简单易用的虚拟机和 Kubernetes 服务，广泛应用于中小企业和初创公司的云服务需求。
Rackspace Technology：提供多云和混合云服务，广泛应用于中小型企业，特别是在托管和技术支持上具有丰富的经验。
OVHcloud：欧洲的云计算公司，以物理服务器、虚拟服务器、存储和托管服务为主，提供面向欧洲客户的本地化服务。
Huawei Cloud (华为云)：华为的云服务平台，除了在中国市场有重要影响力，还在全球范围内提供基础设施和企业级云解决方案。
Linode：主打开发者友好型的云计算服务，专注于提供简单、高效的云服务器和存储服务，适合中小企业和个人开发者。
Vultr：提供全球范围内的云计算服务，以高性价比和分布广泛的数据中心而闻名，特别适合小型项目和个人开发者。
NTT Communications Cloud：日本电信巨头 NTT 提供的云服务，主要面向企业级客户，广泛应用于日本及亚洲市场。
Heroku (Salesforce旗下)：专注于开发者的 PaaS 平台，提供应用托管和部署服务，支持多种编程语言，广泛应用于开发和测试环境。

一看一个不吱声，前面的几个国际大企业还有耳闻，自己家的云也有接触，其他的大多数就不太了解了。

使用体验

关于体验方面，因为很多功能我还没有用到，所以现在只是简单的谈一谈，总的来说几家大的云服务商，功能很全面，比如腾讯云、阿里云、AWS、GCP等，从其中一家迁移到另一家时总可以找到对应的服务，名字可能不一样，但东西都是类似的。

比如我们常说的云服务器，在阿里云叫 ECS（Elastic Compute Service)，在腾讯云叫 CVM（Cloud Virtual Machine），在AWS叫 EC2（Elastic Compute Cloud），在GCP叫 GCE（Google Compute Engine），在Azure上叫 Azure VM（Azure Virtual Machines），名字千变万化，但内容万变不离其宗。

其他的服务诸如CDN、OSS、静态IP、RDS等也都是类似的情况，所以你在切换云服务时基本不用担心找不到平替的服务，只是用起来的步骤可能会有些差异，稍微适应一些就好。

其中有个点对我影响挺大的，那就是各家运营商对于服务器的的监控，也就是CPU、内存、硬盘等硬件的使用曲线，体验了这么多家的云服务我觉得做的最好的是腾讯云。

如果非得要排个序的话大概是这样：腾讯云 > GCP > AWS >= 阿里云，为什么这么排，我简单聊下

腾讯云能查看6个月的历史记录，CPU、内存、硬盘、网络这些默认都可以查看，而且还可以指定和历史哪段时间进行对比
GCP默认能查看CPU和网络情况，安装Ops Agent后能查看内存和硬盘信息，并且历史查看时间比腾讯云还要长，我查看过超过半年的
AWS默认开启基本监控，可以查看CPU和网络使用情况，最长可以查看超过1年，想要查看更多信息需要开启消息监控，配合 CloudWatch 可能产生一些费用
阿里云默认可以查看CPU、内存、硬盘、网络这些信息，但是显示的友好性比不过腾讯云，最长只能查看一个月的

再有一点就是费用的查询上，也就是详细账单的查看，腾讯云相比阿里云也略胜一筹吧，阿里云查看实例费用时不显示标签，只能看实例ID阅读不友好，AWS的费用查看比较笼统，只有服务项的费用，没有对应到实例

总结

互联网时代，云服务百花齐放，AWS、腾讯云、阿里云、GCP、Microsoft Azure蓬勃发展
各家服务可以平替，ECS vs CVM vs EC2 vs Compute Engine vs Azure VM
虽然各家的服务长得很像，但是也各有所长，在服务器监控方面首推腾讯云

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

唯有病痛带来的生理痛苦是真实的，其他的痛苦全部都是由你的价值观决定的。忠、孝、礼、义、廉、耻，悔、悟是否重要，完全在于你怎么看它~
2024-11-1 17:22:48

SVN克隆或更新遇到Error: Checksum mismatch for xxx

2024-10-29T15:45:00.000Z

前言

TortoiseSVN 作为版本控制常用的工具，有一个更为人们熟知的名字 SVN，客观的讲SVN的门槛相比Git而言还是低一些的，用来存储一些文件并保留历史记录比较方便，但使用SVN还是会经常需要这样那样的问题，特别是当仓库很大的时候，提示的问题往往让初学者、甚至是经常使用的人一脸懵，比如这个 Checksum mismatch for 问题，通常SVN问题都有一个终极解法，那就是重新克隆一份再操作，这就像大多数的电脑问题重启后就能解决一样，不过偶尔有一些情景不适合采用重新克隆的解法，我们就得想一个更精确的办法去解决了。

问题的产生

在克隆一个300多G的库时，报了下面这个错误，总结来说这个错误表述的就是“心有所求而不得”，期望得到一个md5是 2c448c9f40b0dd561539b80ec3cfcaa2 的 bundle_103_cp_delafere_e_buff_wuqi.ab文件，但是下载后的文件计算md5得到的是 a2e41ec2779a23d88b31e4237ad43ceb，并不是自己想要的，提示如下：

Error: Checksum mismatch for
Error:  'E:\gameproject\prefabs\bundle_103_cp_delafere_e_buff_wuqi.ab':
Error:
Error:    expected:  2c448c9f40b0dd561539b80ec3cfcaa2
Error:      actual:  a2e41ec2779a23d88b31e4237ad43ceb

探索解决方案

先说说网上一些常见的解决办法：

删除了整个库，重新克隆下载，这个方法99%可行，但是整个库太大了，我不想重新下载
Clean up 之后继续更新，我试过了不行
先在出错的文件夹下执行 svn update --set-depth empty 删除文件夹下所有文件，再执行 svn update --set-depth infinity 更新，这是流传的最广的解决办法，在我这不行
先在 Update to revision... 中选择 Update Depth 为 Only this item 更新，然后再选择 Fully recursive 更新，原理上和上一步类似，在我这也不行

其实仔细分析这几种解决方案的本质，都是把错误的文件删除掉再重新更新，但是为什么不起作用呢？

从我最终解决问题的方法来看是，针对我遇到的问题，上面提到的一些方法并没有将错误的文件成功删除，简单分析下svn克隆和更新的过程，很可能不准确，但是我不在此处不深究，暂时还用不到这一块。

我们在传输文件时为了保证文件的完整性，经常会用一些摘要算法比如md5、sha1等来计算文件摘要，通过比较文件摘要来判断文件传输是否完整，而SVN这个工具每时每刻都在上传下载传输文件，所以也用到了摘要比对的技术。

以较新的SVN版本为例，是将sha1和md5存到了.svn/wc.db中（太老的版本md5是存储到文件中的），下载时先更新 wc.db，然后将原始文件的元文件下载到 .svn/pristine 文件夹中，然后比较这些文件的md5值与 wc.db 记录的md5值是否一致，如果一样就从元文件中提取出真正的文件放到库中，这个文件就算下载完了，如果不一致就会报出上面的错误。

分析过后我们只要找到错误的元文件，删除后重新下载就解决了。

正式的解决方法

首先打开从 .svn/wc.db 中查找的元文件的名字，可以使用你熟悉的工具，我用的是 SQLiteSpy.exe有图形界面方便一下，最基础的也可以用 sqlite3.exe 这种命令行的工具，执行以下sql语句：

1	select * from NODES where local_relpath = 'prefabs/bundle_103_cp_delafere_e_buff_wuqi.ab'

执行过后可以查到checksum列的值为 $sha1$f9fd60e244a004cc30fcc83e8e59e7466b3dca6a，这就是元文件的名字，也可以通过下面的语句查到md5值

1	select * from PRISTINE where checksum = '$sha1$f9fd60e244a004cc30fcc83e8e59e7466b3dca6a';

结果中md5_checksum列的值为 $md5$2c448c9f40b0dd561539b80ec3cfcaa2 就是报错中提到的那个期望值了。

接下来进入 .svn/pristine/f9 文件夹，删除 f9fd60e244a004cc30fcc83e8e59e7466b3dca6a.svn-base 文件，然后在仓库根目录更新就正常了

背后的故事

问题解决了，那么产生的这种问题的原因是什么呢？为什么会md5值不一致呢？我们知道文件的md5值是根据文件内容计算出来的，下载后的文件md5不是预期的值说明文件内容发生了变化。

我用比较工具对比了正常的文件和出错的文件发现，两个大小都为29949字节的文件，其中有一个字节发生了偏差，正确的文件该字节值为 2F，而错误的文件对应值为 2E，就弄错了这一个字节，导致SVN的文件比对报错了。

这一个字节差异产生的原因，可能有很多种，比如传输过程中数据损坏、压缩或加密问题、数据损坏或硬盘问题，我这里大概率是因为下载时机器重启的原因。

这让我想起了7、8年前下载游戏服务器包无法启动的问题，当时下载完启动各种异常，比较文件大小也是一样的，但是计算md5后发现不同，应该也是传输过程中发生了错误。

总结

SVN遇到的问题有90%都可以通过完整删除后重新克隆下载的方式解决
老版本的文件checksum值存储到 .svn/entries 文件中，较新版本的文件将这些值存储在 .svn/wc.db 中
通过 select * from NODES where local_relpath = 'xxx' 方式可以从 .svn/wc.db 中查到文件的 sha1值
在 svn/pristine 中找到 $sha1$.svn-base 删除即可重新下载了

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

待到秋来九月八，我花开后百花杀。有些句子在经历了一些事以后，自然而然就有了新的理解，这与儿时死记硬背下来的赏析是完全不同的~
2024-10-29 10:08:10

Redis内存碎片自动回收

2024-10-24T13:06:19.000Z

前言

今天说的是一个老问题了，关于 Redis 内存碎片的回收，以前用过几次，今天再次使用时发现自己没总结，没有可以拿来直接用的命令，花了一些时间去查找和测试，为了以后使用时更方便，我决定把整理一下放在这，等待再次相遇。

预制命令

查询内存情况

[root@server ~]# redis-cli -a "password" info memory
# Memory
used_memory:48320108840
used_memory_human:45.00G
used_memory_rss:56677724160
used_memory_rss_human:52.79G
used_memory_peak:57105514920
used_memory_peak_human:53.18G
used_memory_peak_perc:84.62%
used_memory_overhead:71864532
used_memory_startup:786616
used_memory_dataset:48248244308
used_memory_dataset_perc:99.85%
total_system_memory:135025369088
total_system_memory_human:125.75G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.17
mem_allocator:jemalloc-4.0.3
active_defrag_running:0
lazyfree_pending_objects:0

查询是否开启了自动清理碎片

1
2
3

[root@server ~]# redis-cli -a "password" config get activedefrag
1) "activedefrag"
2) "no"

开启碎片自动清理

1 2	[root@server ~]# redis-cli -a "password" config set activedefrag yes OK

关闭碎片自动清理

1 2	[root@server ~]# redis-cli -a "password" config set activedefrag no OK

聊聊背后的东西

上面已经把命令都烹饪好了，接下来可以聊聊背后的东西。

先学个单词 defrag /dɪˈfræɡ/，“整理磁盘碎片”的意思，后面的内容大部分都和这个单词有关。

Redis 的数据都存储在内存中，当我们的应用程序频繁修改 Redis 中的数据，特别是删除大量的Key时，就有可能会导致 Redis 产生内存碎片，或者是一些内存剩余，其实Redis删除Key之后使用的内存肯定少了，但是它不一定会释放出来，有时也算是一种预先分配的机制，就比如他的数据只有1个G，但是有可能申请1.2个G的空间，这样在添加新的key时，通常立马就可以使用，不必再去申请新的内存了。

过多的内存碎片会降低 Redis 的内存使用率，通过Redis 的 info memory 命令，查到内存使用率 mem_fragmentation_ratio:1.17，这个值的计算比较简单：

mem_fragmentation_ratio = used_memory_rss / used_memory

其中 used_memory 表示 Redis 存储数据的内存大小，used_memory_rss 表示操作系统实际分配给 Redis 进程的内存大小。

Redis 从 4.0 版本开始，提供了自动碎片整理的功能，可以通过配置开启碎片自动整理，也可以

如果你使用的是 Redis 4.0 以下版本，只能通过重启实例来解决
如果你使用的是 Redis 4.0 版本，它正好提供了自动碎片整理的功能，可以通过配置开启碎片自动整理，开启内存碎片整理必然会占用服务器的计算资源，这可能会导致 Redis 性能下降。所以是否开启这个功能，最好提前测试评估

究其原因，Redis 的碎片整理工作也是在主线程中执行的，当其进行碎片整理时，肯定会会消耗 CPU 计算资源，产生更多的耗时，从而可能影响到客户端的请求。

Redis 碎片整理的参数配置如下：

# 开启自动内存碎片整理（总开关）
activedefrag no
# 内存使用 100MB 以下，不进行碎片整理
active-defrag-ignore-bytes 100mb
# 内存碎片率超过 10%，开始碎片整理
active-defrag-threshold-lower 10
# 内存碎片率超过 100%，尽最大努力碎片整理
active-defrag-threshold-upper 100
# 内存碎片整理占用 CPU 资源最小百分比
active-defrag-cycle-min 1
# 内存碎片整理占用 CPU 资源最大百分比
active-defrag-cycle-max 25

本机查询情况如下：

[root@server ~]# redis-cli -a "password" config get activedefrag
1) "activedefrag"
2) "yes"
[root@server ~]# redis-cli -a "password" config get active-defrag-ignore-bytes
1) "active-defrag-ignore-bytes"
2) "104857600"
[root@server ~]# redis-cli -a "password" config get active-defrag-threshold-lower
1) "active-defrag-threshold-lower"
2) "10"
[root@server ~]# redis-cli -a "password" config get active-defrag-cycle-min
1) "active-defrag-cycle-min"
2) "25"
[root@server ~]# redis-cli -a "password" config get active-defrag-cycle-max
1) "active-defrag-cycle-max"
2) "75"
[root@server ~]# redis-cli -a "password" config get active-defrag-max-scan-fields
(empty list or set)

总结

Redis 从 4.0 版本开始，提供了自动碎片整理的功能，可以通过配置开启碎片自动整理
内存查询 info memory，查询碎片整理是否开启 config get activedefrag
开启碎片整理 config set activedefrag yes
关闭碎片整理 config set activedefrag no

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

不畏浮云遮望眼，只缘身在最高层。真的是这样吗？如果你太高了浮云遮住了你向下望的眼睛呢？太低看不到高处，而太高又看不清地处了呀~
2024-10-24 20:15:17

修复WordPress前后端分离时无法预览文章的问题

2024-10-23T17:30:00.000Z

前言

惊喜总在不经意间来临？前段时间刚刚总结了WordPress迁移遇到的问题及解决办法，费了九牛二虎之力似乎一切都走向正轨了，今天则又冒出点新花样，待发布的文章居然不能预览！这不都是常规功能吗？难道因为我迁移之后就不好使了，根据遇到的情况分析之后发现不是这样的，这个预览一直就不好使，已经过去5年了，也是有点醉了，好像到我手里就坏了一样，其实一直就不能用，5年前别人挖的坑我也要填，我就是一个填坑勇士。

问题表现

问题最直接的表现就是文章保存草稿后，点击预览按钮跳转的不是刚刚编辑的文章预览页面，而是已发布的文章列表，很明显是跳转的链接不对，从已发布的文章链接来看，这个链接格式肯定是编辑过，通过查找资料我发现可以通过 WordPress后台菜单中的 设置 -> 固定链接 来修改固定样式，查看后发现发布链接的样式已经从 https://008ct.top/?p=123 定义为 https://008ct.top/%category%/%year%/%post_id%/ 也就是在链接中增加了分类和年份信息。

再看预览链接的样式为 https://008ct.top/?p=123&preview=true 和默认样式很相似，所以我就找了半天哪里能有修改预览样式的页面，转了一圈无果，后来发现后台的地址和前台地址设置不同，地址中多了一段 cms，完整预览格式应该为 https://008ct.top/cms/?p=123&preview=true，默认打开的地址肯定是不行的，需要修改预览链接样式，朝这个方向努力后发现可以通过钩子函数来自定义预览链接。

解决问题

我们可以使用下面这个过滤钩子preview_post_link来自定义预览链接，把下面的代码放到主题文件夹里的functions.php文件中，路径类似 /cms/wp-content/themes/xxxx/functions.php

function aw_custom_preview_link() {
    return get_option('siteurl') . "/?p=" . get_the_ID() . "?preview=true";
}
add_filter('preview_post_link', 'aw_custom_preview_link');

其中 get_option('siteurl') 获取的是后台的地址，也就是 https://008ct.top/cms 这部分，如果想获取前台的地址可以使用 get_option('home')，这些都是在WordPress后台 设置 -> 常规 页面里设置的，修改过后无需重启项目，直接访问待发布的文章，预览链接就可以使用啦。

总结

WordPress的可定制性真的很强，最近接触后深有体会
WordPress可通过设置 -> 固定链接来设置文章的访问地址
WordPress可通过设置 -> 常规 来设置前台和后台的访问地址
WordPress可通过钩子preview_post_link来自定义预览链接

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

故善人者，不善人之师；不善人者，善人之资。不贵其师，不爱其资，虽智大迷，是谓要妙
2024-10-23 20:03:53

陷入产出危机的我聊聊近况

2024-10-17T17:30:00.000Z

前言

在总结文章时，我把自己当做一个内容产出者，当这样一个身份进入每天按部就班的平稳状态时会陷入一种焦虑，产生一种居然没有什么可写的感觉，如果任由这种焦虑泛滥，便会陷入一种无限内耗的状态，也不是无所事事，只是觉得做重复的工作没有看见提升就让人焦虑，性格使然。

我当然知道它的危害，所以我得找点事情来做，找点常规工作以外的事情来做，今天在依旧找不到话题的情况下，我决定写写最近一段时间的感受和经历，有些知识点之前已经总结过了，今天主要是在整体唠叨唠叨，写写最近一段时间干了点什么。

我的多重身份

作为IT网管

这是一个我在离职前就能预见到的身份，离开了之前庞大的机构，进入一个小小的初创团队，什么事情都得自己干，选网络运营商，配路由，搭建内部DNS服务器，甚至要亲自买机柜，买PDU，接网线，装系统等等等等，刚刚搭建完服务器还要盯着各个服务器的温度，功率太大导致跳闸还得呼哧呼哧搬着机器找一个合适的位置，反正网管的活我都干，能干的不能干的最后也都变成了能干的。

作为运维人员

之前需要服务器，开个防火墙类似的，找运维说一声，或者提个单子等着就行了，现在不行了，机器得自己买，防火墙得自己配，费用要自己算，一切路都得自己趟，今年之前偶尔在阿里云或腾讯云上买个服务器玩玩，最近把AWS和GCP玩的66的，唯一差一点就是 Microsoft Azure 还没有用过，暂时还没有需求吧。

这么来说吧，用了一圈我发现各家云服务器的常用功能类似，只是每个人起了不同的名字，比如 AWS中的 EC2 在腾讯云叫 CVM（Cloud Virtual Machine），在阿里云叫 ECS（Elastic Compute Service) 在GCP 叫 Compute Engine，其他的服务也是类似的情况。

最近AWS用的比较多，我就把AWS的服务列举一下：

EC2：云服务器
RDS：关系型数据库
Amazon MemoryDB：内存数据
Route 53：DNS解析
WAF & Shield：应用防火墙
CloudFront：类CDN产品
S3：对象存储服务
IAM：安全控制服务
CloudWatch：监控和管理服务

此外用到的还有：

AMI：预配置的虚拟机镜像
ALB：负载均衡服务
SSL：安全协议证书

还有一些小的概念，比如硬盘的gp2还是gp3，安全组的配置，弹性IP，在GCP中叫静态IP，密钥的创建和丢失密钥的处理方法，还有目标组，NameServer等等概念，反正搞这些东西的那段时间可把我忙坏了。

作为Web开发人员

关于这个身份，我之前想到了一点点，但是没想到这段时间此类工作占比如此之重，接手了原来完整的一个网站，而且他还是我之前都没听说过的结构框架编写的，例如Nextjs框架，React库，服务器客户端组件、Vercel部署，Supabase存储等，每一项都花了不少时间，后来又迁移了Appsmith，使用了Docker，反正是磕磕绊绊的把这些东西接过来了。

再后来又接了一个WordPress的活，把原来的项目完整迁移过来，配置本地的STMP发送邮件服务，为了测试自己又完整的搭建了一遍WorldPress网站，还跑去GoDaddy上买了个域名，Route53完成DNS解析，ALB转接流量，SSL分配证书，又完整的搞了一遍。

作为游戏开发人员

这个本应该属于我的角色，这段时间却花费时间较少，只能在前面这些工作的间隙抽空过来处理，当然线上的问题肯定优先解决，老项目也开发了几个较小的功能，同时做了一些优化和功能BUG的修复，新项目刚刚又在开发新功能了，也在梳理之前的框架，清理冗余的逻辑，精简模块的实现。

选购云服务器也是这一部分不可缺少的工作，自从来了这个小团队已经买了10来个服务器实例，用途各式各样，手法也越发熟练了。

哦对了，一开始还捣鼓了一阵儿打包的问题，把苹果各类机器和版本试了个遍，那是一段没有前半夜回家的日子。

总结

最近这4个月是近几年最匪夷所思的一段时间，仿佛什么事情都赶在一起了
这段时间游戏开发、网站开发、买服务器、装机器、接网线似乎什么都干
这段经历虽然不一定多彩，但肯定算的上多样，有些事情不经历靠书本是学不会的

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

这人生啊，又开始给我加强度了
虽然我年纪轻轻就谈人生显得有点可笑，但是每个看似深思熟虑的思考在高纬度看来同样可笑至极，蝼蚁罢了~
2024-10-17 20:30:25

AWS上迁移WordPress遭遇若干问题及处理办法

2024-09-26T17:00:00.000Z

前言

前段时间不是在迁移AWS嘛，采用了分享AMI的方式，废了九牛二虎之力，终于在没有密钥的情况下成功登录了转移后的EC2实例，那么我们肯定不单单是为了转移一个EC2实例而大费周章，实际目的还是为了里面的数据和服务，具体来说就是一套WordPress网站，对于一个新的知识和事物围绕它的有很多知识点，一旦发散的过快就发现东西太多了，什么也讲不明白，造成虎头蛇尾的现象，做技术内容输出的人经常有这种力不从心的感觉。

为了避免这种现象，我尽量保持克制，不随意发散，按着时间先后发生的主线，来说说遇到了哪些问题，又是怎么解决的，解决方案或许不完美，只是提供一种思路。

问题的产生

前文提到我已经把原来的AWS实例迁移到新的账号下了，其实繁杂的工作才刚刚起步，首先是访问IP，为了每次重启后IP地址不发生变化，我们不能采用自动分配的公共IP，而要申请弹性IP关联到对应的实例上，注意弹性IP关联到正在运行的实例上时不收费，但是如果不关联或者关联的实例不运行，则需要支付费用，大约$0.005/小时。

当然这都是小问题，真正的问题还在后面，比如域名需要转移，域名的解析需要重新配置，SSL证书要重新申请，花费时间最多的还是网站用户上报信息发送邮件功能不可用的问题，不过还好，凭借这知识积累和渊博的互联网，基本都找到了解决方案，下面逐项来介绍一下。

域名转移与DNS解析

域名转移据说在国外非常顺畅，但这次不是常用的GoDaddy，也不是上次虐我千百遍的JPDirect，是一个叫Onamae服务网站，使用这个网站最大的难点不是技术上的，而是语言层面的，全网站只有日文，凭借着我的有道词典和小伙伴的日语助攻，域名顺利转移，但是我废了九牛二虎之力也没找到原来的DNS记录配置在哪里，找不到DNS记录意味着我无法将域名解析到新的EC2。

后来想起了Vercel验证域名的经历，这个域名不会也把域名服务器改到别处了吧，一查果然是改到aws了，那必然是用了Route53啊。

Amazon Route 53 是 AWS 提供的高度可用和可扩展的云域名系统（DNS）服务，主要用于将用户访问的域名（如 example.com）映射到网络资源（如 EC2 实例、负载均衡器、S3 存储桶等）。Route 53 提供域名注册、DNS 解析、流量管理、以及健康检查等功能。

Route53 提供高度可用的 DNS 解析服务，将域名映射到 AWS 资源或其他 IP 地址，支持 A 记录（IPv4 地址）、AAAA 记录（IPv6 地址）、CNAME、MX 等常见 DNS 记录类型。支持多种路由策略，如简单路由、加权路由、基于延迟的路由、地理位置路由、故障转移路由等，帮助实现流量优化和高可用性。

每月前 25 个托管区域每个 $0.50，超过部分按 $0.10/托管区域/月收费。首 10 亿次查询为 $0.40 每百万次查询，超过部分按 $0.20 每百万次查询计费。在全球多个 AWS 区域提供服务，确保最快速的 DNS 解析速度。

总的来说就是Onamae甩锅了，有人查询DNS记录，Onamae指着AWS说你问他，我不管了，这个域名由他全权负责。

解析域名到EC2与启用SSL

现在是个网站就HTTPS，也不管是不是有隐私数据，反正我就得加上显得安全，那我们也随大流别特立独行了，去搞个SSL证书吧，虽然给官网买个好点的证书也付得起，但毕竟免费的更具性价比，在AWS上有免费的证书可用，访问ACM即可申请。

AWS Certificate Manager (ACM) 是 Amazon Web Services 提供的服务，用于轻松管理 SSL/TLS 证书，来保护网站和应用程序的网络流量。ACM 自动化了证书的申请、颁发、续订、以及配置过程，从而简化了安全管理。

ACM 支持免费申请 公有 SSL/TLS 证书，用于保护基于 HTTPS 协议的流量。支持单域名、多域名和通配符证书。可以将 ACM 证书快速部署到多个 AWS 服务上，如 Elastic Load Balancers (ELB/ALB/NLB)、CloudFront、API Gateway、和 Elastic Beanstalk。

申请时，需要验证域名的所有权，ACM 支持 DNS 验证 和 Email 验证，证书可以直接部署在 ALB、CloudFront 等 AWS 服务上，无需手动上传证书，ACM 会自动检测到即将到期的证书，并在过期前完成自动续订。ACM 是一个简化 SSL/TLS 证书管理的服务，特别适合不希望手动处理证书申请、安装和续订的用户。它与 AWS 其他服务深度集成，确保用户在 AWS 上可以轻松实现网站和应用的安全性。

看了这些介绍是不是心动了，申请步骤也非常方便，基本上填写一个域名example.com 其他参数默认就可以了，前文提到ACM需要验证域名的所有权，这一点AWS做的非常方便，之前我们已经修改Onamae购买的域名NS指向了Route53，这里可以选择DNS 验证，在申请SSL证书后会有一个按钮，将验证的DNS记录添加到Route53，一步到位非常的人性化，添加完验证DNS记录后，证书状态会显示为 等待验证，这个过程我等待了1-2小时，然后状态切换成了 已颁发，可能因为我使用新买的域名进行的测试。

进行到这遇到了一个难题，SSL给谁用？如果我在Route53中将域名解析到EC2，那么我这个SSL证书就得放到EC2上，不管是配置到Nginx、Apache，还是应用程序自己处理都比较麻烦，所以我们充分利用AWS的服务架构，申请一个ELB，将SSL证书分配到ELB上，然后Route53将域名解析到ELB，ELB收到请求后再将流量转发到EC2。

申请ALB完成转发

AWS ELB（Elastic Load Balancing）是亚马逊云服务（AWS）提供的一项负载均衡服务，主要分为ALB、NLB、CLB，旨在自动分配进入应用程序的流量，以确保高可用性和可靠性。ELB 可以帮助你管理和优化应用程序的流量，同时确保后端服务器不会因过载而失效。

ELB 能够根据流量自动扩展和缩减负载均衡能力，以适应流量的变化，支持 SSL/TLS 加密，确保数据在传输过程中安全。集成了 AWS CloudWatch，可以实时监控负载均衡器的性能和流量，并提供访问日志。支持 HTTP、HTTPS、TCP 和 WebSocket 等多种协议。

ELB分类

应用负载均衡器（ALB）：
- 最适合 HTTP 和 HTTPS 流量，能够根据请求的内容进行智能路由。
- 支持基于内容的路由、SSL 终止、WebSocket 和 HTTP/2。
- 提供更细粒度的流量控制和监控功能。
网络负载均衡器（NLB）：
- 设计用于处理 TCP 流量，能够提供极低的延迟和高吞吐量。
- 可以处理数百万个请求，并支持静态 IP 地址。
- 适合高性能、低延迟的应用场景，如游戏和实时数据处理。
经典负载均衡器（CLB）：
- 早期的负载均衡器，支持 HTTP、HTTPS 和 TCP。
- 提供基本的负载均衡功能，但不具备 ALB 和 NLB 的高级功能。
- 目前已不再推荐用于新应用，AWS 建议用户使用 ALB 或 NLB。

因为使用的是 HTTP 和 HTTPS 流量的应用程序，所以需要选择 ALB，NLB是不会解析到应用层协议的，使用ALB可以进行SSL终止，那什么是SSL终止呢？

SSL终止（SSL Termination）是在负载均衡器或代理服务器等中间设备上处理SSL/TLS加密和解密的技术。

SSL终止及优点

SSL终止指的是当客户端与服务器之间的连接使用SSL/TLS加密时，SSL连接在中间设备（如负载均衡器）上终止（解密）。之后，终止SSL加密的数据将作为未加密的数据在中间设备和后端服务器之间传输。

性能提升：后端服务器不需要处理SSL/TLS加解密工作，减轻了服务器的负担，特别是对于高流量的网站，能够提高整体的性能和响应速度。
集中管理SSL证书：SSL证书只需要在负载均衡器等设备上配置，无需在每台后端服务器上安装SSL证书，简化了证书的管理和更新流程。
简化架构：SSL终止简化了网络架构，尤其适合需要将流量分配给多台服务器的负载均衡环境。
支持多种协议：可以支持HTTP、WebSocket等不加密协议的通信形式，而客户端仍然认为其连接是安全的。

SSL终止的工作流程

客户端发起HTTPS请求。
负载均衡器或代理服务器接收请求，并在此解密SSL加密的数据。
解密后，负载均衡器将未加密的数据转发给后端服务器（通过HTTP等协议）。
服务器处理请求并将结果返回给负载均衡器。
负载均衡器将响应数据重新加密，并返回给客户端。

在创建ALB时有几个需要注意的点，面向互联网还是内部？IPv4还是双栈？网络映射到哪？安全组怎么配？侦听器和路由是什么？这些问题看着深奥，其实一点也不简单，我用大白话试着解释一下？

面向互联网还是内部，就是问给公网用户访问还是内网访问，这个就是字面意思
IPv4还是双栈，就是问只用IPv4还是需要支持IPv6，我不太懂，选了双栈，功能多总没坏处
网络映射到哪，就是选一个子网和至少两个可用区域，为了说明流量的去向
安全组怎么配，按照EC2的规则配就行了，这个就是EC2的前面的一道门，注意开启443端口的流入哈
侦听器和路由是什么，这个是个重点，就是说监听某个端口，然后将流量导入到目标组，按照我们的目的肯定是监听443，然后导向EC2实例的80啊，选择443时就可以使用前文里申请的SSL证书了

回答了上面的问题，又引出了新的问题，我选择的子网不让我选择双栈怎么办？目标组又是什么？

如果你选择的是双栈（IPv4/IPv6），确保子网有 IPv6 CIDR 块。CIDR块（Classless Inter-Domain Routing Block）是一种表示IP地址范围的方式。它用于描述一个网络及其子网的大小，并且广泛应用于现代网络，特别是在分配和管理IP地址时。如果没有就去子网里添加。

目标组就是把流量目标组到一起，定义一个目标组，目的就是精确表示流量去到的地方，我目前的需求是导向到具体的EC2，所以目标组里可以只选择一个EC2实例，其实你也可以选择多个实例去做类似负载均衡的需求

到这里ALB基本就配置完了，这时可以将这个ALB的DNS信息复制添加到Route53里，以别名的形式添加，这一套路径就走下来了

用于访问域名，交给Route53解析地址，Route53将ALB地址返回，流量以HTTPS形式到达ALB，使用证书解密出数据，数据以HTTP形式从ALB到达目标组中的EC2实例，完成一次请求，EC2不用关心证书的问题，多数一句，这样的EC2如果不直接访问可以不配置公网IP和弹性IP。

进行到这里网站跑起来了，访问也正常了，貌似问题都解决了，但旅途怎会如此顺利？接下来就将迎来业务引发的问题——发邮件不成功，经历了这次的折腾我看到了更本质的东西。

邮件发送问题

当你不熟悉一件事情的时候总会认为它很神秘，就像我之前认为邮件特别复杂、特别庞大一样，经过这次折腾之后发现它的轮廓清晰了起来，再说问题之前，我们先来看一段历史。

1987 年 9 月14 日晚上，北京车道沟十号院中一座树木掩映的小楼里，李澄炯教授等13 位中、德科学家聚拢在一台西门子7760 大型计算机周围，成功发出中国第一封电子邮件。这座小楼，就是中国兵器工业计算机应用技术研究所的所在地。

“Across the Great Wall we can reach every corner in the world”（“越过长城，走向世界”）。这是西方世界第一次通过互联网听到中国的声音。

看到Great Wall和这个句子含义总联想到另一个词，有点讽刺~

现在看来，邮件本质是数据的发送，从数据层面来看与HTTP请求并无不同，只是使用了另一种更适合它的协议，将数据传递到目的地罢了。

我很早就不觉得HTTP神秘了，为什么呢？因为整天接触它，但是我在前两天还在觉得Email神秘，因为平时用的少也没有过多研究过，这次趁着解决问题稍微拓展了一下，感觉知识面又变宽了一点点。

好了，接下来说遇到的问题，迁移的WordPress有一个提交表单发邮件的功能，使用了一个叫 MW WP WPForm 的插件，可以自动回复邮件以及向管理员发送表单邮件，但是我将WordPress迁移到新的AWS实例后，这个功能失效了

官方也给出了一些FAQ

“There was an error trying to send your message. Please try again later.” is a message that appears when an email fails to send. There are two main reasons why this message appears:
WordPress itself cannot send emails
The email body is not set on the MW WP Form form editing screen

虽然不能直接解决我的问题，但是我发现了一件事，就是这个插件本身不能发送邮件，它要求WordPress必须本身可以发送邮件才可以，怎么理解这句话呢？首先你要理解插件的作用，插件是在原项目或作品上通过加载的方式丰富完善原来的内容，本身并不能提供一些基础的能力。

因为插件一般与源系统是解耦的，所以只能通过系统提供的一些钩子或事件来改善原系统功能，就以 MW WP WPForm 这个插件为例，WordPress本身是可以利用 PHP 的 WP_Mail 发送邮件的，但是相对来说使用较复杂，需要传递很多参数，而 MW WP WPForm 就是将这些参数便利化的插件，当我收到你要发邮件的请求时由插件负责组装参数和调用函数，大大方便了邮件发送的操作。

但是如果本身调用 WP_Mail 都发不了邮件，那么这个插件也就无能为力了。

其实 WP_Mail 只是为 WordPress 提供了发送邮件的功能逻辑，并不是发邮件的基础架构，以Linux为例，与邮件相关的命令有 mail、sendmail、postfix 等，其中 mail 是一个邮件客户端，用于发送和接收邮件，可以这样使用 mail -s "Subject" user@example.com，sendmail 和 postfix 是邮件传输代理（MTA），主要用于处理邮件的发送和接收。在现代 Linux 系统中，postfix 通常被认为是比 sendmail 更好的选择，因为它更安全、易于管理且性能优越。

这些才是Linux系统发送邮件的基础结构，WordPress的 WP_Mail 函数主要依赖于 PHP 的 mail() 函数来发送邮件，而PHP 的 mail() 函数通过系统的邮件传输代理（通常是 sendmail 或 postfix）来发送邮件，确保适当的 MTA 已安装并配置正确，才能保证 PHP 可以成功发送邮件。

初步分析是这台机器邮件服务没有配置好，那就查查log吧，打开 /var/log/maillog 文件看到以下字样：

Sep 26 16:14:29 ip-192-168-2-26 postfix/smtp[9198]: connect to mx2.qq.com[240d:c040:1:40::133]:25: Network is unreachable

咦？25号端口咋不通呢？看了看安全规则也没限制25号端口，还有就是我现在的系统是直接镜像过来的，配置应该一模一样才对，为什么之前的实例可以发送邮件，而镜像过来的新实例就不行呢？

后来我又创建一个简单实例，然后搭建了WordPress，依旧发不了邮件，然后我就查了一下发现AWS-FAQ：

EC2 SMTP 端点策略的变化
问：ID 格式会发生怎样的变化？

自 2020 年 1 月 7 日起，Amazon EC2 开始推出一项变化来限制默认情况下通过端口 25 的电子邮件流量，
从而防止客户和其他收件人收到垃圾邮件和电子邮件滥用。端口 25 通常用作发送电子邮件的默认 SMTP 端口。
在过去请求并取消了端口 25 限制的 AWS 账户将不受此变化影响。

原来是AWS把新实例的25端口封锁了，之前的实例是2019年申请的没有受到影响，进一步查询，发现不只AWS这样做，阿里云也封锁了25号端口，要是申请解封会花一些时间还不一定成功，我还是想想别的办法。

解决邮件问题

既然25号端口不好用，我就用SMTP的SSL端口465吧，可是怎么改变发送的端口呢？我查到了WordPress的 WP MIAL SMTP 插件，填写qq邮箱的SMPT服务器，添加qq邮箱和授权码，就搞定了，真是太方便，设置完终于可以发邮件了，泪流满面，天知道这个过程我持续了多久，熬了多少个夜晚。

这个插件的安装我是在测试实例时搞得，正当我想要在正式实例上安装 WP MIAL SMTP 插件时，提示我WordPress版本5.2.4太低无法安装，之前安装的那个测试环境是6.2.4，天塌了呀，那没办法升级WordPress吧，找到升级按钮那么一点，开始转圈圈，然后提示我升级失败，天又塌了呀。

鬼知道我都遇到了什么，既然不让我安装 WP MIAL SMTP，那我安装个别的呗，后来找到了 Easy WP SMTP 可以在当前版本安装，整个使用过程和 WP MIAL SMTP 几乎一毛一样，看起来就像换了个主题，结果就是一样好使，事情还没完。

刚刚配置的是我的QQ邮箱，但是这里总不能把邮件都扔我邮箱吧，最终要换成企业微信邮箱，但是当我配置为公司企业微信邮箱再提交表单发邮件时，虽然邮件正常回复给QQ邮箱了，但是插件 WP MIAL SMTP 测试页面报了一个警告和错误

Domain Check Results
spf
Action Needed: It doesn’t look like the SPF record required by your SMTP server has been added to your domain. Please contact your SMTP server provider for details on how to find the SPF record, and how to add this record to your domain’s DNS.
dmarc
Action Recommended: It doesn’t look like DMARC has been set up on your domain (xxx.com). We recommend using the DMARC protocol because it helps protect your domain from >>unauthorized use. Please check out this step-by-step guide for details on how to add the DMARC record to your domain’s DNS.

其实一开始我也没当回事，查了Easy WP SMTP插件的文档，还提供了一个查询DNS信息的工具,但是我没有放在心上，不撞南墙怎会回头，后来再给Gmail发邮件的时候，邮件被退回了，错误原因写的还算清楚

无法发送到 yyy@gmail.com
退信原因    发件人（support@xxx.com）域名的DNS记录未设置或设置错误导致对方拒收此邮件。
host gmail-smtp-in.l.google.com[172.253.118.27] said: 550-5.7.26 Your email has been blocked because
the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
Authentication results:  DKIM = did not pass  SPF [xxx.com] with ip: [18.169.211.239] = did not pass
For instructions on setting up authentication,
go to  https://support.google.com/mail/answer/81126#authentication d9443c01a7336-20af16e543csi13995695ad.54 - gsmtp (in reply to end of DATA command)
解决方案    请通知你的邮箱管理员为邮箱域名设置正确的DNS(SPF、DKIM、DMARC)记录。
详细请见 http://service.exmail.qq.com/cgi-bin/help?subtype=1&&no=1000580&&id=20012。

在自己企业微信的域名上添加两行记录就可以了，这样就可以顺利的发邮件给GMail了。

主机记录：@
记录类型：TXT
记录值为：v=spf1 include:spf.mail.qq.com ~all

主机记录： _dmarc
记录类型：TXT
记录值: v=DMARC1; p=none; rua=mailto:mailauth-reports@qq.com

SPF（Sender Policy Framework） 是一种电子邮件验证协议，用于防止邮件伪造和垃圾邮件。SPF 的验证原理基于 DNS（域名系统）记录。DMARC（Domain-based Message Authentication, Reporting & Conformance） 是一种邮件身份验证协议，用于增强电子邮件的安全性，防止邮件伪造和钓鱼攻击。它建立在 SPF（Sender Policy Framework）和 DKIM（DomainKeys Identified Mail）之上，通过提供发送方的政策声明和报告机制来实现。

有关SPF和DMARC的详细原理可以自己去扩展，这里只做简单介绍了。

本来事情到这里就比较完美了，但是架不住技术人有一个爱折腾的心，我不装插件行不行呢？

原生解决邮件问题

临时测试

既然装了个插件能解决发邮件的问题，那我能不能自己搞个简单配置文件来做（貌似写代码的人有技术洁癖），说干就干，我先是在测试的WordPress上进行，版本6.2.4，ChatGPT提示我直接在主题下面的 functions.php 文件里加代码就行，路径 /wp-content/themes/你的主题名/functions.php

function configure_smtp( PHPMailer $phpmailer ) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtp.qq.com';       // 你的 SMTP 服务器
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Port       = 465;                 // SMTP 端口，465 是 SSL 的常用端口
    $phpmailer->Username   = '707070901@qq.com';  // 你的 SMTP 用户名
    $phpmailer->Password   = 'SMTPjyiqwhzlSMTP';  // 你的 SMTP 密码
    $phpmailer->SMTPSecure = 'ssl';               // 加密类型，使用 ssl
    $phpmailer->From       = '707070901@qq.com';  // 发件人地址
    $phpmailer->FromName   = 'Your Name';         // 发件人姓名
}

add_action( 'phpmailer_init', 'configure_smtp' );

一测试发邮件，网站崩溃了，最后在开头加了一句 use PHPMailer\PHPMailer\PHPMailer; 问题解决

正式修改

后来我又到正式的WordPress上修改，这次为6.2.4版本，但是这个WordPress主题是自定义的，我没找到 functions.php，ChatGPT又给我出了主意，让我自己创建一个我没听，而是采用了他说的另一种方法，使用 mu-plugins 文件夹，如果你确保这段代码始终运行（甚至在你切换主题时），可以使用 WordPress 的 mu-plugins 机制（”must-use plugins”）。

在/var/www/sanctus-senki.com/cms/wp-content/下新建文件夹 mu-plugins

在这个文件夹下新建文件 custom-smtp.php 编写下面内容，这个版本不能在开头加 use PHPMailer\PHPMailer\PHPMailer;代码段，否则报错


// Custom SMTP configuration for WordPress

function configure_smtp( PHPMailer $phpmailer ) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtp.qq.com';       // 你的 SMTP 服务器
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Port       = 465;                 // SMTP 端口，465 是 SSL 的常用端口
    $phpmailer->Username   = '707070901@qq.com';  // 你的 SMTP 用户名
    $phpmailer->Password   = 'SMTPjyiqwhzlSMTP';  // 你的 SMTP 密码
    $phpmailer->SMTPSecure = 'ssl';               // 加密类型，使用 ssl
    //$phpmailer->From       = '707070901@qq.com';// 发件人地址（这里不强制发件人可以显示转发哦）
    $phpmailer->FromName   = 'Your Name';         // 发件人姓名
}

add_action( 'phpmailer_init', 'configure_smtp' );
?>

好了，这件事告一段落了，大道至简，经历了由简到繁，由繁化简的历程，才明白简约的可贵。

总结

AWS Route53 提供高度可用的 DNS 解析服务，将域名映射到 AWS 资源或其他 IP 地址
ACM 支持免费申请 公有 SSL/TLS 证书，用于保护基于 HTTPS 协议的流量
AWS ELB（Elastic Load Balancing）是AWS提供的一项负载均衡服务，主要分为ALB、NLB、CLB，旨在自动分配进入应用程序的流量，以确保高可用性和可靠性
Linux系统下 mail 是一个邮件客户端，用于发送和接收邮件，sendmail 和 postfix 是邮件传输代理（MTA），主要用于处理邮件的发送和接收
自 2020 年 1 月 7 日起，Amazon EC2 开始限制默认情况下通过端口 25 的电子邮件流量
记住WordPress的 MW WP WPForm、WP MIAL SMTP、Easy WP SMTP 插件，你或许以后用的上

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

过钢者易折，善柔者不败
不必为人性感到意外，哪个人强大了不对弱者动武，哪个女人漂亮了不被男人惦记，
利刃在手，易起杀心，权大无边，总想乱来
2024-9-26 20:26:55

AWS镜像迁移登录问题二三则

2024-09-21T16:26:14.000Z

前言

关于云服务器之前用的多的还是国内的阿里云和腾讯云，也用过一点点的华为云，而今年接触的AWS和GCP比较多，使用场景渐渐多了起来，遇到的问题也渐渐多了起来，之前这些都是有专门的运维同事负责的，而现在降本增效之后只能自己上了，这两条在捣鼓AWS，就先记录一些AWS上遇到的问题和解决办法吧，关于问题我尽量贴一些原始的报错，便于有相同问题的人进行对照。

EC2镜像迁移

此文章的本意是记录遇到的问题和解决办法，所以我在这不会详细描述怎样做镜像，自己去搜索文档吧，要实在找不到可以留言等有空我帮你找下，说说镜像有什么用，在AWS中的系统镜像被称为AMI，全称Amazon Machine Image，可以简单的连接为操作系统，不过要更好用一些。

现实中我们买一台新电脑是先挑硬件组装好，然后安装操作系统，Windows、Linux都可以，如果是云服务器比如AWS，也是先选配置比如CPU、内存、硬盘等等，然后选择一个AMI就可以安装使用了，如果你操作很熟练的话，大概几秒钟就可以得到一台可以立即使用的特定配置的云服务器。

这里的镜像可以选择官方Windows、Linux、Mac等官方支持的系统，也可以选择第三方的，甚至是自己可以定制的，比如你的项目大量使用Ubuntu+XXX的机器，每次创建Ubuntu实例后都要安装XXX软件，这就很麻烦，你可以使用安装好XXX的实例创建映像，保存下来，以后创建新的实例时直接使用这个AMI就很方便了，有点像Docker，但这比Docker要重度一些。

而我使用这个映像的情景是项目的迁移，将AWS实例从一个账号迁移到另一个账号，这里有几个问题需要注意：

AMI可以分享，但只能在同一个区域内，如果跨区域只能先复制到同区域再进行分享
使用AMI镜像时需要分配大于制作镜像时磁盘大小，所以在创建实例时磁盘应该尽可能合理，否则分配了100G实际只用3G，那么用这个AMI最少也要分配100G才行
使用共享AMI先要浏览获取基础映像的授权，我在这遇到了一个问题，选择了另一个账号的AMI，但是启动失败，提示错误如下：

In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit https://aws.amazon.com/marketplace/pp?sku=aw0evgkw8e5c1q413zgy5pjce

其实你访问提供的链接会看到产品的详细信息和定价。你需要阅读并接受产品条款，然后点击“Continue”或类似的按钮完成订阅。之后你就可以返回 AWS 管理控制台，再次尝试启动实例，这时候应该可以成功启动。

无法登录古老的AWS实例

无法登录的原因，并不一定是因为AWS出问题了，AWS本身出问题不能说完全没有，但是这种情况概率比较小，来聊聊我遇到的情况。

接手别的项目组的AWS，密钥已经无法找到，这种情况我已经遇到了两次，都是经了几手的项目，密钥早已经找不到了，我们知道这个密钥只能在创建时下载一次，丢了就几乎无法再登录这个实例了，很多时候需要删除重建了。

为什么说几乎呢？因为没有密钥也不是完全没有办法再登录进去，我在这走了很多弯路，你可以先检测一下这几个问题，对你或许有帮助

再找找原来的密钥，如果能找到这是最方便的途径
使用AWS网站后台的“连接”按钮，来直连实例
检查实例的安全规则，看看22端口是否放行，是否使用其他端口来运行ssh服务了

查询端口是否连通的办法有 telnet ip port 或 nmap -p port ip 等多种办法

前两种方法我都试了行不通，而第三种遇到问题时还没意识到，所以我使用了“必杀技”，将无法连接的实例硬盘分离，然后挂载到其他可以登录的实例，然后挂载修改ssh密钥，再挂载回去重新登录即可，挂载到其他实例的命令如下，根据实际情况调整

1 2	mkdir /mnt/temp sudo mount /dev/xvdb1 /mnt/temp

这时你可能会遇到报错，提示你挂载报错，大概率是UUID重复了，可以修改挂载命令 sudo mount -o nouuid /dev/xvdb1 /mnt/temp

但我修改后还是不能登录，后来发现端口22不通，我一度以为这个实例没有启动ssh服务，尝试了多种方法，走了很多弯路，比如 chroot 或者修改用户数据添加启动ssh命令的脚本但都没有效果，最终发现是ssh服务器被改到了2022端口，废了九牛二虎之力终于可以访问ssh服务了，但还是认证失败

ssh登录时添加 -vvv 选项，输出以下关键调试信息

debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method

关键是 receive packet: type 51 这一句表示publickey验证失败，如果能登录这里应该是 receive packet: type 52，原因大概率就是publickey出了问题，我是因为没把publickey放到服务器上，不过我也很奇怪，创建实例时明明选了密钥，可能因为一开始启动报错就没放上去，导致了后面一系列弯路

总结

AWS 和 GCP 是全球主流的云服务，Microsoft 的 Azure至今还没用过
如果想重用一个云服务环境，可以将这个实例创建成一个AMI保存
如果无法登录实例看看安全规则有没有换ssh的端口
如果密钥真的丢了就把实例的硬盘挂载到其他的实例上修改密钥吧

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

你我皆凡人，生在人世间。终日奔波苦，一刻不得闲。既然不是仙，难免有杂念。道义放两旁，利字摆中间~
无德无行而取厚利，必有奇祸；善行善德而受磨难，必有后福；修德以配位，自谦以远祸。以色相交者，色衰而爱弛；以利相交者，利尽而交疏；以势相交者，势倾而交绝；以道相交者，天荒而地老；以德相交者，地久而天长；你用什么吸引人，你吸引的就是什么样的人。
2024-9-22 00:10:51