大模型和编程--写在 2024 年初
本文翻译自：http://antirez.com/news/140
作者： Antirez（本名为 Salvatore Sanfilippo，Redis 作者）
发布时间：2024 年 1 月 1 日。
我想先明确一点，这篇文章并不旨在回顾大语言模型(LLMs)。毫无疑问，2023年对人工智能领域而言是具有里程碑意义的一年，但重复这一点似乎没有太多意义。这篇文章更多是一名程序员个人的体验分享。自从 ChatGPT 面世，以及后来我开始使用能在本地运行的大语言模型(LLMs)，我就深入地应用了这一新技术。我的目标是提高编程效率，但这不是唯一的理由。另一个重要的目的是避免在编程中那些不值得投入精力的部分浪费心智。无数个小时被花在搜索那些乏味、缺乏智力挑战的细节文档上；努力去理解一个复杂得无谓的 API；编写一些几小时后就被弃用的即用型程序。这些都是我特别想避免的，特别是在如今这个时代，谷歌搜索结果中充斥着大量无用信息，要在其中找到真正有价值的内容变得越来越困难。
软件 2.0
本文翻译自：https://karpathy.medium.com/software-2-0-a64152b37c35
作者： Andrej Karpathy（OpenAI 创始团队成员，原特斯拉 AI 负责人）
发布时间：2017 年 11 月 12 日。
我发现，有时候人们把神经网络简单归类为机器学习工具箱里的一种工具。神经网络确实有其优势和局限，在某些情况下效果显著，有时候还能帮助人们在 Kaggle 竞赛中获胜。但遗憾的是，这种看法忽略了神经网络的真正意义。神经网络并不仅仅是一种分类工具，它们标志着软件开发方式的一次根本性变革，代表着软件 2.0 的时代。
我们所熟悉的软件 1.0 是用 Python、C++ 等语言编写的。这类软件包含了程序员为计算机撰写的明确指令。程序员通过编写代码的每一行，标定了程序空间中某一特定点，这一点展现了某种我们期望的行为。
An Overview of AWS VPC Networking
Recently, my work requires me to familiarize myself with concepts such as AWS Availability Zones, subnets, network connectivity, NAT Gateways, and Internet Gateways. I would like to summarize my understanding of these topics briefly.
RocketMQ 5.0 × OpenTelemetry 分布式全链路追踪最佳实践
在分布式系统中，多个服务之间的交互涉及到复杂的网络通信和数据传输，其中每个服务可能由不同的团队或组织负责维护和开发。因此，在这样的环境下，当一个请求被发出并经过多个服务的处理后，如果出现了问题或错误，很难快速定位到问题的根源。全链路追踪技术可以帮助我们解决这个问题，它能够跟踪和记录请求在系统中的传输过程，并提供详细的性能和日志信息，使得开发人员能够快速诊断和定位问题。这种技术对于分布式系统的可靠性、性能和可维护性都非常重要。
RocketMQ 5.0 与分布式全链路追踪
Apache RocketMQ 5.0 版本作为近几年来最大的一次迭代，在整个可观测性上也进行了诸多改进。其中，支持标准化的分布式全链路追踪就是一个重要的特性。
分布式链路追踪系统的起源可以追溯到 2007 年 Google 发布的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》论文。这篇论文详细介绍了 Google 内部使用的链路追踪系统 Dapper，其中使用的 span 概念被广泛采用，并成为后来开源链路追踪系统中的基础概念之一。
gRPC 中的客户端重试
gRPC 提供了非常复杂的自动重试策略。其中按照重试时机可以分为简单 retry 和 hedging 两种。按照业务上划分可以分为透明重试和非透明重试。
全面升级 —— Apache RocketMQ 5.0 SDK 的新面貌
长久以来，RocketMQ 易于部署、高性能、高可用的架构，支撑了数十年来集团内外海量的业务场景。时至今日，为了迎接如今云原生时代的新挑战，我们重磅推出了 RocketMQ 5.0 新架构。
在 5.0 新架构中，我们更新了整个 RocketMQ 的网络拓扑模型，着眼于将更上层的业务逻辑从 broker 中剥离到无状态的 proxy ，这样独立的计算节点可以无损地承担日后的升级发布任务，与此同时将 broker 解放出来承担纯粹的存储任务，为未来打造更强的消息存储引擎做好铺垫。通信层方面，出于标准化，多语言的考虑我们摒弃了 RocketMQ 使用多年的 RemotingCommand 协议，采用了 gRPC 来实现客户端与服务端之间的通信逻辑。
针对于用户侧，我们希望尽可能少的叨扰客户进行升级，维持逻辑轻量，易于维护，可观测性良好，能够可以达到“一次性把事情做对”。
常见的限流算法
计算机系统中，常常会有各种业务场景需要限制调用方的调用频次，当下游调用频次过高时，往往会造成服务端过多资源占用从而请求报错，超时甚至服务崩溃等超出预期的情况。在此时限流算法就显得非常有必要。
在介绍之前，有一点需要弄清楚：当我们分别说限流 1 次/s 和 60 次/min 时，我们是在谈论一件事吗？
shade logback 的正确姿势
示例工程参照 aliyun-mq/rocketmq-logging。
在开发 RocketMQ 5.0 SDK 的过程中，遭遇到一个问题，由于历史上的原因，RocketMQ 的日志默认情况下是会输出到用户的账户主目录下的，但是在之前的版本中，RocketMQ 自己维护了一个日志模块，也是我们所熟知的 logging 模块（下图所示）。之所以没有使用开源的 slf4j 和 logback/log4j2 的方案主要还是想要避免配置文件和环境参数的冲突。
RocketMQ 作为经常被业务代码所依赖的中间件产品，如果自己也直接使用开源的 logback/log4j2 解决方案，那么和用户自己的配置发生冲突几乎是板上钉钉的事情。但是 RocketMQ 本身这个日志模块带来一定的维护成本不说，功能也是无法做到和开源的 logback/log4j2 的解决方案对齐的。
缓存一致性协议和内存屏障
现代 CPU 一般都是有多级缓存的，越靠近 CPU 的缓存越快也越小。CPU 缓存层数并不固定，通常是三层，因此这里以三层缓存的典型 hierarchy 来进行叙述。
CPU 的三层缓存我们称之为 L1，L2 和 L3 cache，也被称为一/二/三级缓存。其中：
- L1 和 L2 cache 为每个核特有，L1 缓存是最小最快的缓存。
- L3 为单个插槽上的所有 CPU 核心共享。
- 主存保存这程序运行的所有数据，相比较 L1/L2/L3 而言，更大更慢，由所有插槽上的所有 CPU 核心共享。
