在日常开发中，我经常需要在工作项目和个人项目之间切换。每次切换项目时，都需要手动修改 Git 的用户名和邮箱配置，不仅繁琐，还容易出错。更糟糕的是，一旦忘记切换，错误的身份信息就会被永久记录在 Git 历史中，后续清理起来也很麻烦。
为了解决这个问题，我开发了 gid (Git Identity Manager)，一个用 Rust 编写的命令行工具，用于管理多个 Git 身份。本文将介绍这个工具的使用方法，以及在实际使用中遇到的问题和思考。
众所周知，预编译技术对于 SQL 查询具有显著的性能提升作用。具体而言，在执行 SQL 操作时，利用预编译技术可以省略编译步骤，仅需传递特定参数即可借助已准备好的执行计划快速完成查询，从而极大地提升了后端系统的查询效率。
然而，预编译技术并非总是适用且无懈可击的。在实际应用中，可能会遇到一些问题和挑战。例如，在某个场景下，当系统需要处理超过1亿条记录的数据量时，即使采用了预编译技术，查询速度仍然会变得缓慢甚至导致超时现象的发生。尽管从接口层面进行了充分的优化，并建立了相应的索引以加速查询过程，但在实际运行环境中，由于数据规模的巨大差异，这些措施可能无法完全解决问题。
在日常的项目开发过程中，多人协作时难免会有开发同学因误操作，将敏感信息（如密钥、数据库密码等）提交到 Git 仓库中。如果还未推送到远端，通常可以使用 git reset --soft 重新提交。但一旦推送到远端仓库，仅删除或修改文件已无法彻底擦除这些敏感信息。因为Git作为版本控制工具，会在历史纪录中保留所有的内容，不仅影响项目的安全性，还有可能会对客户的产品和终端用户产生影响。
本文将从一个实际案例出发，介绍如何使用Git工具git filter-repo来清理Git仓库中的敏感信息，并探讨其中的原理及其他适用场景。
在实际项目中，我们偶尔会遇到由于客户部署环境的网络限制问题，导致 Docker 镜像的推送与拉取速度很慢，影响部署的效率。 最近接手的一个项目中，我就遇到了类似的情况，我们在客户的内网部署了 Docker 的私有仓库，Jenkins 打包完后需要推送到 Docker 仓库中。 由于客户基于安全要求对于内部网络之间的传输做了网速的限制，通过传统的 Spring Boot 的 FatJar 生成的 Docker 镜像过大，在每次推送镜像和拉取镜像都需要花不少时间。 我们在私有仓库部署的服务较多，对私有仓库的存储容量要求较高。
ElasticSearch是一个高可用的搜索引擎，最近在项目中由于客户基础设施的成熟度不够，需要Ops来进行ElasticSearch的高可用部署，了解了其底层集群相关的知识，本文将对其进行总结，介绍ElasticSearch中集群的架构及数据的存储。