分布式数据库系统中主从、主主和无主三种复制算法
分布式系统中的复制对于确保数据一致性、可用性和系统弹性至关重要。这是一种将数据存储在多个节点或服务器上的策略，即使在服务器故障或维护期间也可以防止数据丢失并实现不间断访问。1、单领导者主从复制：涉及一台主服务器（领导者）处理所有写入操作，而多个辅助服务器（跟随者）复制这些更改。非常适合保持强一致性和数据完整性，广泛应用于写操作至关重要的场景。2、多主复制：每个节点都可以接受写操作，并且更改在节点之间同步。这种方法对于延迟和写入冲突解决是关键考虑因素的分布式系统是有益的。3、无领导复制：所有节点都可以接受读取和写入，通常用于高度分布式架构中，以增强可用性和分区容错性。什么是复制？复制分同步复制和
via 极道 (author: banq)
分布式系统中的复制对于确保数据一致性、可用性和系统弹性至关重要。这是一种将数据存储在多个节点或服务器上的策略，即使在服务器故障或维护期间也可以防止数据丢失并实现不间断访问。1、单领导者主从复制：涉及一台主服务器（领导者）处理所有写入操作，而多个辅助服务器（跟随者）复制这些更改。非常适合保持强一致性和数据完整性，广泛应用于写操作至关重要的场景。2、多主复制：每个节点都可以接受写操作，并且更改在节点之间同步。这种方法对于延迟和写入冲突解决是关键考虑因素的分布式系统是有益的。3、无领导复制：所有节点都可以接受读取和写入，通常用于高度分布式架构中，以增强可用性和分区容错性。什么是复制？复制分同步复制和
via 极道 (author: banq)
Reddit网友：Springboot升级后性能下降
我最近为我的团队进行了 springboot 和 Java 从 2.7 到 3.1.2 的升级，以及从 Java 11 到 Java 17 的升级。这次升级后，我们发现性能非常糟糕。我在前后也进行了性能测试。我们的一个 API 的 p99 延迟约为 2 秒，但升级后跃升至 5.5-6 秒。我们还升级了tomcat版本到10.1.X你们对此有什么想法吗？有没有人在升级后也遇到过这种性能下降的情况。讨论： 我们对两个 API 进行了性能测试，这两个 API 都进行了降级。 虽然我怀疑 spring 是罪魁祸首，但由于许多项目都使用它，而且这种降级会出现在科技新闻中，但这并非不可能。您还可以检查您的
via 极道 (author: banq)
我最近为我的团队进行了 springboot 和 Java 从 2.7 到 3.1.2 的升级，以及从 Java 11 到 Java 17 的升级。这次升级后，我们发现性能非常糟糕。我在前后也进行了性能测试。我们的一个 API 的 p99 延迟约为 2 秒，但升级后跃升至 5.5-6 秒。我们还升级了tomcat版本到10.1.X你们对此有什么想法吗？有没有人在升级后也遇到过这种性能下降的情况。讨论： 我们对两个 API 进行了性能测试，这两个 API 都进行了降级。 虽然我怀疑 spring 是罪魁祸首，但由于许多项目都使用它，而且这种降级会出现在科技新闻中，但这并非不可能。您还可以检查您的
via 极道 (author: banq)
实施卢曼卡片盒笔记法的操作原则之一：“最小可行方案” 原则
上一次连载探讨了卢曼卡片盒背后的 “角色分工”，并站在个人创作者的视角上描述了一种典型的角色分工：以卡片笔记作为 “食材” 和 “调味料”，以卡片盒作为 “原料仓库”、“菜谱经验库” 和 “实验平台”，创作者自己扮演 “厨师” 不断制作推陈出新的 “饭菜”———文章作品 😃
需要说明的是，以上只是无数可行的角色分工中的一种，或者说是我结合自身创作经历最容易联想到的一种。对于复习备考、教学科研类工作、团队协作项目乃至我从未接触过的工作类型，也许会有更合适的角色分工。
无论具体工作类型如何，我相信它们都包含一定的创造性思维成分———比如说：在自己头脑中建立起灵活可靠的 “脑回路”、在教学实践中设计出启发思考和参与的活动、在学术社区中发表一种新颖的思维模型或解释框架等等
接下来开始介绍卢曼卡片盒的操作原则，介绍这些原则可能是最具挑战性的部分，因为我自己仍处在创作内容连载的过程中，如果我的总结与实际情况不符，就会出现这些问题：
❶ 操作原则高于实际，连我自己都做不到，结果可能为了死守原则，后续连载文章都写不出来了
❷ 操作原则低于实际，假如我没能把握卢曼笔记法的核心思想，只是展现了一些粗浅的理解，那么很可能会误导自己和读者，让大家误认为卢曼笔记对创作活动的帮助仅此而已
为了避免上述两种偏差，同时减少 “追求一步到位” 的纠结，我优先引入一个最为基础的操作原则，即 “最小可行方案” 原则，它的英文表达是 “Minimum Viable Plan”，简称 MVP。用 Emoji 表情图来展示，就是 🛹 ➠🚲 ➠ 🏍 ➠ 🚗
理解和实践最小可行方案原则，可从以下几方面入手：
❶ 优先选择 ”稍微努力就能够到“ 的改进方案，而不是 ”憋大招“。比如：先用滑板代替步行和跑步，再用自行车代替滑板
❷ 确保当前正在使用的方案可以达成某种 ”小的目标“、”小的飞跃“。比如：踩着滑板前进，轻松超越 60% 的跑步者；骑自行车则轻松超越 60% 的滑板使用者
❸ 先简单粗暴地把方案 ”跑通“，再设法让它变得 ”好用和优雅“：比如为了给自行车加速，可以先捆绑自动蹬车的电动机，显著降低骑行时的体力消耗，未来条件允许时再改造或置换为摩托车。
❹ 改造当前方案的过程中，为了不忘记当初想要的成果，应保留对关键成果的明确承诺或明显暗示（通俗地说就是不忘初心）。比如：改造自行车的方向不止一种，可以让它更快，也可以让它更 ”酷“；如果想要的成果是更快，就不要花太多时间在单车的外部装饰上面，除非这种装饰能给使用者 ”加快速度“ 的心理暗示
❺ 前期重在培养挑战小目标的习惯，中、后期再挑战关键成果。比如：滑板和自行车不适合挑战上百公里的行程，但它们能培养控制感，体验加速行进的效果，帮自己逐步建立长途旅行的信心
以上就是实践卢曼笔记法过程中的 ”最小可行方案“ 操作原则介绍。考虑到每个人习惯使用的工具和流程千差万别，全文中没有谈到任何与笔记工具或日常记录流程相关的细节，而是采用类比的方式来说明。
为什么以 ”自行车“ 等交通工具为对象来作比喻呢？这并不是偶然的。
按我的理解，卢曼卡片盒是一种思维辅助工具（Tools for Thought），一种在抽象的思维空间中构建高楼大厦的脚手架（Scaffolding），更进一步，借鉴乔布斯在《遗失的访谈》节目末尾阶段的观点：我相信卢曼卡片盒也可以被看作人类头脑的自行车——在没有使用自行车之前，人类行进速度落后于许多野生动物，秃鹫独占鳌头；而一旦学会使用自行车，在消耗同样体能的前提下，人类的行进速度瞬间超越秃鹫，遥遥领先。
在后续分享中，我会继续介绍其它更具体的操作原则，比如：注意力聚焦，保持主画面稳定，笔记边界感分明，交互简洁不浮夸，待办/完成左右分区，以创作主题为锚点等等… 敬请期待后续更新 🔜
✪ 前情回顾 - https://pimgeek.com/blog/intro-to-the-working-logics-of-luhmann-zettelkasten-note-system
via 学习者的个人主页 (author: pimgeek)
上一次连载探讨了卢曼卡片盒背后的 “角色分工”，并站在个人创作者的视角上描述了一种典型的角色分工：以卡片笔记作为 “食材” 和 “调味料”，以卡片盒作为 “原料仓库”、“菜谱经验库” 和 “实验平台”，创作者自己扮演 “厨师” 不断制作推陈出新的 “饭菜”———文章作品 😃
需要说明的是，以上只是无数可行的角色分工中的一种，或者说是我结合自身创作经历最容易联想到的一种。对于复习备考、教学科研类工作、团队协作项目乃至我从未接触过的工作类型，也许会有更合适的角色分工。
无论具体工作类型如何，我相信它们都包含一定的创造性思维成分———比如说：在自己头脑中建立起灵活可靠的 “脑回路”、在教学实践中设计出启发思考和参与的活动、在学术社区中发表一种新颖的思维模型或解释框架等等
接下来开始介绍卢曼卡片盒的操作原则，介绍这些原则可能是最具挑战性的部分，因为我自己仍处在创作内容连载的过程中，如果我的总结与实际情况不符，就会出现这些问题：
❶ 操作原则高于实际，连我自己都做不到，结果可能为了死守原则，后续连载文章都写不出来了
❷ 操作原则低于实际，假如我没能把握卢曼笔记法的核心思想，只是展现了一些粗浅的理解，那么很可能会误导自己和读者，让大家误认为卢曼笔记对创作活动的帮助仅此而已
为了避免上述两种偏差，同时减少 “追求一步到位” 的纠结，我优先引入一个最为基础的操作原则，即 “最小可行方案” 原则，它的英文表达是 “Minimum Viable Plan”，简称 MVP。用 Emoji 表情图来展示，就是 🛹 ➠🚲 ➠ 🏍 ➠ 🚗
理解和实践最小可行方案原则，可从以下几方面入手：
❶ 优先选择 ”稍微努力就能够到“ 的改进方案，而不是 ”憋大招“。比如：先用滑板代替步行和跑步，再用自行车代替滑板
❷ 确保当前正在使用的方案可以达成某种 ”小的目标“、”小的飞跃“。比如：踩着滑板前进，轻松超越 60% 的跑步者；骑自行车则轻松超越 60% 的滑板使用者
❸ 先简单粗暴地把方案 ”跑通“，再设法让它变得 ”好用和优雅“：比如为了给自行车加速，可以先捆绑自动蹬车的电动机，显著降低骑行时的体力消耗，未来条件允许时再改造或置换为摩托车。
❹ 改造当前方案的过程中，为了不忘记当初想要的成果，应保留对关键成果的明确承诺或明显暗示（通俗地说就是不忘初心）。比如：改造自行车的方向不止一种，可以让它更快，也可以让它更 ”酷“；如果想要的成果是更快，就不要花太多时间在单车的外部装饰上面，除非这种装饰能给使用者 ”加快速度“ 的心理暗示
❺ 前期重在培养挑战小目标的习惯，中、后期再挑战关键成果。比如：滑板和自行车不适合挑战上百公里的行程，但它们能培养控制感，体验加速行进的效果，帮自己逐步建立长途旅行的信心
以上就是实践卢曼笔记法过程中的 ”最小可行方案“ 操作原则介绍。考虑到每个人习惯使用的工具和流程千差万别，全文中没有谈到任何与笔记工具或日常记录流程相关的细节，而是采用类比的方式来说明。
为什么以 ”自行车“ 等交通工具为对象来作比喻呢？这并不是偶然的。
按我的理解，卢曼卡片盒是一种思维辅助工具（Tools for Thought），一种在抽象的思维空间中构建高楼大厦的脚手架（Scaffolding），更进一步，借鉴乔布斯在《遗失的访谈》节目末尾阶段的观点：我相信卢曼卡片盒也可以被看作人类头脑的自行车——在没有使用自行车之前，人类行进速度落后于许多野生动物，秃鹫独占鳌头；而一旦学会使用自行车，在消耗同样体能的前提下，人类的行进速度瞬间超越秃鹫，遥遥领先。
在后续分享中，我会继续介绍其它更具体的操作原则，比如：注意力聚焦，保持主画面稳定，笔记边界感分明，交互简洁不浮夸，待办/完成左右分区，以创作主题为锚点等等… 敬请期待后续更新 🔜
✪ 前情回顾 - https://pimgeek.com/blog/intro-to-the-working-logics-of-luhmann-zettelkasten-note-system
via 学习者的个人主页 (author: pimgeek)
Generate Image with Github CI Action for free
In teaching myself how to use Github Action for CI, I am curious if one can just use this for some customized task. Github Action is designed for CI and CI needs computation resource. Each Github account has 2000 minutes computation for free.
via Haoxiang’s Blog (author: Haoxiang Li)
In teaching myself how to use Github Action for CI, I am curious if one can just use this for some customized task. Github Action is designed for CI and CI needs computation resource. Each Github account has 2000 minutes computation for free.
via Haoxiang’s Blog (author: Haoxiang Li)
Weekly Issue 2024-01-21
文章 链接到标题 技术 链接到标题 #!/usr/bin/env docker run · GitHub 作者利用 [[shebang]] 机制，在 Dockerfile 中直接通过 env 来查找 Docker 命令，可以达到 ./Dockerfile 直接构建并运行容器的效率。 个人觉得这是邪教。 2023 开发者生态系统现状信息图 | JetBrains: Developer Tools for Professionals and Teams [[JavaScript]],[[python]],[[HTML]] 被使用次数最多，[[Rust]] 仍是最受欢迎的，并且有 1/6 的 Go 开发者想要采用 Rust。 性别分布中，男性 91%，女性 5%。77% 的开发者已经采用 ChatGPT，46 的开发者采用了 Github Copilot。 74% 的人经历过倦怠，针对倦怠的改善方式中：看到自己的工作成果发挥作用、涨薪、工作过程中的乐趣、来自同事的感谢，是最有效的。 每 10 位开发者中有不到 3 位 QA 的占比达到了73%。 How fast is your shell? - by Thorsten Ball - Register Spill [[shell]] 的启动速度是非常重要的，我是一个重度的 tmux 用户，每天会打开无数次的 shell，前阵子还吐槽自己的 zsh 速度很慢，修复了一圈之后现在在 80ms 左右，可以接受的范围。
via Yiran's Blog
文章 链接到标题 技术 链接到标题 #!/usr/bin/env docker run · GitHub 作者利用 [[shebang]] 机制，在 Dockerfile 中直接通过 env 来查找 Docker 命令，可以达到 ./Dockerfile 直接构建并运行容器的效率。 个人觉得这是邪教。 2023 开发者生态系统现状信息图 | JetBrains: Developer Tools for Professionals and Teams [[JavaScript]],[[python]],[[HTML]] 被使用次数最多，[[Rust]] 仍是最受欢迎的，并且有 1/6 的 Go 开发者想要采用 Rust。 性别分布中，男性 91%，女性 5%。77% 的开发者已经采用 ChatGPT，46 的开发者采用了 Github Copilot。 74% 的人经历过倦怠，针对倦怠的改善方式中：看到自己的工作成果发挥作用、涨薪、工作过程中的乐趣、来自同事的感谢，是最有效的。 每 10 位开发者中有不到 3 位 QA 的占比达到了73%。 How fast is your shell? - by Thorsten Ball - Register Spill [[shell]] 的启动速度是非常重要的，我是一个重度的 tmux 用户，每天会打开无数次的 shell，前阵子还吐槽自己的 zsh 速度很慢，修复了一圈之后现在在 80ms 左右，可以接受的范围。
via Yiran's Blog
利用 Cloudflare Worker 搭建自定义的 Memos WebHook Service
Memos WebHook 引入的新场景
之前写过一篇文章解释 WebHook 基本原理和应用场景的：理解 WebHook，对于 WebHook 的应用场景抽象描述就是：现在有系统 A 和系统 B，B 系统关心 A 系统内部的某些事件 E，B 系统会根据事件 E 的具体状态或数据进行其业务逻辑。
查看全文
via Shadow Walker 松烟阁 (author: edony)
Memos WebHook 引入的新场景
之前写过一篇文章解释 WebHook 基本原理和应用场景的：理解 WebHook，对于 WebHook 的应用场景抽象描述就是：现在有系统 A 和系统 B，B 系统关心 A 系统内部的某些事件 E，B 系统会根据事件 E 的具体状态或数据进行其业务逻辑。
查看全文
via Shadow Walker 松烟阁 (author: edony)
聊一下 Java 的日志系列三
上周因为一些事情没有更新在这里，是因为新电脑还没到，手头没有把移动硬盘里的 time machine 恢复出来的机器，所以单独更了一篇在新建的一个 cloudflare page 服务上，总体体验还可以，就是有个小点后面可以讲一下，继续完善下 Java
via Nicksxs's Blog
上周因为一些事情没有更新在这里，是因为新电脑还没到，手头没有把移动硬盘里的 time machine 恢复出来的机器，所以单独更了一篇在新建的一个 cloudflare page 服务上，总体体验还可以，就是有个小点后面可以讲一下，继续完善下 Java
via Nicksxs's Blog
Leetcode 25 Reverse Nodes in k-Group 题解分析-再解分析
上一次主要是给了一个解题方案，没有具体讲解，这次又做到了就来看下几种方案，链表转置一直是我比较疑惑的问题，特别是边界处理，而这个问题要把难度加大了
我先讲一下我一开始的思路和解题方法，首先就是写一个转置方法，就处理 k
via Nicksxs's Blog
上一次主要是给了一个解题方案，没有具体讲解，这次又做到了就来看下几种方案，链表转置一直是我比较疑惑的问题，特别是边界处理，而这个问题要把难度加大了
我先讲一下我一开始的思路和解题方法，首先就是写一个转置方法，就处理 k
via Nicksxs's Blog
1705825109676.png
84.5 KB
利用Github Action自动检测项目中 yaml 或 json 的语法
我最近开源的 awesome-ops 项目，其中的项目分类及表格数据的生成，依赖 yaml-readme 这个项目所实现的 action 来完成。因此，其中的项目都是基于大量 yaml 来收集，在于 yaml 打交道的过程中，不可避免的会遇到错漏的情况，这个时候，增加一个 yaml 语法检测的 action 就势在必行了。当我有了这个念头之后，就针对这方面的 action 进行了一大波调研，发现市场上有许多对应的 action，真正好用的并不多，因此，在花了一两个小时之后，才发掘到了本文将要介绍的 action，如果你也有此类场景与需求，那么就往下读吧。
via 二丫讲梵
我最近开源的 awesome-ops 项目，其中的项目分类及表格数据的生成，依赖 yaml-readme 这个项目所实现的 action 来完成。因此，其中的项目都是基于大量 yaml 来收集，在于 yaml 打交道的过程中，不可避免的会遇到错漏的情况，这个时候，增加一个 yaml 语法检测的 action 就势在必行了。当我有了这个念头之后，就针对这方面的 action 进行了一大波调研，发现市场上有许多对应的 action，真正好用的并不多，因此，在花了一两个小时之后，才发掘到了本文将要介绍的 action，如果你也有此类场景与需求，那么就往下读吧。
via 二丫讲梵