如何删除 Git 记录中的敏感信息

最近一些内部开发的 Git Repository 需要开始做对外披露了,回想起当初测试时可能曾经把一些敏感信息给提交到 git 里了,尽管最后一次提交已经把敏感信息删除了,但是中间的提交历史是包含敏感信息的,因此不能直接把代码丢出去了,但是 git 的提交记录我还是想要保留的,这就成了一个问题了。当然最后还是成功解决了,所有的操作都是直接使用 git 命令完成的,特此记录一下。

阅读更多

常见的限流算法

计算机系统中,常常会有各种业务场景需要限制调用方的调用频次,当下游调用频次过高时,往往会造成服务端过多资源占用从而请求报错,超时甚至服务崩溃等超出预期的情况。在此时限流算法就显得非常有必要。

Rate Limiting
 

在介绍之前,有一点需要弄清楚:当我们分别说限流 1 次/s 和 60 次/min 时,我们是在谈论一件事吗?

阅读更多

三言两语 .NET

.NET 是什么

大学期间就听说过 .NET 平台,但是读书和实习期间一直没有接触到对应的业务,不知不觉 .NET 已经发展到 .NET 6.0 了,在这里对 .NET 的一些基础概念和发展历史做一下简单的整理。

.NET

.NET 是由 Microsoft 创建的开源开发人员平台,用于生成不同类型的应用程序。在 .NET 平台上,可以使用 C#、F# 或 Visual Basic 编写 .NET 应用。

阅读更多

如何理解 guava 中的 MoreExecutors#directExecutor ?

guava 是谷歌官方一个著名的 Java 类库,增加了很多 feature ,很多都被官方借鉴。我在使用 guava 提供的 future 的时候,发现了 MoreExecutor#directExecutor 这个方法。对这个方法的理解产生了一些疑问。

阅读更多

缓存一致性协议和内存屏障

现代 CPU 一般都是有多级缓存的,越靠近 CPU 的缓存越快也越小。CPU 缓存层数并不固定,通常是三层,因此这里以三层缓存的典型 hierarchy 来进行叙述。

CPU 的三层缓存我们称之为 L1,L2 和 L3 cache,也被称为一/二/三级缓存。其中:

  • L1 和 L2 cache 为每个核特有,L1 缓存是最小最快的缓存。
  • L3 为单个插槽上的所有 CPU 核心共享。
  • 主存保存这程序运行的所有数据,相比较 L1/L2/L3 而言,更大更慢,由所有插槽上的所有 CPU 核心共享。
阅读更多

简述 memory reordering

什么是 memory reordering

在阐述 memory reordering 之前,首先需要声明的一点是:

memory reordering 本身和多线程没有必然联系,无论保持何种 memory order ,均只是对程序的底层执行进行优化(优化包括编译器和 CPU 两个环节)来提高运行速度,而绝不会改变单线程程序执行的最终结果。只是在实际实践的过程中往往会使用 memory reordering 的特性来保证多线程操作时的线程安全而已。所谓 memory reordering,本质上就是编译器和 CPU 对单线程中指令执行顺序进行的优化。

memory reordering 涉及到各语言编译器的具体实现以及硬件平台的设计。memory reordering 本质上其实可以简单分为三种:

  • relaxed ordering:最弱的内存模型。
  • acquire-release ordering:遵循 acquire and release semantics 的内存模型。
  • sequential consistent ordering:连续一致性模型,没有任何 memory reordering 的可能,下文简称 SC。

三种模型从上往下,依次加强。硬件平台和各语言实现中按内存模型的强弱可以划分如下:

阅读更多

shade logback 的正确姿势

示例工程参照 aliyun-mq/rocketmq-logging

在开发 RocketMQ 5.0 SDK 的过程中,遭遇到一个问题,由于历史上的原因,RocketMQ 的日志默认情况下是会输出到用户的账户主目录下的,但是在之前的版本中,RocketMQ 自己维护了一个日志模块,也是我们所熟知的 logging 模块(下图所示)。之所以没有使用开源的 slf4j 和 logback/log4j2 的方案主要还是想要避免配置文件和环境参数的冲突。

RocketMQ 作为经常被业务代码所依赖的中间件产品,如果自己也直接使用开源的 logback/log4j2 解决方案,那么和用户自己的配置发生冲突几乎是板上钉钉的事情。但是 RocketMQ 本身这个日志模块带来一定的维护成本不说,功能也是无法做到和开源的 logback/log4j2 的解决方案对齐的。

阅读更多

全面升级 —— Apache RocketMQ 5.0 SDK 的新面貌

📣📣📣 阿里巴巴云原生消息中间件团队招聘中 📣📣📣

相关的职位需求见此,热烈欢迎对云原生消息队列感兴趣的朋友找我内推,或者推荐身边的同学。有意者请联系我的工作邮箱

引言

长久以来,RocketMQ 易于部署、高性能、高可用的架构,支撑了数十年来集团内外海量的业务场景。时至今日,为了迎接如今云原生时代的新挑战,我们重磅推出了 RocketMQ 5.0 新架构。

在 5.0 新架构中,我们更新了整个 RocketMQ 的网络拓扑模型,着眼于将更上层的业务逻辑从 broker 中剥离到无状态的 proxy ,这样独立的计算节点可以无损地承担日后的升级发布任务,与此同时将 broker 解放出来承担纯粹的存储任务,为未来打造更强的消息存储引擎做好铺垫。通信层方面,出于标准化,多语言的考虑我们摒弃了 RocketMQ 使用多年的 RemotingCommand 协议,采用了 gRPC 来实现客户端与服务端之间的通信逻辑。

针对于用户侧,我们希望尽可能少的叨扰客户进行升级,维持逻辑轻量,易于维护,可观测性良好,能够可以达到“一次性把事情做对”。

阅读更多

gRPC 中的客户端重试

gRPC 提供了非常复杂的自动重试策略。其中按照重试时机可以分为简单 retry 和 hedging 两种。按照业务上划分可以分为透明重试和非透明重试。

阅读更多
Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×