使用 Azure Container Registry 缓存 Docker Hub 镜像
这篇文章介绍如何使用 ACR (Azure Container Registry) 缓存 Docker Hub 和 GitHub Container Registry 的镜像。
这篇文章介绍如何使用 ACR (Azure Container Registry) 缓存 Docker Hub 和 GitHub Container Registry 的镜像。
工作场景通常需要有身份认证机制保护的 API,客户端在调用这些 API 之前,就需要先进行身份验证,然后使用身份验证得到的 Access Token 去访问这些 API。这篇文章告诉你如何让控制台应用进行交互式身份验证,然后请求受保护的 API。
W3C TraceContext V1 标准 直到 2021 年 11 月才发布。在此之前,很多系统使用自定义的 HTTP Header 字段进行请求和调用链路的追踪。例如 AWS S3 使用 X-Amzn-Trace-Id
进行跟踪。这篇文章告诉你在 ASP.NET 中如何把旧系统中的 X-Request-Id
和 X-Trace-Id
嫁接到最新的 OpenTelemetry 框架上。
Microsoft.Extensions.Logging 打印 Scope 的时候默认是个字符串,这篇文章告诉你如何让其保持 Scope 的结构化输出
总结 MSBuild 的基本概念和扩展方法
总结侵入式链表的主要优缺点和在 C++ 语言参考实现
staged event-driven architecture (SEDA) 框架在建模的时候就将负载和资源瓶颈考虑在内,从而可以在高负载的情况下也能工作良好,并且有效防止服务过载。SEDA 架构的基本思想是将业务逻辑切分成一系列通过 queues 连接起来的 stages,组合成一个 data flow 网络去执行。
很久之前就看到过 SEDA 的论文,当时没有太过在意,因为这个 idea 实在是太简单了。最近这几年在多租户系统的隔离性,延迟稳定性方面进行了一些比较深入的工作,又加上最近看到了比较相关的论文和文章之后,突然又产生了一些触动,决定把这篇文章再捞起来写上几句。
RUM 猜想指的是在 Read Overhead,Update Overhead 和 Memory (or Storage) Overhead 中,同时优化 2 项时需要以剩余的 1 项劣化作为代价。论文原作者进一步解释了一下,在一定程度以内(还没有达到最优的情况下)优化,不遵循 RUM 猜想,但是达到一定阈值后,就需要付出代价才能进一步进行优化。这里的 Update Overhead 只考虑写放大,不考虑写时寻址的代价。
The RUM Conjecture: Read, Update, Memory – Optimize Two at the Expense of the Third.
designing access methods that set an upper bound for two of the RUM overheads, leads to a hard lower bound for the third overhead which cannot be further reduced.
论文原作者解释,提出这一猜想不是说大家啥都不用干了,而是说在达到优化阈值后,如果不想付出某一项性能劣化的代价,应当考虑自适应调整之类的方法,根据数据的特征在这三个重要的参数之间进行平衡。
RUM-Aware Access Method Design. Accepting that a perfect access method does not exist, does not mean the research community should stop striving to improve; quite the opposite. The RUM Conjecture opens the path for exciting research challenges towards the goal of creating RUM-aware and RUM-adaptive access methods.
P.S. 这篇论文也由相同的作者在 SIGMOD'16 上发表了几乎相同的内容[2]。
提到存储系统,就绕不开成名已久的两大系统:文件系统和关系型数据库系统。这两大系统切实的解决了用户的关键问题,并且演进的比较成熟,是我们实现分布式存储系统的重要参考。