Git克隆阿里云CodeUp仓库时出现“debug1: No more authentication methods to try.”和“Permission denied (publickey)”错误

by

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

已深度思考(用时7秒)

用户现在遇到的问题是Git克隆阿里云CodeUp仓库时出现“debug1: No more authentication methods to try.”和“Permission denied (publickey)”错误。首先，我需要回忆之前的对话，用户之前已经问过类似的问题，当时提供了很多排查步骤，但现在用户给出的错误信息更具体，提到了“没有更多认证方法可尝试”，这说明SSH客户端已经尝试了所有可能的认证方法，但都失败了。

首先，我需要明确这个错误的原因。通常，当SSH连接时，客户端会尝试使用配置的密钥进行认证，如果没有找到合适的密钥或者密钥不被服务器接受，就会出现这个错误。结合之前的对话，用户可能已经尝试过生成密钥、添加公钥到CodeUp、加载私钥等步骤，但可能还有遗漏的地方。

接下来，我需要分析可能的排查点。根据错误信息，“No more authentication methods to try”意味着SSH客户端没有可用的认证方法了。可能的原因包括：本地没有可用的SSH密钥、密钥未正确加载到ssh-agent、密钥权限不正确、SSH配置文件未正确指定密钥、服务器未接受提供的密钥等。

然后，我需要回顾之前的回答，确保这次的回答更聚焦于这个具体的错误信息。之前的回答提到了检查密钥是否存在、添加公钥、加载私钥、权限设置、SSH配置文件、网络测试等，现在需要将这些步骤更针对性地结合起来，特别是针对“没有更多认证方法”这一点。

另外，用户可能没有正确配置SSH配置文件，导致SSH客户端没有使用正确的密钥去连接CodeUp。或者，虽然生成了密钥，但没有将私钥添加到ssh-agent，导致客户端无法找到密钥。还有一种可能是，用户有多个密钥，但SSH客户端没有尝试正确的那个，这时候需要在~/.ssh/config中明确指定。

还要注意，用户可能在生成密钥时使用了不同的算法或文件名，比如使用了id_rsa而不是id_ed25519，或者在添加公钥到CodeUp时复制错了内容。此外，私钥文件的权限必须是600，.ssh目录权限是700，否则SSH会忽略该密钥。

另外，测试SSH连接时使用ssh -T git@codeup.aliyun.com -v可以查看详细的调试信息，显示客户端尝试了哪些密钥，服务器接受了哪些，这对排查问题非常有帮助。用户可能需要执行这个命令来查看具体尝试的密钥和失败原因。

总结下来，解决步骤应该包括：1. 确认本地有SSH密钥；2. 确保公钥已正确添加到CodeUp；3. 检查私钥是否加载到ssh-agent；4. 验证私钥权限和.ssh目录权限；5. 配置~/.ssh/config指定CodeUp的密钥；6. 使用-v参数调试SSH连接，查看详细过程；7. 备选方案使用HTTPS克隆。

需要确保回答清晰，步骤明确，特别是针对“没有更多认证方法”这一关键点，强调检查是否有可用密钥、是否正确加载、配置是否正确，以及如何通过调试日志定位问题。

debug1: No more authentication methods to try.结合 Permission denied (publickey)表明：SSH 客户端已尝试所有可能的认证方法（主要是公钥），但均被服务器拒绝，最终导致认证失败。这是 SSH 公钥认证失败的典型表现，核心原因是客户端未提供服务器接受的 SSH 公钥，或提供的密钥无效/未加载。

一、核心原因定位

通过 ssh -T git@codeup.aliyun.com -v命令（加 -v查看详细调试日志），重点关注以下输出：

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxxxxx explicit

debug1: Authentications that can continue: publickey

debug1: Trying private key: /home/user/.ssh/id_dsa

debug1: Trying private key: /home/user/.ssh/id_ecdsa

debug1: Trying private key: /home/user/.ssh/id_ed25519

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

日志中 Offering public key会显示客户端尝试的密钥路径（如 id_rsa、id_ed25519）。

若所有密钥均显示 Authentications that can continue: publickey后无 Server accepts key，说明服务器未接受任何提供的密钥。

二、分步解决（按优先级排序）

  1. 确认客户端有可用 SSH 密钥，且公钥已添加到 CodeUp

这是最常见原因：客户端未生成密钥，或生成的密钥未添加到 CodeUp 的「SSH 公钥」列表。

检查本地密钥：

ls -la ~/.ssh # 查看是否有 id_rsa.pub/id_ed25519.pub 等公钥文件

若无密钥：执行 ssh-keygen -t ed25519 -C “你的邮箱”生成（一路回车默认即可）。

复制公钥内容（以 Ed25519 为例）：

cat ~/.ssh/id_ed25519.pub # 输出类似：ssh-ed25519 AAAAB3NzaC1yc2E… 邮箱

添加公钥到 CodeUp：

登录 阿里云 CodeUp→ 右上角头像 → 个人设置​ → SSH 公钥​ → 添加公钥，粘贴公钥内容并保存。

2. 确保私钥已加载到 ssh-agent（关键！）

SSH 客户端默认不会主动加载私钥，需通过 ssh-agent管理（尤其当私钥有密码或存在多个密钥时）。

启动 ssh-agent 并加载私钥：

eval “$(ssh-agent -s)” # 启动 agent（输出 Agent pid xxxx 表示成功）

ssh-add ~/.ssh/id_ed25519 # 加载私钥（替换为你的私钥文件名，如 id_rsa）

若提示 Identity added，说明加载成功；

若提示 Could not open a connection to your authentication agent，先执行 eval “$(ssh-agent -s)”再重试。

验证已加载密钥：

ssh-add -l # 列出 agent 中加载的密钥指纹，应能看到你的私钥

3. 修复私钥权限（SSH 安全检查）

SSH 严格要求私钥文件权限为 600（仅所有者可读写），.ssh目录权限为 700，否则会拒绝使用该密钥。

chmod 700 ~/.ssh # .ssh 目录权限（必须）

chmod 600 ~/.ssh/id_ed25519 # 私钥权限（替换为你的私钥文件名）

chmod 644 ~/.ssh/id_ed25519.pub # 公钥权限（可选，不影响认证）

4. 配置 SSH 配置文件（指定 CodeUp 专用密钥）

若你有多个 SSH 密钥（如 GitHub、GitLab 各一个），需在 ~/.ssh/config中明确指定 CodeUp 使用的密钥，避免客户端尝试无关密钥。

创建/编辑配置文件：

vim ~/.ssh/config

添加以下内容（根据实际密钥路径修改）：

阿里云 CodeUp 专用配置

Host codeup.aliyun.com

HostName codeup.aliyun.com # 服务器地址

User git # 固定用户名为 git

IdentityFile ~/.ssh/id_ed25519 # 你的私钥路径（绝对路径更佳，如 /home/user/.ssh/id_ed25519）

IdentitiesOnly yes # 仅使用指定密钥，不尝试其他密钥

PreferredAuthentications publickey # 优先使用公钥认证

5. 验证 SSH 连接（关键测试）

执行以下命令测试认证是否成功，必须看到欢迎信息：

ssh -T git@codeup.aliyun.com

成功提示：Welcome to Codeup, <你的阿里云账号名>!（说明认证通过）。

失败提示：若仍提示 Permission denied，执行 ssh -T git@codeup.aliyun.com -v查看详细日志，重点关注：

客户端尝试了哪些密钥（Offering public key: …）；

服务器是否接受密钥（Server accepts key: …）。

6. 排查网络与仓库权限

网络连通性：确保服务器能访问 CodeUp 的 SSH 端口（22）：

telnet codeup.aliyun.com 22 # 成功会显示 “SSH-2.0-OpenSSH_xxx”

若端口不通：检查服务器安全组（阿里云 ECS → 安全组 → 放行 22 端口）。

仓库权限：确认你要克隆的仓库是公开仓库，或你是仓库成员（联系管理员添加「开发者」及以上权限）。

三、备选方案：用 HTTPS 协议克隆（临时解决）

若 SSH 仍有问题，可临时用 HTTPS 协议克隆（需输入 CodeUp 账号密码或个人访问令牌）：

生成个人访问令牌（推荐，比密码安全）：

登录 CodeUp → 个人设置 → 访问令牌​ → 创建令牌（勾选 repo权限）。

用令牌克隆：

git clone https://codeup.aliyun.com/62a863ad487c507f6270c/adbd/test-android.git

提示输入用户名时填阿里云账号，密码填生成的个人访问令牌。

四、终极调试：通过 SSH 日志定位问题

执行 ssh -T git@codeup.aliyun.com -vvv（加 -vvv获取最详细日志），重点关注：

debug1: Offering public key: …：客户端尝试的密钥路径是否正确？

debug1: Server accepts key: …：服务器是否接受该密钥？（若没有这行，说明密钥未被接受）

debug1: No more authentication methods to try：确认所有密钥均已尝试但仍失败。

总结

No more authentication methods to try的核心是SSH 客户端未找到服务器接受的密钥。按以下顺序排查：

本地是否有密钥 → 2. 公钥是否添加到 CodeUp → 3. 私钥是否加载到 ssh-agent → 4. 私钥权限是否正确 → 5. SSH 配置是否指定密钥 → 6. 测试连接并查看日志。

完成后，重新执行 git clone git@codeup.aliyun.com:62a863ad487c500c27f6270c/rpa/wxhb-android.git即可成功。

debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM

debug1: Authentications that can continue: publickey

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ecdsa_sk

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_ed25519_sk

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Trying private key: /root/.ssh/id_dsa

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

已深度思考(用时8秒)

用户现在遇到的SSH认证问题是：客户端尝试了多个私钥（包括id_rsa、id_ecdsa、id_ed25519等），但都被服务器拒绝，最终提示“Permission denied (publickey)”。根据之前的对话，用户已经尝试过生成密钥、添加公钥到CodeUp、加载私钥到ssh-agent等操作，但问题依然存在。现在需要从提供的调试日志中分析问题所在。

首先，仔细看调试日志：“debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM”，这说明客户端尝试了/root/.ssh/id_rsa这个公钥，但服务器没有接受（因为后面只显示“Authentications that can continue: publickey”，没有“Server accepts key”）。接着客户端尝试了其他私钥（id_ecdsa、id_ed25519等），但都没有成功，最终“No more authentication methods to try”。

核心问题在于：客户端提供的公钥（尤其是id_rsa.pub）没有被阿里云CodeUp服务器接受。可能的原因有几个：1. 用户添加到CodeUp的公钥不是当前客户端正在使用的这个id_rsa.pub；2. 公钥添加到了错误的CodeUp账户；3. 公钥内容复制有误（比如多了空格、换行，或者不完整）；4. 服务器端对该公钥的权限设置有问题（比如仓库未授权）。

接下来，需要引导用户确认几个关键点：首先，检查/root/.ssh/id_rsa.pub的内容，确保和添加到CodeUp的公钥完全一致；其次，确认添加公钥的CodeUp账户是否是当前克隆仓库的账户（比如是否有多个阿里云账户）；另外，可能用户之前生成过多个密钥，而添加到CodeUp的是另一个密钥（比如id_ed25519.pub），但客户端当前尝试的是id_rsa，所以服务器不接受。

另外，日志中显示客户端尝试了多个密钥，包括id_rsa、id_ecdsa、id_ed25519等，但用户可能只在CodeUp添加了其中一个（比如id_ed25519.pub），而客户端优先尝试了id_rsa（因为ssh-agent中可能加载了多个，或者配置中没有指定IdentityFile），导致服务器不接受id_rsa的公钥。这时候需要通过SSH配置文件指定只使用添加到CodeUp的那个密钥。

还有可能是权限问题，虽然用户之前可能改过权限，但需要再次确认/root/.ssh目录权限是700，私钥id_rsa权限是600，公钥权限644。另外，root用户的.ssh目录可能存在权限问题，或者SELinux/AppArmor的限制（不过这种情况较少见）。

总结下来，解决步骤应该是：1. 确认客户端当前使用的公钥（id_rsa.pub）是否已添加到CodeUp；2. 若添加了其他公钥（如id_ed25519.pub），则配置SSH只使用该公钥；3. 检查公钥内容是否完全一致，无多余字符；4. 确认CodeUp账户权限；5. 重新测试连接并查看详细日志。

从你提供的 ssh -T git@codeup.aliyun.com -v调试日志来看，核心问题是：客户端尝试了多个 SSH 私钥（包括 /root/.ssh/id_rsa、id_ecdsa、id_ed25519等），但服务器均未接受这些密钥，最终导致认证失败。以下是具体分析和解决步骤：

一、日志关键信息解读

debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM

debug1: Authentications that can continue: publickey

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ecdsa_sk

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_ed25519_sk

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Trying private key: /root/.ssh/id_dsa

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

Offering public key: /root/.ssh/id_rsa：客户端首先尝试使用 /root/.ssh/id_rsa私钥对应的公钥进行认证，但服务器未接受（无 Server accepts key提示）。

后续尝试其他密钥：客户端依次尝试了 id_ecdsa、id_ed25519等所有本地私钥，但均被服务器拒绝。

最终失败：所有密钥尝试完毕，服务器仍未接受，返回 Permission denied。

二、核心原因定位

最可能的原因：你添加到阿里云 CodeUp 的公钥，与客户端当前尝试的私钥不匹配（即服务器没有你正在使用的这些私钥对应的公钥）。

例如：

你可能在 CodeUp 添加的是 id_ed25519.pub公钥，但客户端优先尝试了 id_rsa私钥（因 ssh-agent加载顺序或配置问题），而 id_rsa.pub未添加到 CodeUp；

或你添加的公钥内容有误（如复制时遗漏字符、多了空格），导致服务器无法识别；

或你添加公钥时用的是 A 阿里云账户，但当前克隆仓库用的是 B 账户（无权限）。

三、分步解决步骤

Step 1：确认「客户端使用的密钥」与「CodeUp 添加的公钥」是否匹配

这是最关键的一步！必须确保 客户端正在尝试的私钥对应的公钥，已添加到 CodeUp。

① 查看客户端当前尝试的所有密钥​

从日志可知，客户端尝试了以下私钥（按优先级排序）：

/root/.ssh/id_rsa→ id_ecdsa→ id_ed25519→ id_xmss→ id_dsa

② 检查这些私钥对应的公钥是否已添加到 CodeUp​

假设你希望使用 id_ed25519密钥（推荐，更安全），则需确保 id_ed25519.pub已添加到 CodeUp：

1. 查看 id_ed25519.pub 内容（复制此内容，用于对比 CodeUp 添加的公钥）

cat ~/.ssh/id_ed25519.pub

输出示例：ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKZxxxxxx… 你的邮箱

2. 登录 CodeUp 控制台（https://codeup.aliyun.com/）→ 个人设置 → SSH 公钥

3. 检查已添加的公钥中，是否有与上述 id_ed25519.pub 完全一致的内容

若未添加：将 id_ed25519.pub内容复制到 CodeUp 并添加。

若添加的是其他公钥（如 id_rsa.pub）：确保 id_rsa.pub内容与 CodeUp 添加的一致，或通过 SSH 配置强制使用 id_ed25519。

Step 2：通过 SSH 配置强制使用「已添加到 CodeUp 的密钥」

若你有多个密钥（如同时有 id_rsa和 id_ed25519），需在 ~/.ssh/config中明确指定 CodeUp 只使用已添加到 CodeUp 的那个密钥，避免客户端尝试无关密钥。

① 编辑 SSH 配置文件​

vim ~/.ssh/config

② 添加 CodeUp 专用配置（以 id_ed25519为例）​

阿里云 CodeUp 专用配置（替换为你的密钥路径和文件名）

Host codeup.aliyun.com

HostName codeup.aliyun.com # 服务器地址（固定）

User git # 固定用户名为 git

IdentityFile ~/.ssh/id_ed25519 # 仅使用 id_ed25519 私钥（确保此公钥已添加到 CodeUp）

IdentitiesOnly yes # 仅用指定密钥，不尝试其他密钥

PreferredAuthentications publickey # 优先公钥认证

③ 保存后测试连接​

ssh -T git@codeup.aliyun.com

若成功，会显示 Welcome to Codeup, <你的阿里云账号名>!。

Step 3：修复「公钥内容不一致」或「账户权限」问题

① 确保公钥内容完全一致​

复制公钥时避免多余字符（如换行符、空格），建议用 cat命令直接输出并复制：

cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard # Linux 复制到剪贴板（需安装 xclip）

或手动选中输出内容复制（注意不要复制末尾的邮箱别名外的多余字符）

② 确认 CodeUp 账户权限​

确保你添加公钥的阿里云账户，有权限访问目标仓库（仓库是公开仓库，或你是仓库成员/管理员）。

若仓库属于某个组织，需联系组织管理员将你的账户添加为成员（角色至少「开发者」）。

Step 4：验证私钥权限与 ssh-agent 加载

即使配置了 IdentityFile，仍需确保私钥权限正确且已加载到 ssh-agent（尤其当私钥有密码时）：

① 修复私钥权限​

chmod 700 ~/.ssh # .ssh 目录权限（必须）

chmod 600 ~/.ssh/id_ed25519 # 私钥权限（替换为你的私钥文件名）

② 加载私钥到 ssh-agent​

eval “$(ssh-agent -s)” # 启动 ssh-agent（输出 Agent pid xxxx 表示成功）

ssh-add ~/.ssh/id_ed25519 # 加载私钥（若提示输入密码，输入生成密钥时设置的密码）

ssh-add -l # 验证是否加载成功（应显示密钥指纹）

Step 5：终极测试与日志分析

若以上步骤无效，执行 最详细日志​ 定位问题：

ssh -T git@codeup.aliyun.com -vvv # 加 -vvv 获取所有调试信息

重点关注以下输出：

debug1: Offering public key: …：确认客户端是否使用了你在 config中指定的密钥（如 id_ed25519）。

debug1: Server accepts key: …：若出现此行，说明服务器接受了密钥（认证成功）；若没有，说明密钥未被接受（回到 Step 1 检查公钥是否添加正确）。

四、备选方案：用 HTTPS 协议临时克隆（绕过 SSH）

若 SSH 问题暂时无法解决，可先用 HTTPS 协议克隆（需输入 CodeUp 账号密码或个人访问令牌）：

生成个人访问令牌（推荐，比密码安全）：

登录 CodeUp → 个人设置 → 访问令牌​ → 创建令牌（勾选 repo权限）。

HTTPS 克隆仓库：

git clone https://codeup.aliyun.com/62a863ad487c57f6270c/abcd/test-android.git

提示输入用户名时填阿里云账号，密码填生成的个人访问令牌。

总结

当前问题的核心是 客户端尝试的密钥与 CodeUp 添加的公钥不匹配。按以下顺序排查：

确认 IdentityFile指定的私钥（如 id_ed25519）对应的公钥已添加到 CodeUp；

通过 ~/.ssh/config强制 SSH 只使用该密钥；

检查公钥内容是否完全一致、账户权限是否正确；

修复私钥权限并加载到 ssh-agent。

完成后，重新执行 git clone git@codeup.aliyun.com:62a8687c500c27f6270c/abcd/test-android.git即可成功。

解决在 Mac 上安装 软件弹出提示：安装包已经被损坏并且不能被打开

by

解决方法和步骤：

  1. 打开安装包；
  2. 将安装包+“INSTALLER”+拖动复制到某个文件夹，复制后的文件路径例如像这样：%2FUsers%2Fmichael%2FDownloads%2FINSTALLER.app；
  3. 打开+Terminal%2C+输入xattr+-cr+，再将复制后的“INSTALLER”拖动到Terminal，此时像这样：xattr+-cr+%2FUsers%2Fmichael%2FDownloads%2FINSTALLER.app，然后按return；
  4. 打开复制后的“INSTALLER”安装；
  5. 安装好“INSTALLER”后，打开刚才安装的+Adobe+软件，打开后再关闭；
  6. 安装“Adobe+2023-2024+一键激活+Patcher+v14.pkg”；
  7. 完成。

为每个项目单独设置用户名和邮箱

by

问题描述

提交git记录前需要先设置用户名和邮箱，最常用的方式就是全局设置

$ git config --global user.name xxx
$ git config --global user.email xxx
# 查看
$ git config -l

最近想要在服务器上进行版本管理，不方便全局设置，可以在项目路径下进行本地设置

方式一

进入项目路径，执行如下命令

$ git config --local user.name xxx
$ git config --local user.email xxx
# 查询
$ git config --local -l

方式二

直接在.git/config配置文件中设置

[user]
    name = xxx
    email = xxx

Library not loaded: @rpath/libcurl.4.dylib

by

当你在 macOS 上遇到“Library not loaded: @rpath/libcurl.4.dylib”的错误时，这通常意味着你的应用程序在运行时找不到指定的动态链接库（DLL）文件。这种情况通常发生在以下几种情况：

解决方案

  1. 确保库文件存在：确保 libcurl.4.dylib 文件存在于你的应用程序的 @rpath 目录下。你可以使用 install_name_tool 来查看和修改库文件的路径。
  2. 设置正确的运行路径：使用 install_name_tool 来修改库文件的安装名称（install name）。例如，如果你的应用程序位于 /Applications/MyApp.app，而 libcurl.4.dylib 位于该应用的 Contents/Frameworks 目录下，你可以使用以下命令来设置正确的运行路径：install_name_tool -change @rpath/libcurl.4.dylib @executable_path/../Frameworks/libcurl.4.dylib /Applications/MyApp.app/Contents/MacOS/MyApp
  3. 或者，如果你使用的是 Xcode，可以在项目的 Build Phases 中添加一个 Run Script Phase，在其中加入上述命令。
  4. 检查构建配置：确保你的项目配置正确设置了运行时搜索路径（Runpath Search Paths）。在 Xcode 中，你可以在 Target 的 Build Settings 中查找 Runpath Search Paths，并添加包含 libcurl.4.dylib 的目录。例如：
    • 在 Xcode 的 Build Settings 中，找到 Runpath Search Paths 并添加 @executable_path/../Frameworks。
  5. 使用 lipo 工具验证架构：确保 libcurl.4.dylib 支持你的应用程序架构（如 arm64, x86_64 等）。你可以使用 lipo 工具来检查和修改库文件的架构：lipo -info /path/to/libcurl.4.dylib如果库文件的架构不正确，你可能需要重新编译或获取正确架构的库文件。
  6. 清理和重建项目：有时候，简单的清理和重建项目可以解决路径或配置问题。在 Xcode 中，你可以选择 Product > Clean Build Folder，然后重新构建项目。

通过上述步骤，你应该能够解决 “Library not loaded: @rpath/libcurl.4.dylib” 的错误。如果问题仍然存在，检查是否有其他依赖问题或配置错误，并确保所有依赖库都已正确安装和配置。

getExternalCacheDir与getCacheDir的区别

by

getCacheDir
getCacheDir()其对应着应用程序内的内部缓存，用来存储临时数据。因此在系统空间较少时有可能会被自动清除。存放路径一般是/data/data/<应用包名>/cache目录。

getExternalCacheDir
getExternalCacheDir()对应着应用程序内的外部缓存，同样是用来存储临时数据的。但是其由于脱离了应用管理，因此并不会在空间少时被自动清除。存放路径一般是/storage/sdcard/Android/data/<应用包名>/cache目录。

应用卸载
当用户卸载当前应用程序时，以上两个方法里的内容都会随着应用卸载所清除。若有想要一直保存的内容，可以调用getExternalStorageDirectory目录下（抑或其他sd卡下的目录）进行保存。

当然，如果想要保存文件数据（长时间保存），上面对应着getFilesDir()和getExternalFilesDir()，类比即可。

笔记
可以看到，当有External（外存）时，数据都是缓存在sd卡中的（若存在）；否则则是内部缓存（可管理）。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/CarsonWoo/article/details/89142756

android变量被系统回收,Android使用static定义全局变量被系统回收的问题

by

ppConstants.java

public static  String AppPay = “AppPay”;

public static  String AppPay_AccountPay = “/AccountPay”;

public static  String AppPay_TencentPay = “/TencentPay”;

public static  String AppPay_AllinPay = “/AllinPay”;

public static  String AppPay_VCardPay = “/VCardPay”;

public static  String AppPay_GetPayHistory = “/GetPayHistoryByUserId”;

public static  String AppPay_OrderConfirm = “/OrderConfirm”;

大家在开发Android应用的时候，应该会有沿用java的习惯，用static定义一些全局的变量。可是Android对进程和内存管理不同于PC的核心——如果资源足够，Android不会杀掉任何进程，另一个意思就是进程随时可能会被杀掉。而Android会在资源够的时候，重启被杀掉的进程。也就是说静态变量的值，如果不做处理，是不可靠的，可以说内存中的一切都不可靠。

网上很多文章说用Application来保存一些全局变量，这个方法经过我尝试之后，发现还是会被清空。怎么办呢？

当我快绝望的时候，忽然想起一个方法onSaveInstanceState()!我们可以覆写Activity的onSaveInstanceState()方法，保存当前页面的一些数据，在进程被摧毁之后，重新回到页面的时候，在onCreate(Bundle savedInstanceState)中的savedInstanceState取到保存的数据。本以为这样就可以解决问题了，但是想想之后，发现不可能每个页面都去保存一大堆变量。

最后我想到java的反射机制，可以为成员变量赋值，因为当应用的进程被系统摧毁之后，再回到应用，Application会重启，执行onCreate()方法，所以我就在onCreate()里调用

public void initAppData(){

try {

Class> clazz = AppConstants.class;

//获取这个类所有的成员变量

Field[] fields = clazz.getDeclaredFields();

for(Field field : fields) {

Object appConstants;

//得到一个实例

appConstants = clazz.newInstance();

field.set(appConstants, field.get(field.getName()));

}

}catch (InstantiationException e) {

e.printStackTrace();

}catch (IllegalArgumentException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

}

}

Application重启之后，再进行数据的初始化。

link: https://blog.csdn.net/weixin_33443972/article/details/117617251

在JNI中使用SetSystemProperty

by

在 Java Native Interface (JNI) 中，SetSystemProperty 并不是一个直接可用的函数或方法。通常，你会通过 JNI 调用 Java 的系统属性相关方法来设置系统属性。

如何在 JNI 中设置系统属性

  1. 获取 java.lang.System 类：你需要首先获取 System 类的引用。
  2. 获取 setProperty 方法：然后获取这个类中 setProperty 方法的引用。
  3. 调用方法：通过 JNI 调用这个方法来设置属性。

示例代码

以下是一个简单的示例，展示了如何在 JNI 中设置一个系统属性：

#include <jni.h>
#include <stdio.h>

JNIEXPORT void JNICALL Java_YourClass_setProperty(JNIEnv *env, jobject obj) {
    jclass systemClass = (*env)->FindClass(env, "java/lang/System");
    if (systemClass == NULL) {
        return; // 处理错误
    }

    jmethodID setPropertyMethod = (*env)->GetStaticMethodID(env, systemClass, "setProperty", "(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;");
    if (setPropertyMethod == NULL) {
        return; // 处理错误
    }

    jstring key = (*env)->NewStringUTF(env, "myProperty");
    jstring value = (*env)->NewStringUTF(env, "myValue");

    (*env)->CallStaticObjectMethod(env, systemClass, setPropertyMethod, key, value);

    // 清理局部引用
    (*env)->DeleteLocalRef(env, key);
    (*env)->DeleteLocalRef(env, value);
    (*env)->DeleteLocalRef(env, systemClass);
}

使用步骤

  1. 编译并生成共享库：确保你的 JNI 代码编译正确，并生成相应的共享库（如 .dll、.so 文件）。
  2. 在 Java 中加载本地库：使用 System.loadLibrary("your_library_name") 来加载本地库。
  3. 调用 JNI 方法：从 Java 代码中调用 setProperty 方法。

注意事项

  • 设置的系统属性在 JVM 运行期间有效，但不会影响外部环境。
  • 确保在多线程环境下小心使用，以避免潜在的数据竞争问题。

解决：RPM软件包: 错误：无法从 /var/lib/rpm 打开软件包数据库

by

错误原因

可能由于强制结束了yum操作而导致rpm数据库被损坏了！不一定是你手动结束，也可能是因为网络原因

解决方案

删除已损坏的 __db 文件

进入rpm目录命令：
cd /var/lib/rpm
#删除 __db 文件命令：两种方式任选一种
#方式一：
rm /var/lib/rpm/__**
#方式二：
rm -i __db.*
重建rpm数据库
#重新构建rpm数据库命令：
rpm –rebuilddb

MySQL MGR集群原理及实践

by

一、MGR简介

MGR全称MySQL Group Replication（Mysql组复制），是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用、高扩展、高可靠的MySQL集群服务。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-syncreplication），从而进一步提示数据复制的强一致性。

MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。

二、MGR原理

组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的Server集群。复制组由多个Server成员组成，如下图的Master1、Master2、Master3，所有成员独立完成各自的事务。

当客户端发起一个更新事务时，该事务先在本地执行，执行完成之后就要发起对事务的提交操作。在还没有真正提交之前，需要将产生的复制写集广播出去，复制到其它成员。如果冲突检测成功，组内决定该事务可以提交，其它成员可以应用，否则就回滚。

最终，所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。

三、MGR特点

高一致性。基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

高容错性。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

高扩展性。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

高灵活性。有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

四、使用限制

（1） 仅支持innodb引擎

​为什么需要使用innodb引擎呢？在MySQL Group Replication中，事务以乐观形式执行，但是在提交时检查冲突，如果存在冲突，则会在某些实例上回滚事务，保持各个实例的数据一致性，那么，这就需要使用到事务存储引擎，同事Innodb提供一些额外的功能，可以更好的管理和处理冲突，所以建议 业务使用表格使用inndb存储引擎，类似于系统表格mysql.user使用MyISAM引擎的表格，因为极少修改及添加，极少出现冲突情况。

（2）主键

​每个需要复制的表格都必须定义一个显式主键，注意跟隐式主键区分（使用Innodb引擎的表格，如果没有指定主键，默认选择第一个非空的唯一索引作为主键，如果没有，则自动创建一个6个字节的rowid隐式主键）。这个主键能在冲突发生时启动极其重要的作用，同时，能够有效提高relay log的执行效率。

（3）隔离级别

​官网建议使用READ COMMITTED级别，除非应用程序依赖于REPLEATABLE

READ，RC模式下没有GAP LOCK，比较好支持Innodb本身的冲突检测机制何组复制的内部分布式检测机制一起协同工作。不支持SERIALIZABLE隔离级别。

（4）外键

​不建议使用级联外键，如果旧库本身有外键，业务上无法去除并且使用的是多主模式，那么，请配置group_replication_enforce_update_everywhere_check ，强制检查每个组成员的级联检查，避免多主模式下执行级联操作造成的检测不到的冲突。

五、参数规范

因前期创建实例大多采取默认配置 导致开发，测试，生产等环境间数据库参数不同 对程序运行有一定的影响。 以后创建实例将会参数规范化 对已有的实例后续也会慢慢修正。

下面简单解释下几个改动的参数

sql_mode 去除了ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES,NO_ZERO_IN_DATE, NO_ZERO_DATE等限制 采取了较为宽松的模式

lower_case_table_names 统一设置为1 即不区分大小写 有些实例还没更改 大家建表建库的时候不要大写

character-set-server 统一设置为utf8 不要用latin1字符集

wait_timeout和interactive_timeout参数控制空闲连接的时长 当连接空闲时间超过此参数则会被断开 以后会统一设置为1800s即30分钟

transaction_isolation 事务隔离级别 MySQL官方默认是可重复读（repeatable-read）目前单实例及主从架构的mysql采用了此级别，MGR集群将采取读已提交（read-committed）级别。Oracle默认是读已提交 。

六、两地三中心应用

随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。其中两地是指同城、异地；三中心是指生产中心、同城容灾中心、异地容灾中心。

两地三中心方案中，基于设定的短期目标可以明确同城双活和异地容灾的方案组合。设计重点为同城双活，即在同城的数据中心之间，一般通过高速光纤相连，在网络带宽有保障的前提下，网络延迟一般在可接受范围内，两个机房之间可以认为在同一个局域网内。

在设计上可以和应用层结合起来，有两种部署模式：分为应用层双活和数据库双活，应用层双活和数据库单活。

（1）MGR集群多活架构

基于MGR的多活特性，数据的写入可以在多个节点之间进行复制，实现数据强一致性需求，并且在节点间通信出现延迟的情况下，会自动实现服务降级。对于此类方案，我们可以采用同机房多写，同城异机房只读的方案。

（2）双主模式的多活

两个节点均可以写入数据，可以实现跨机房的数据复制，延迟较低，在业务层需要做隔离，在故障发生时能够快速切换到同机房的Slave节点。此方案对于两个IDC机房的场景中较为实用，但是机房多活的场景不适合。

（3）业务交叉的双活方案

此种方案是双活技术的变通实现，即存在两类业务A和B,数据存储在database级别（schema层级），分别在不通的IDC节点完成数据写入，比如业务A在IDC1完成写入，业务B在IDC2完成写入，两个节点之间存在跨机房的复制节点，在出现问题时，能够通过域名的方式切换到指定的IDC节点。此种方案对于业务的依赖性较高，不适合机房多活的场景。

作者：架构设计思维

Link: https://www.jianshu.com/p/b9831f15e10c