分享有趣的、贴近生活的CS知识

主备服务器部署：主备服务器均运行业务程序和数据库实例。数据实时同步：使用 SQLite 文件同步或 MySQL 主从复制保持数据一致。高可用切换：利用 HAProxy 或 Keepalived 实现主备服务器的自动切换。此架构适合中小型应用，能够显著提高系统的容灾能力。如果需求更复杂（如高并发、高吞吐量），可以结合分布式数据库和更高级的负载均衡方案。

面向不确定性、不一致性和不可用性进行数据建模，需要对系统的核心和非核心数据进行合理分离，并采用读写分离、读写缓存等策略进行优化。这种设计思路不仅能够提升业务的可用性，还能为系统扩展性和性能优化提供良好的基础。在实际应用中，通过精细化的缓存策略和读写分离的配置，可以实现更高效、更稳定的数据服务，为用户提供更好的体验。我感觉这也是必然之路，现在的所谓稳健、也是基于一个不稳定的假设，例如阿里云华为云aws都出现过大规模不可用，一些头部应用也出现过业务不可用，尤其是一些核心业务。

昨天（2024/11/18)碰到这么个问题，因为要控制成本，公司只愿意出两台服务器（很小的盒子）部署业务，采用传统的主备模式。这其中就包括Mongodb数据库，最稳固的方法当然是采用官方推荐的最低3台。但没办法，只能是模拟部署了。

Node.js的模块化系统在历史上经历了从CommonJS到ESM的演变，但这种演变带来的兼容性问题和复杂的文件扩展名规则，给开发者带来了很多困扰。而Deno通过采用统一的ESM模块化方案，严格遵循Web标准，彻底解决了这些问题。Deno的2.0版本更是通过deno.json等配置进一步提升了开发者的体验。对于前端和全栈开发者来说，Deno提供了一种现代化、简洁而统一的开发体验，不再需要为模块化的复杂性而烦恼。它让开发者能够更加专注于代码本身，而不是被各种历史遗留的模块化问题所困扰。

Deno2.0至少是目前最佳的Websocket全栈应用js运行时，本文就介绍下如何用它快速构建Websocket应用：服务端应用+客户端应用，并于Nodejs进行对比下-突出下其简洁性和一致性

前面的内容介绍deno的基础，这篇文件主要讲如何利用deno快速创建http服务端应用，包括两个场景：restful接口、静态文件托管

抛弃动态路由参数，改为固定路径的设计，可以简化微服务 API 的实现，提高安全性和可维护性，并更好地与其他系统进行对接。在微服务架构下，API 的清晰简洁显得尤为重要，而固定路径的设计理念则提供了一种更加一致和直观的方式来构建 RESTful API。这种设计不仅提高了系统的安全性，还使得 API 的管理和维护变得更加高效。同时，固定路径的结构使得开发者能够更加专注于业务逻辑的实现，而不是在复杂的路径匹配和解析上浪费精力。因此，在考虑到微服务架构的扩展性和可维护性时，固定路径的设计显得尤为合适。

如果你想要快速、高效地对模型进行微调，且用户反馈较为简单（例如只选择最佳答案），LoRA是一个不错的选择。如果你需要在复杂的交互环境中不断优化模型性能，且用户能够提供详细的反馈（如评分），那么PPO是更合适的选择。当数据规模较小时，LoRA 更加高效；而在数据规模较大时，PPO 更能发挥其优势。根据数据规模（1k-10k、10k-50k、50k+），选择合适的微调方法可以最大化地提高模型的性能和训练效率。

今天打包Deno发现构建物接近100M，为什么会这么大呢？当我深入了解后，发现这很合理。从此运维负担大大减轻了，部署不再需要node/docker

Deno 使用了“显式权限”模型，默认情况下，所有对文件系统、网络和环境变量等关键资源的访问都被禁止，开发者需要通过命令行参数或特定 API 明确授予这些权限。本文将介绍权限的种类，以及几种配置权限的方法，一次帮你搞懂它并学会用

在前端全栈开发中，工具的不断演变让开发者们始终在寻找更高效、更现代化的解决方案。Deno2.0的近期的发布让它在性能和兼容性方面大幅提升，而Bun则凭借其高效的运行速度和友好的开发体验获得了广泛关注。那么，Deno 2.0和Bun到底谁更胜一筹？本文将对这两个工具进行理性对比，并探讨各自的优势与适用场景。

作为ToB项目身份认证的完结篇，带你掌握如何利用ldapjs库与 Windows AD 进行交互。并且介绍了cn带中文时会遇到的错误及应对的补丁方法，附带生产可用的完整服务类代码

开发时遇到个很奇怪的问题：音视频播放时长变成无限。最终发现是缺少了一个比特，原因是content-range的起始位置，都是包含的，这个反通用模式的坑不知道你踩到过没有呢

Nix 是一个独特的包管理工具和构建系统，它采用了一种声明式的方法来管理软件包和运行环境。你只要定义好需求，它会帮你下载、构建和管理这个环境，让它与你声明的需求保持一致

使用docker compose插件运行容器，对于本地开发来说是更轻便的选择。本文主要是详细的介绍了使用docker创建meteor项目的准备工作和步骤，并解析了基于容器化的meteor项目架构，介绍了一下最佳实践。

DDP (Distributed Data Protocol) 是Meteor框架中使用的一种简单而强大的发布/订阅协议，它允许客户端和服务器之间进行实时数据同步，是Meteor实现实时应用的核心技术之一。由于后续需要实现非js的Native版本，同时了解它有助于更好的使用meteor，所以提前介绍下

在Meteor框架中，EJSON（Extended JSON）是一个扩展了标准JSON的库，旨在支持更多的数据类型。标准JSON仅支持字符串、数字、布尔值、数组和对象等基本数据类型，而EJSON允许开发者在Meteor应用中传输更复杂的数据类型，例如DateBinary数据，甚至是自定义对象，这使得Meteor在客户端和服务器之间传递复杂数据变得更加便捷和高效。

本文将介绍两种不同的方式来搭建 Meteor 的开发环境：通过全局安装 Meteor 工具、使用 Docker 镜像，以及创建和运行一个简单的 Meteor 项目。而配合docker使用也是我比较推荐的，因为版本升级时不用清理残留在电脑里的老旧资源文件，而且部署和构建都能保证环境一致

前后端分离是一种将应用程序的前端（用户界面）和后端（业务逻辑和数据处理）解耦的架构设计，虽然有不少公司号称前后端开发，但实际上却是通过接口将前后端耦合在一起，graphql试图改善，但或许我们可通过有限的共享来加快开发，简化一些额外的工作。

Meteor3.0的发布-订阅模型使得开发实时应用非常高效。服务器端可以通过简单发布或自定义发布来灵活地控制数据的发布，客户端则可以通过订阅获取数据，并通过等机制实现自动化的 UI 更新。这种架构能够确保客户端总是与服务器端的数据保持同步，不需要定时或者在某个时机去获取最新数据。

Meteor 3.0中引入的异步支持和callAsync方法，使得开发者在处理前后端数据交互时更加轻松，本文简单介绍一下它的前后端用法

写给前端的混合全栈之路Meteor篇，这是一个很小众的框架，但是野心很大，尤其是3.0版本推出了，有必要系统的介绍下。本文主要介绍它的核心模块-minimongo，一个前后端公用的数据库门面库，从而保持了前后端数据操作相关代码的一致性

Meteor全栈框架3.0版本终于稳定下来了，它的效果约等于webpack+vue+express+socket.io+mongodb+npm+uniapp，学一个搞定全套，值得学习了解下，最后找到适合于自己的技术栈。

windows下删除了docker镜像和无用容器，虚拟盘占用依旧很大甚至上百G怎么办？

今天教一个魔法，使用javascript远程唤醒别人的电脑~恶作剧别说我教的哈

Node -> Oden -> Deno，感觉不能替代nodejs的前端部分，但真的很适合自己做项目了呢

通过ldap操作AD域时，如果进行密码修改等敏感操作，需要通过ssl加密通道ldaps，本文将教你学会如何部署，掌握让windows server一分钟支持ldaps的技能。

有时候发版本给测试，发现问题往往第一印象是我的问题。看我如何一点点的”教“它背锅，同时复习网络知识

ToB的项目中，应用与AD域对接大多数情况下是绕不开的，作为偏前端的Noder，我们需要浅浅的了解一下