我的知识管理工作流整体来说非常简单，只有三步：

• I-Inbox：输入，即知识、信息的获取；
• P-Process：加工，即对知识、信息进行要点提取、整合、理解、内化、总结等处理；
• O-Output：输出，即写作、分享并获取反馈。

输入（readwise & raindrop）–> Obsidian同步整合信息 –> 输出（typora + blog）

1. 基础命令

1.1 查看健康

1
2
3
4
5
6
7
8

# 查看健康
curl -XGET 'http://localhost:9200/_cat/health?v'
​
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
​
1675044251 02:04:11 elasticsearch yellow          1         1     83  83    0    0       69             0                  -                 54.6%
​
绿色表示一切正常, 黄色表示所有的数据可用但是部分副本还没有分配,红色表示部分数据因为某些原因不可用.

打工人每日网抑云, 所以就用 es简单做个网易云听歌记录. 先上效果图.

当您遇到如下问题时，可以使用分片集群解决：

• 存储容量受单机限制，即磁盘资源遭遇瓶颈。
• 读写能力受单机限制，可能是 CPU、内存或者网卡等资源遭遇瓶颈，导致读写能力无法扩展。

许多人对复制和分片之间的区别感到困惑。记住，复制在多台服务器上创建了数据的精确副本，因此每台服务器都是其他服务器的镜像。相反，每个分片包含了不同的数据子集。

1. 规则

1.1 最左匹配原则

MongoDB 中复合索引的使用和 MySQL 中复合索引的使用类似，也有最左匹配原则。即最左优先，在检索数据时从复合索引的最左边开始匹配。

复合索引创建的时候有一个一个基本的原则就是将选择性最强的列放到最前面。

选择性最高值得是数据的重复值最少，因为区分度高的列能够很容易过滤掉很多的数据。组合索引中第一次能够过滤掉很多的数据，后面的索引查询的数据范围就小了很多了。

1. hook介绍

客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。

客户端钩子位于项目根目录 your_project/.git/hooks 文件夹下。

服务端钩子则位于 your_project.git 文件夹下的 hooks 和 custom_hooks。

1. 初代编码

1.1 ASCII

这是最早也是最著名的编码。由于计算机诞生于美国，所以最早的编码主要考虑的是英语环境。

ASCII 总共可以表示 128 个字符。ASCII 只需要 7 位，但在计算机中，数据存储的基本单位是字节 (Byte)，1 字节 = 8 比特。所以，ASCII 字符通常存储在一个字节中，最高位（第 8 位）固定为 0。

例如：字符 ‘A’ 的 ASCII 码是 65，二进制表示为 01000001。

• 0-31：控制字符（如换行、回车、制表符等，不可打印）。
• 32-127：可打印字符，包括了大小写英文字母 (a-z, A-Z)、数字 (0-9) 和各种标点符号。

1. 功能简介

tmux 3.2 版本引入了强大的 Popup（弹窗）功能，允许用户在当前会话之上悬浮显示一个新的 pane。结合 fzf（命令行模糊搜索工具），我们可以在不离开当前工作上下文的情况下，快速进行文件搜索、命令执行或会话切换。

fzf (Fuzzy Finder) 是一款通用的命令行模糊搜索工具，能够通过模糊匹配关键词快速定位文件、历史命令、进程、Git 提交记录等。

它的核心设计哲学遵循 UNIX 管道理念：作为一个通用的交互式过滤器，接收标准输入（stdin），处理后将结果输出到标准输出（stdout）。这种设计使其能够与 find、grep、history 等任何命令无缝集成。

核心特性：

• 通用性：默认列出当前目录文件名，配合 ripgrep 或 grep 可搜索文件内容。
• Shell 集成：安装后默认接管 Ctrl + R，将枯燥的历史命令回溯转化为高效的交互式搜索体验。

微服务集群中，每个应用基本都会依赖一定数量的外部服务。如果依赖服务过载，服务不可用的情况,在高并发场景下如果此时调用方不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集群雪崩。

所以应该采用熔断的策略，不再调用下游服务。

首先先区分下熔断、限流、降级区别

1. 限流

   是针对服务请求数量的一种自我保护机制，当请求数量超出服务负载时，自动丢弃新的请求，是系统高可用架构的第一步。

2. 熔断

   是调用方自我保护的机制（客观上也能保护被调用方），熔断对象是外部服务。

3. 降级

   是被调用方（服务提供者）的防止因自身资源不足导致过载的自我保护机制，降级对象是自身。