Tools

修改后的效果图 👉项目地址：sirius2alpha/resume 🍴Fork from： hijiangtao/resume LaTex简介 LaTeX是一种基于TeX的排版系统，广泛用于生成科学和数学文档的高质量排版。在LaTeX中，你可以使用各种命令和环境来结构化文档并控制其外观。以下是LaTeX项目的基本结构和语法： LaTeX项目结构 文档类声明（Document Class Declaration） 在文档的最开始，你需要声明文档类，例如\documentclass{article}。这行代码定义了文档的类型和基本布局。 宏包（Packages） 使用\usepackage{}命令来引入宏包。宏包提供了额外的功能，如增强的数学公式支持（amsmath）、图像插入（graphicx）等。 文档设置（Document Settings） 在\begin{document}之前，可以定义一些全局设置，如页面布局、自定义命令等。 正文内容（Document Content） \begin{document}和\end{document}之间的内容是文档的主体。这里包含了所有的文本内容、图表、公式等。 环境（Environments） 在文档中，可以使用各种环境来区分文本的不同部分，例如列表（itemize）、表格（tabular）、数学模式（equation）等。 LaTeX语法 命令（Commands） LaTeX命令以反斜杠\开头，如\textbf{}用于加粗文本。 命令可能需要参数，参数放在花括号{}中；也可能有可选参数，放在方括号[]中。 环境（Environments） 环境用于改变一段文本的行为或布局，格式为\begin{environment} ... \end{environment}。 例如，itemize环境用于创建无序列表。 注释（Comments） 使用百分号%开始注释，注释内容不会出现在最终文档中。 特殊字符（Special Characters） 一些字符在LaTeX中有特殊意义，如%、$、&等，如果需要在文档中直接显示这些字符，通常需要在前面加上反斜杠\。 数学模式（Math Mode） 用$...$来标记行内数学内容，用\[...\]或$$...$$来标记独立的数学块。 通过组合这些结构和语法元素，你可以创建出结构化且格式严谨的文档。LaTeX的学习曲线可能相对陡峭，但它能够为复杂的文档排版提供强大且灵活的功能。 一些修改：修改heading，添加照片布局 在resume.cls文件中新增了一些命令： - \tableInfo：姓名、主页左对齐；电话、邮箱右对齐 - \rightInfo:姓名、主页、电话、邮箱右对齐 - \leftInfo：姓名、主页、电话、邮箱左对齐

:label:现状 已经安装好了clash for linux，并且在systemd中写好了配置，能够正常运行（在主机上使用浏览器访问外网OK的）。 vpn配置也已经从机场上拉下来了，但是目前无法ping通google.com。 潜在误区：ping命令是走的ICMP协议 :loudspeaker: 诉求 想要在外部网络环境中，调用clash ui进行节点的选择 web端dashboard的控制：https://clash.razord.top/#/proxies 另外一个项目yacd dashboard：https://yacd.haishan.me/ :question: 怀疑 怀疑没有进行节点的选择，需要把9090端口公开用于在服务器上进行访问。 但是这台主机是通过云服务器的内网暴露实现公网访问的，所以说需要对frpc的相关进行修改才行。 备注 clash的配置文件 config.yaml在/etc/clash下面 dashboard在/etc/clash下面 :mag: 问题排查 检查http_proxy, https_proxy echo $http_proxy $https_proxy // output http://127.0.0.1:7890 http://127.0.0.1:7890 SSL错误问题 在主机上开启代理的情况下，使用conda install 会出现SSL的问题； 但是把环境变量http_proxy等取消设置后，他就不报这个错误了。 frp内网暴露服务是否转发成功 因为我要用到clash的主机，是通过一台云服务器进行内网暴露进行使用的，所以需要检查frp相关设置。 检查~/frp/frpc.toml 配置是否正确，配置正确后在systemctl status 的输出中可以看见相应服务名字成功启动。 像这样： 同时在服务端上的日志/var/log/frps.log中可以进行查看。 在这里也检查出来了一些问题，刚开始的时候clash的相关转发没有跑起来，[[proxies]]这个标签是必要的，不是乱写的啊啊啊 在主机上 使用https://clash.razord.top/#/proxies可以正常访问web端的dashboard 访问localhost:9090端口会有一个{“clash”,“hello”}类似的提示，但是没有相关的控制平面 感觉没有暴露和访问正确的端口，9090端口里面什么都没有。 也有可能是yacd的dashboard影响

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 网页上完成合并。

消息队列的特性 卡夫卡(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性能下降。