技术链接、资讯与社区分享流
技术圈正在讨论的分享链接。
三体问题，其实可以看作是 N 体问题的一个特例，而所谓 N 体问题，则是指 N 个参照值相对一致的天体，仅在万有引力的作用下会呈现出什么样的运动规律。该问题最早由天才数学家希尔伯特教授，在 1990 年的全球数学大会上提出，是目前公认的人类科学界最难的 23 道数学题之一。如果你无法理解这个难度，请允许我找一个更有名的问题——费马大定理作为参照。事实上，早在 1687 年近代物理学之父牛顿，第一次提出了三体问题。此后的三百余年里，三体问题更是串联起无数如雷贯耳的名字：欧拉、拉格朗日、庞加莱、希尔伯特、开普勒…等等。
在这个过程中，我最大的收获是学会了如何用编程控制米家设备。尽管现在智能家居的交互场景还相对有限，但就像 ChatGPT 一样，当你意识到 AI 正式进入一个新阶段的时候，一切都显得为时已晚。
FinOps 是一种不断发展的云财务管理学科和文化实践，通过帮助工程、财务、技术和业务团队在数据驱动的预算分配上进行协作，使成本预算能够产生最大的业务价值。
云上的 Kubernetes 集群，基本上各云厂商都支持一键部署。这里主要关注本地部署，或者叫做裸机(baremetal)部署。
本文介绍的方法适合开发测试使用，安全性、稳定性、长期可用性等方案都可能还有问题。
本文主要介绍我个人在使用 Kubernetes 的过程中，总结出的一套「Kubernetes 配置」，是我个人的「最佳实践」。 其中大部分内容都经历过线上环境的考验，但是也有少部分还只在我脑子里模拟过，请谨慎参考。
我们在创建一个 python 的 web 服务的镜像时，一般的做法是，将 python 环境与代码打包成一个镜像，然后将这个镜像进行发布。
现在有个需求就是将 python 环境和代码分别构造成两个镜像，让他们进行解耦，并且将他们编排在一个 pod 中。
本文介绍如何将 pod 中的代码与运行的环境进行拆分。
本文主要讲解 redis 的五种基本数据类型：String、List、Set、Sorted Set、Hash。学习如何使用它们，并且了解它们的底层数据结构实现，这样我们才能在适当的应用场景选择最适合的数据类型来解决我们的需求。
MVCC 的全称是 Multi- Version Concurrency Control，也就是多版本并发控制，该机制是只有支持事务的 InnoDB 引擎下才存在的，用来实现提高数据库的并发性能，可以做到：读不加锁，读写不冲突。
本文主要是介绍 redis 是如何进行持久化数据的，我们知道 redis 是基于内存的数据库，那么只要服务器一旦宕机，那么数据则将全部丢失，如果从后端数据库进行恢复，则可能导致性能变慢，那么 redis 需要自身持久化，而不通过后端数据库来恢复数据是重要的。
我的 xirang 系统之前引入 sqlite 功能的时候，使用的驱动包是 github.com/mattn/go-sqlite3 v1.14.15，这个库现在在 go 项目当中，引用最多，应用最广，看项目 Used By 达到了 71k，俨然成为这一方面的标准，但有一个最大的问题就是，这是一个 C 语言实现的库，如果要应用这个库，那么你的环境就需要解决这个 CGO 依赖。
本文主要分享了前端图片懒加载的三种实现思路，即监听滚动事件、IntersectionObserver 以及浏览器原生支持的 loading='lazy'。懒加载的基本思路是延迟加载，对图片而言，我们更希望它可以在即将出现在用户视野中的时候去加载，因为这样能减少不必要的资源请求，同时可以缩短首屏渲染时间。因此，图片的懒加载是前端性能优化过程中不可或缺的一种优化策略。判断一个图片是否位于可视视口内，可以采用手工计算的方式，当然这里更推荐使用 IntersectionObserver 这个 API。 loading='lazy' 是一种浏览器级别的懒加载的特性，虽然它的用法非常简单，可是考虑到整个懒加载的过程，对用户而言完全就是个黑箱，因此，如果你想更精确地控制懒加载的细节，譬如给定一个占位图片，这种情况下该方案就显得非常鸡肋啦。
一直打算写一篇关于 ASP.NET Core 集成测试 的文章，因为一旦说起单元测试这个话题，多多少少会牵动我内心深处的理想主义色彩，虽然如今已然是程序员职业生涯的第七年，可在我看来依然有太多东西在原地打转。这一路跌跌撞撞地走过来，在不同的公司里，见识到了形态各异的研发流程，接触到了貌合神离的敏捷思想，阅读过了风格迥异的框架/架构。
在上家公司工作的时候，我们有部分业务是采用事件/消息驱动的形式。虽然，当时博主还没能用上诸如 Kafka、RabbitMQ 这样的消息中间件，可数据库 + Quartz 这样一个堪称“简陋”的组合，完全不影响博主对事件/消息驱动这种思想的启蒙。后来，在实现数据库审计、数据同步 等问题的时候，更是从实践层面上加深了这一印象。再后来，博主陆陆续续地接触了 DDD，其中 领域事件 的概念，第一次让博主意识到，原来事件可以和聚合根产生某种联系。退一步讲，即使你没有接触过 DDD，你只要听说过 MediatR 或者 CQRS，相信你立马就能明白我在说什么。
这篇文章尝试了用 gRPC 来实现文件的上传与下载，而最终令我们感到无力的一件事情，则是 gRPC Streaming API 在浏览器环境下的支持不完整这件事情。
延迟队列，即 DelayQueue，所以，顾名思义，首先，它是一个队列，对于队列这种数据结构，相信大家都不陌生啦！这是一种先入先出(FIFO)的数据结构，就像现实生活中排队讲究先来后到一样，普通队列中的元素都是有序的。相比普通队列，延迟队列主要多了一个延迟的属性，此时，元素何时出队不再取决于入队顺序，而是入队时指定的延迟时间，它表示该元素希望在经过该指定时间后被处理。从某种意义上来讲，延迟队列更像是一种以时间作为权重的集合。我想，单纯地介绍概念，不一定能真正深入人心，所以，请允许我举几个生活中的例子：当你在网上购物的时候，如果下单后一段时间内没有完成付款，那这个订单就会被自动取消；当你通过 Outlook 预约了会议以后，Outlook 会在会议开始前 15 分钟提醒所有与会人员；当你在网上叫外卖以后，平台会在订单即将超时前 10 分钟通知外卖小哥…这样看起来，是不是顿时觉得延迟队列的使用场景还是挺广泛的呢？
最近一直在研究 gRPC 的 ServerReflection，顾名思义，这是 gRPC 里提供的反射接口，当你需要获取某个接口的描述信息，或者是希望动态调用 gRPC 的时候，这一切就会变得非常有用，如果你经常使用 gRPC UI 这款工具来调试 gRPC 接口，那么，你一定会注意到一件事情，即它要求服务端必须支持 ServerReflection API，而这一点在 ASP.NET Core 中已经得到支持，对此感兴趣的朋友可以参考官方文档。当然，这并不是我想表达的重点(我就知道)。重点是什么呢？在使用 ServerReflection API 的过程中，我发现它采用了 gRPC 双向流的方式来进行交互，在过去的日子里，我研究过诸如 WebSocket、Server-Sent Events 等等服务器推送的技术，我意识到这是一个非常接近的技术，所以，今天这篇文章，我们来一起聊聊 gRPC 中的流式传输。
