欢迎来到我的博客！我是一名拥有10年以上经验的系统架构师。在这个博客中，我将与大家分享我在C#、JavaScript、Python、Docker、SQL和Rust等领域的知识与经验。 作为一名技术爱好者，我相信技术的力量可以改变世界。

本文对比分析了传统流处理框架(如Spark/Flink)和新兴WASM方案的差异，探讨了技术选型的关键因素。通过性能测试数据、架构对比和实际案例，揭示流处理技术从集群调度到边缘计算的演进路径。（关键词：流式计算、WASM、性能优化、边缘计算）

本文深入剖析了ZeroMQ中REQ/REP通信模式的本质特性与实用技巧。不同于传统RPC，REQ/REP通过严格的锁步通信机制（REQ必须send→recv，REP必须recv→send）保证了基础的请求-响应语义。文章对比了本地调用、传统RPC与REQ/REP的核心差异，强调分布式环境下必须显式处理网络延迟、消息顺序和错误恢复等特性。通过Rust实现示例，详细讲解了rcvhwm、sndtmo等关键参数的调优策略及其在不同场景（微服务、物联网、金融系统）下的最佳实践。

本文深入探讨了ZeroMQ在分布式日志采集系统中的关键作用。通过分析消息队列的五大核心要素（缓存、水位线、超时、丢弃策略和Linger机制），揭示了ZeroMQ如何解决日志突发流量、生产消费解耦等典型问题。文章提供了基于Rust的ZeroMQ配置示例，包括缓冲区设置、高水位线调整和超时控制等关键参数，并针对不同场景（高吞吐、低延迟、高可靠性）给出了优化建议。最后指出，通过合理配置ZeroMQ参数，可以构建一个既轻量级又高性能的日志采集管道。

告别单例模式的锁焦虑！Rust的`OnceLock`像轻巧的守门人，用原子操作解决初始化竞态，无需`Arc`的沉重。更惊艳的是编译期的`Send+Sync`机制：当多个线程通过`get_instance()`访问数据库连接时，Rust编译器会严格检查对象是否满足线程安全约束——就像给每个共享对象颁发"跨线程通行证"。对比Java/C#的运行时锁，Rust在编译期就捕获线程安全问题，零成本抽象+错误前置的设计，让机器替你熬夜排查错误。单例模式从未如此优雅安全！

为什么选择RocksDB做配置存储？它比文件更可靠（原子写入/无锁读取），比数据库更轻量（嵌入式进程内运行）。本文带你穿透核心机制：- **LSM树魔法**：MemTable+SSTable+WAL如何实现高吞吐写入- **三放大困境**：写/读/空间放大的精妙平衡术- **键排序实战**：时序场景下100倍查询加速的密钥- **嵌入式优势**：告别独立数据库，拥抱低延迟数据处理无论存储配置还是时序数据，一文掌握RocksDB的高效之道！

当你需要轻量级、高性能的进程间通信时，ZeroMQ就像代码世界里的瑞士军刀。今天我们一起探索如何在Rust生态中使用这把利器，感受它如何在不同操作系统间架起通信的桥梁。就像搭建乐高积木，用zmq crate可以组合出各种通信模式。这种架构的精妙之处在于彻底解耦了数据生产者和消费者——发布者无需知道谁在接收，订阅者也不必关心消息来源，双方如同独立运转的齿轮，通过ZeroMQ的管道默契协作。

ZeroMQ是一个智能消息传输层，抽象了传统socket编程的底层细节，提供高级消息模式。它自动处理消息传递，支持多种通信模式：请求-回复模式（REQ-REP）实现同步RPC调用，发布-订阅模式（PUB-SUB）支持一对多广播，管道模式（PUSH-PULL）适合并行任务分发。这些模式通过简单API实现组件解耦，开发者无需关注通信细节即可构建分布式系统。ZeroMQ高效处理消息序列化、路由和重试，使系统组件可替换如积木，是构建现代分布式架构的理想中间件选择。

Rust 语言在跨平台开发中，尤其是交叉编译时，常面临依赖问题。vendored 特性作为 Cargo 生态系统中的工具，能够有效解决这些问题，特别是在处理系统库如 OpenSSL 时。vendored 特性通过将依赖库打包到项目中，避免了对外部系统库的依赖，从而解决了交叉编译中的兼容性和版本一致性问题。例如，在 macOS 上交叉编译 Linux 目标时，启用 vendored 特性后，openssl crate 会从源代码编译 OpenSSL 并静态链接到项目中，避免了 OpenSSL 库找不到的问题。

通过这次实践，我深刻体会到了数据库实体表重构的重要性和挑战性。这个过程要谨慎操作，步步为营，多做接近于用户场景的测试，一定不要造成数据丢失（注意，是一定不要，因为一旦造成数据丢失，不但造成的影响很大，找回数据的成本也是很高昂的）。每一次困境，对我们来说都是一次成长的机会，这次也不会例外。2024.3.31重庆，渝北。

docx库通常虽然提供了一些抽象层，使得开发者可以在不了解Word文档内部复杂结构的情况下，也能读取和修改文档的基本内容，但是，如果我们需要处理更复杂的任务，比如修改特定样式的文本、处理文档的页眉页脚、或者处理文档的元数据等，那么对Word文档的内部结构有更深入的了解就会非常有帮助。别忘了，我们是要挑战这万分之几的出错率，对word文档的了解，应该是必须的。word到pdf的转换看起来已经成熟，但是在特定的业务场景下，现有的转换仍然有万分之几的出错率，这个数字，在苛刻的商业环境下，也是不能接受的。

在我的笔记系统中，我使用Docker Compose将各个微服务编排在一起，形成了一个完整的应用程序。优化是一个持续的过程，我将继续关注最佳实践和技术发展，以进一步提升系统的稳定性、性能和安全性。的开发是基于微服务的思想，但是在服务的配置和编排上感觉还是不太合理，具体来说，在开发上的配置和在生产上的配置差别太大。因此，我在周末重构了项目结构和docker-compose.yml，本文将分享我在这一过程中的经验，并探讨如何进一步优化基于Docker Compose的微服务架构。请关注我，不要错过更新哟。

如果你稍微留意一下todo list v0.0.3的代码，你会发现它是比较臃肿的，因为，这个版本只是通过组装AI写出来的代码，完成了功能的开发。说“能”，我想不用我说，很早就有人用AI生成正则表达式的相关功能代码，从这个角度来说，AI 已经替代了程序员的工作了。

只有开发者对代码的不断觉察和理解，才会产生重构代码的念头。因此，驱动重构的应该是开发者本身的认知，而不是线上产品的反馈或者测试的反馈。以上面的代码为例，对属性名称的重构/修改，也是基于对代码的察觉。之前的命名在当前的业务理解上下文中过于模糊，甚至还有歧义。导致这种现象的原因并不是因为我之前对这些属性的命名过于草率，而是因为之前我还没确定生成的代码中要使用vue的mixins技术。为什么我要用觉知这个词呢，因为就算我不修改上面的命名，就现阶段来说，代码也是能够正确运行的。

在数据管道中，staging指的是将数据从源系统移动到目标系统之前的中间步骤。在staging过程中，数据会经过一系列的转换和处理，以确保数据的质量和准确性。staging可以包括数据清洗、格式转换、数据合并等操作，以便最终将数据加载到目标系统中。这里面既有函数式编程的思路，也有系统数据流分析的影子。而今天在这个项目的代码重构中，再次体验到了这个原则。实际上，在我之前设计的bisheng-cli的项目中也成功使用了这个原则，只是现在对这个原则的体验更加强烈。

我说的体验感不好，不是在于AI的回答结果的正确率，而在于我发现我问过多次类似于“Rust中如何使用正则表达式”之类的问题。这也是我不断向我的开源项目。虽然AI在编程中涉及的方面有很多，但我在Rust的学习和使用中，主要通过AI来生成代码，因此，我的体验也主要围绕代码的生成和使用上来阐述。当前AI在编程开发方面的使用越来越广泛，我在Rust的学习中，也刻意加重了对AI的使用。在代码的生成上，随着使用的深入，我提的问题逐渐从之前的偏重功能到偏逻辑。当然，这只是我的个人想法，我也真诚的接受各位大神的意见和建议。

我使用Rust开发将近一年了，每次我读到Rust的核心概念中包含了“模式匹配”时，心里就会不由冷笑，因为我对模式匹配的理解仅限于对枚举值，Result和Option的简单处理，没有觉得它有好高级的地方。但是，最近AI给我提供的一个Rust的例子代码，着实把我惊艳到了。

一个简单的全栈功能闭环基本完成。既然是开源，因此，这里有必要分享一下部署结构，希望能够获得小伙伴们的反馈。后期还会增加其它服务来实现笔记数据的处理。欢迎大家评论区讨论。note_book_api: 负责笔记系统数据处理的后端应用。api-gate: 负责路由和访问权限验证的后端应用。目前整个系统采用docker容器来部署。auth2: 负责用户登录和注册的后端应用。auth_app: 登录/注册的前端应用。web_app: 笔记系统的前端应用。请关注我，不要错过更新哟。

在开发我的笔记系统时，我遇到了一个问题。问题是，在api-gate服务中，我需要验证用户的access_code，但是access_code的生成逻辑是在auth2服务中实现的。这个问题从架构设计的层面上看，就是一个高耦合度问题。高耦合度会给代码的扩展代码麻烦，并给未来的系统维护带来隐患。

在Rust中，数组的长度必须是常量，但是我们可以通过Vec提供的功能来实现“动态”初始化这个“常量”。

在Rust中，Serde几乎成了JSON数据解析的事实标准，例如tokio、Actix等网络库都采用Serde来处理JSON的序列化和反序列工作。Serde简化数据序列化和反序列化的过程，提供类型安全和错误处理，支持自定义序列化和反序列化逻辑，它的强大功能使它得到了广泛的应用和支持。

系统的开发，测试和部署离不开环境变量，今天分享在Rust的系统开发中，使用dotenvy来读取和使用环境变量。

我们写的代码主要有两部分，第一部分是正常的业务流程，第二部分是错误处理。 通常情况下，这两部分代码不是分开的，而是杂糅在一起的。 这让我们后期维护正常的业务逻辑非常头疼。今天分享的是Rust语言中的错误处理的魔法， 它可以帮助我们写代码时，将错误处理的“体积”压缩到最小，同时还保证错误分支能被一个剩的处理掉。

上上周了吧，写了一篇Rust-后端服务调试入坑记，现在看来那个坑根本就不算什么。这次这个坑才是真正的坑。到写文章这一刻，我只是确定了复现这个问题的最简单代码（参考目录验证4：基于Debian:11镜像创建最简单Rust的http服务）。但依然没有找到解决这个问题的办法。现在把这个问题以及我的验证过程整理出来，以便路过的朋友了解，我相信肯定有大神知道其中的缘由和解决办法。还望各位大神留言赐教。结论：Rust创建的api部署到网络模式为bridge的Docker容器中，不能从宿

上面这个图画出来用了小半天时间，目前已经实现了资源服务器，认证服务器，token存储服务器和API网关，看似比较顺利，但不知不觉渐渐进入深坑。这个坑是怎么形成的呢？正好前几天在知乎上看见有人提问后端开发是否只是CRUD，我觉得这个问题挺有意思的，因此，决定休息的时候画一张图来展示这个坑的形成过程，正好换换脑子。

我们描述了转换的场景，具体的转换步骤和转换的应用方式。这里的场景是数据集和本地类型之间的数据转换。类似的场景还有很多，只要涉及到不同的上下文，数据转换的需求就会出现。使用Rust的`std::convert::From` trait，实际上就是在实践“关注点分离”的设计模式，它会大大提升我们代码的可维护性和可扩展性，个人认为这是写好Rust代码的重要方法之一。

Rust的所有权机制，数据允许通过借用的方式，在函数的上下文中传递数据。如果离开数据作用的有效范围，这个借用就会失效，编译就会报错。这也是我们不会将借用(引用）作为函数的返回值的原因。

这几天我的笔记系统开发工作进入了搬砖期，前端基于Yew，后端基于Rocket。关于Rocket搭建Restful服务，官方也有介绍，感觉很多细节不到位。因此我打算花2到3天的时间来整理一下，也算是对自己的一个交代。对于有一定经验的开发者来说，他们可能已经熟悉了 Restful 开发中的基本 HTTP 方法，如 GET、POST、PUT 和 DELETE。然而，从项目实战的角度来说，这些方法的细节处理是不容忽视的。在项目开发中，我们必须关注文件夹结构的组织、参数的获取、返回值的处理和日志处理等方面的问题。

SSR（Server-Side Rendering）具有许多优势，其中之一就是能够在服务器端生成页面，从而提高整个页面的加载速度。在Yew SSR开发模式中，我们可以使用use_prepared_state宏在服务器端获取数据并生成Html返回到客户端。官方提供了相应的例子供参考。然而，如果在客户端修改并提交了该数据，我们需要如何刷新之前在服务器端生成的数据呢？官方未提供相应例子，经过多次实验后，以下代码可以实现该功能。

昨天解决了[焦点问题](https://blog.csdn.net/firefox1/article/details/133276666?spm=1001.2014.3001.5501)，今天就开始搬砖了。本以为可以一帆风顺，但是还是遇到了几个问题，不过还好，都被一一解决，这里我分享一下JsValue的转换体验以及关键字`as`的使用浅析。

前些天，写了[探索Rust编写基于web_sys的WebAssembly编辑器：挑战输入光标定位的实践](https://blog.csdn.net/firefox1/article/details/133180584)，经过后续的开发检验，我发现了一个问题，就是光标消失了。为了继续输入，用户需要再次使用鼠标点击。现在我已经弄清楚了导致这个问题的原因，即需要找到text node来设置光标。

今天周日，搞定了家里装修的一件事情，周末的事特别多，总算在10点的时候，解决了昨天那个输入焦点设置失败的问题。在[探索Rust编写基于web_sys的WebAssembly编辑器：挑战输入光标定位的实践](https://blog.csdn.net/firefox1/article/details/133180584?spm=1001.2014.3001.5501)中，我们总结了设置光标的位置

昨天，我对过去[两周的工作进行了总结并上传了源代码](https://caozy.blog.csdn.net/article/details/133127078)。而今天，我又踏入了一个对我来说既熟悉又陌生的领域：编辑器。我对编辑器的熟悉来自于多年来使用他人开发的编辑器的经验，但对于自己开发编辑器这件事情，我感到陌生。想自己开发一个编辑器，我的感受，就一个字“难”，但我很享受这个挑战。这也让我反思了一下，这些年来，我到底写了多少有价值的代码呢？

资源中的代码非常简洁易懂，虽然离商用场景还有一段距离，但是涵盖了前端的组件搭建、事件通信和反向代理，以及后端的Restful API的路由、功能实现和数据库访问。此外，还包括了postgres数据库的初始化脚本和docker部署脚本，方便您快速搭建环境。

Yew是一种用于构建现代Web应用程序的Rust框架，其计目标是提供一种安全、高效、易用的方式来构建Web应用程序。Yew基于WebAssembly（Wasm）技术，将Rust代码编译为能在浏览器中运行的Wasm二进制文件。这使得Yew能够充分利用Rust的内存安全和并发性能优势，同时保持前端开发的灵活性和易用性。最后，Yew采用了类似于React的组件化开发模式，这一点使其能容易被接受，毕竟Reactjs的开发人员很多，其中也包括我在内。

今天的工作重点又从后端API转移到了前端Yew的开发中。目前已经完成了前端到后端的数据持久化，以及后端到前端数据展示。现在基本上打通了基于Rust的全栈链路，当然还有很长的路要走，至少后面是1到100的问题了。在这几天的开发工作中，类型的转换无处不在，不同的类型意味着不同的逻辑上下文，而数据必定是在不同的逻辑上下文中流动以实现特定的功能。我们这里提到了类型和逻辑上下文，这和类型的一等公民地位有啥关系呢？

随着项目的进展，关于Rust的故事又翻开了新的一页，今天来到了服务器端的开发场景，发现错误处理中的错误类型转换有必要分享一下。Rust抽象出来了Result，T是返回值的类型，E是错误类型。只要函数的返回值的类型被定义为Resut，那么作为开发人员就有责任来处理调用这个函数可能发生的错误。通过Result，Rust其实给开发人员指明了一条错误处理的道路，使代码更加健壮。

Yew的SSR应用开发的故事一幕接一幕，就在前天，我解决了一个看似棘手的问题：[如何从客户端的wasm文件中将数据成功地传递给后端](https://caozy.blog.csdn.net/article/details/132910180)。然而，人生如戏，新的问题又悄然而至。

今天是周六，周末的事情感觉比平时都多，所以也没有写代码。所以打算结合这几天开发Yew应用的经历，聊聊Yew的Hydration。

关于条件编译，我的记忆是10多年前，写C#的时代了，最近10年写Python和Javascript代码，虽然Javascript中也可以通过插件实现条件编译的效果，但是用起来太憋足了。

Rust的所有权问题，在我学Rust的时候就跳过了，因为我知道这玩意儿没有场景就不好理解。没想到场景很快就出现了。在开发Yew应用组件的时候，涉及到了事件，闭包，自然就引出了所有权问题。话不多说，下面让我们直接进入代码场景，去体验并了解Rust的所有权机制吧。