Posts

问题描述 在某一天正常输入密码进入mysql的过程中出现了这样的问题： yoho@~$ mysql -u root -p Enter password: ERROR 3118 (HY000): Access denied for user 'root'@'localhost'. Account is locked. 问题分析 查证一番之后就是账户被锁定了，在mysql.user中的用户的account_locked属性写成了N，正常应该是Y； 现在的问题就是需要进入到mysql中对这个值进行修改。。 问题是平时个人电脑上我就是用的root，其他也没有什么用户了，我就进不去mysql修改不料。 解决方法 一番摸索之后找到了一个方法，绕过权限检查机制登入mysql然后进行修改即可。 绕开权限检查机制的过程如下： 进入/etc/mysql/mysql.conf.d/下，有mysql.cnf和mysqld.cnf两个文件 你看你自己电脑上的东西是写在哪个文件上的，我的电脑上基本就是mysql.cnf是空的，配置都在mysqld.cnf上 对你要修改的文件先用sudo cp命令进行一个备份，再进行修改，防止发生意外 打开文件，在[mysqld]下添加一行配置:skip-grant-tables 保存之后重新启动mysql服务，sudo ststemctl restart mysql 再用mysql -u root 就可以绕过权限直接登陆了 进入之后再对mysql.user表中的相应用户的account_locked字段的值进行修改 最后再将mysqld.cnf改回来重启mysql服务就可以了

Git正确使用姿势 Git工作区域和流程 工作区域 **远程仓库：**就是我们托管在github或者其他代码托管平台上的仓库。 **本地仓库：**就是在我们本地通过git init命令初始化的新建的仓库。 **工作区：**就是我们写代码、编辑文件的地方。 **暂存区：**当工作区的内容写好了之后，就会通过add命令，将工作区的内容放到暂存区，等待commit命令提交到本地仓库中。 文件状态 **未跟踪的（untracked）：**表示在工作区新建了某个文件，还没有add。 **已修改（modofied）：**表示在工作区中修改了某个文件，还没有 add。 **已暂存（staged）：**表示把已修改的文件已add到暂存区域。 **已提交（commit）：**表示文件已经commit到本地仓库保存起来了。 Git常见命令 仓库初始化和克隆 # git仓库初始化 git init # 从远程仓库中进行克隆代码到本地仓库 git clone [远程仓库的HTTP/SSH的URL] # 查看当前git仓库的状态 git status 远程仓库管理 Git正确使用姿势 Git工作区域和流程 工作区域 远程仓库： 就是我们托管在github或者其他代码托管平台上的仓库。 本地仓库： 就是在我们本地通过git init命令初始化的新建的仓库。 工作区# git remote 是用来管理远程仓库的命令 git remote # 查看已配置的远程仓库 git remote -v # 查看远程仓库的URL git remote add <远程仓库名称> <远程仓库URL> # 添加一个新的远程仓库 # e.g git remote add origin <远程仓库URL>，一般采用origin作为远程仓库的名字 git remote remove origin # 删除名为origin的远程仓库 git remote rename origin newname # 将origin的名字改为newname # 设置本地仓库的上游分支 git branch --set-upstream-to=origin/main main # 给本地仓库的分支重命名 ## 把master分支更名为main分支 git branch -m master main 从工作区提交代码到远程仓库 # git add 将更改过的代码添加到暂存区 git add ....

要在 Ubuntu 的终端中合并别人的 Pull Request (PR)，您可以按照以下步骤操作： 确保您的本地仓库是最新的： git fetch origin git checkout main git pull origin main 创建一个新分支来测试 PR： git checkout -b pr-branch 拉取 PR 的内容。假设 PR 编号为 xx： 这个编号就是PR界面中的#16，就代表编号是16 git pull origin pull/xx/head 测试代码，确保一切正常。 如果测试通过，切换回主分支： git checkout main 合并 PR 分支： git merge --no-ff pr-branch 推送更改到远程仓库： git push origin main 删除临时分支： git branch -d pr-branch 这些步骤假设您有权限直接推送到主分支。如果您使用的是 GitHub，通常会在网页界面上完成 PR 的最终合并。在那种情况下，您可以在本地测试 PR，然后在 GitHub 网页上完成合并。

什么是GORM？ GORM 是一个 Go 编程语言中的 ORM（对象关系映射）库，全名为 “Go Object Relational Mapping”。ORM 是一种编程技术，旨在将数据库中的数据与编程语言中的对象进行映射，从而使开发者能够使用面向对象的方式来操作数据库，而不需要直接编写 SQL 查询语句。 GORM 为 Go 语言开发者提供了一个便捷的方式来操作数据库，支持多种数据库系统，包括 MySQL、PostgreSQL、SQLite 等。它提供了许多功能，如数据库连接管理、模型定义、查询构建、事务管理、关联关系映射等。 以下是一些 GORM 提供的功能和特点： 模型定义简单：你可以定义 Go 结构体来映射数据库表，然后使用 GORM 来处理与数据库的交互。 自动迁移：GORM 可以自动根据模型定义来创建、修改和删除数据库表结构。 查询构建：你可以使用链式方法构建复杂的查询语句，进行数据的检索、排序、过滤等操作。 事务管理：GORM 支持事务，你可以在代码中使用事务来确保数据库操作的原子性。 关联关系：GORM 支持定义和处理表之间的关联关系，如一对一、一对多、多对多等。 钩子函数：GORM 允许你在模型的生命周期中定义钩子函数，以便在不同的操作发生时执行特定的逻辑。 使用GORM对数据库进行增删查改 数据库的设计 使用mysql作为数据库，新建一个表user，其中最主要的列是Username和Email； 因为gorm默认使用id为主键，所以我们也在表user中新建一列id； 另外为了配合grom.Model的使用表中另外新增created_at,updated_at,deleted_at三列。 注意，主键id记得要设置自动递增。 我们可以先使用navicate的随机数据生成少量数据。 连接数据库 使用 GORM 建立数据库连接，你需要提供 MySQL 数据库的连接信息。这包括数据库的用户名、密码、主机名、端口号和数据库名称。 dsn := "username:password@tcp(hostname:port)/dbname?charset=utf8mb4&parseTime=True&loc=Local" db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{}) if err != nil { panic("Failed to connect to the database") } 确保将 username、password、hostname、port 和 dbname 替换为自己的 MySQL 数据库连接信息。...

消息队列的特性 卡夫卡(Kafka)作为消息队列的一种，拥有异步、削峰、解耦三种特性，并依靠这些特性，他经常在搜索、直播、订单和支付服务。 **异步：**不同于同步通信的需要等待接收方响应，异步通信的发送方在发送消息到消息队列后，不等待接收方响应，而是继续进行其他操作。接收方仅需要从消息队列中拉取消息即可。 异步操作减少了流程长度，提高消息的吞吐量和效率。 **削峰：**对于突发的消息高峰，消息队列起到了存储请求的作用，使后台能以稳定的速率处理消息，从而减少了服务器的高峰负担，提高系统的稳定性。 解耦：解耦合即降低各个组件之间的依赖。使用消息队列，发送者和接收者各种把自己的消息发送给消息队列，从而实现解耦，方便各自开发部署，避免一方接口发生错误而影响多方，实现错误隔离。 卡夫卡的基本概念 **逻辑队列(Topic)：**可以建立不同的逻辑队列，存储于物理集群中。 **物理集群(Cluster)：**可建立多个逻辑队列。 **生产者(Producer)：**发送消息到逻辑队列。 **消费者(Consumer)&消费者组(Consumer Group)：**消费逻辑队列内的消息，各个消费者组互不干扰。 **Offset：**记录消息在有序序列Partition中的相对位置，每个Topic可分为多个Partition。Offset是消息的唯一ID，并在序列中严格递增。搜索Offset采用二分查找找到小于目标Offset的最大索引位置（时间戳索引类似）。 **Replica：**相当于副本，保证集群中节点上的 Partition 数据不因故障丢失。每个Partition有一个Replica-Leader，用于写入，同时拥有多个Follower用于记录Leader。如果Follower数据与Leader差距过大则踢出ISR。Replica又以log日志文件存储。 卡夫卡的消费模式 卡夫卡消息队列有两种最常见的消费模式。 **一对一：**生产者将消息发送到消息队列后，由消费者从队列中拉取并消费，然后信息会被删除。 一对多：即发布-订阅模式。生产者将消息发送到逻辑队列(Topic)（逻辑队列存储在Cluster物理集群中），可以被多个消费者订阅，从而实现每个消费者独立从该主题中拉取消息，值得注意的是该模式下消息并不会在消费后立刻删除，而是会在删除前保留一段时间。 然而在实际业务中，这两种消费模式并不能覆盖所有常业务场景，因此也会衍生出如竞争消费和优先级消费等高级模式。 卡夫卡消息分配 **手动分配：**通过手动分配完成哪个consumer消费哪个Partition。缺点是当Consumer节点故障后，Partition数据流受影响；当出现新的Consumer，需要重新分配Partition。 **Rebalance：**通过设立Coordinator，自动识别故障的consumer节点或新增的consumer，实现自动分配。Consumer端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。 提高卡夫卡吞吐量和稳定性的方法 **Producer：**批量发送（降低io次数）、数据压缩（降低带宽流量）。 **Broker：**顺序写（提高吸入速度），消息索引，零拷贝。 **Consumer：**Rebalance分配。 卡夫卡的缺点 **重启操作：**重启broker后，Leader切换。与此同时数据仍在写入，导致重启的broker和当前的Leader数据产生差异，需要重新追赶后才能回切（由于其他broker也有可能需要重启），导致需要大量时间。 **替换、扩容、缩容操作：**替换与重启操作类似，不过由于是重新写入，所以需要的时间更多。扩容和缩容都需要进行复制操作，因此也需要大量时间。 **负载不均衡问题：**为降低某个Partition的IO写入而进行迁移，但同时也会引入新的IO负载，陷入恶性循环，需要复杂的解决方案。 缺点总结： 卡夫卡运维成本高。 负载不均衡问题严重。 没有缓存，依赖页缓存Page Cache。 Controller、Coordinator和Broker在同一进程中，IO性能下降。