常见分布式 ID 解决方案
分布式 ID 的生成是分布式系统中的一个核心问题,需要确保生成的 ID 全局唯一、性能高效,并且能够适应高并发和大规模的场景。以下是一些常见的分布式 ID 生成方案:
分布式 ID 的生成是分布式系统中的一个核心问题,需要确保生成的 ID 全局唯一、性能高效,并且能够适应高并发和大规模的场景。以下是一些常见的分布式 ID 生成方案:
以下是一个基于本地缓存 + Redis ZSet + 定时任务的榜单方案,适用于高并发场景:
在互联网领域,限流是指对进入系统的请求数量或频率进行控制的一种机制,以防止系统因流量暴增而过载,从而保障系统的稳定性和可用性。
在实际项目中,区分偶发性超时和频繁超时的重试策略非常重要。偶发性超时可能是由于网络抖动或临时负载过高引起的,适合立即重试;而频繁超时则可能是系统过载或下游服务不可用,此时应避免重试,以免加剧问题。
在实际面试的过程中,经常会遇到类似的面试题目,这时候可以这样回答:
在处理大量请求时,我们经常会遇到超时的情况。为了合理控制重试行为,避免所谓的“重试风暴”,我设计了一个基于时间窗口的算法。在这个算法中,我们维护了一个滑动窗口,窗口内记录了每个请求的时间戳以及该请求是否超时。每当一个请求超时后,我们会统计窗口内超时的请求数量。如果超时请求的数量超过了设定的阈值,我们就认为当前系统压力较大,不适合进行重试;否则,我们认为可以安全地进行重试。
然而,随着并发量的增加,普通版的滑动窗口算法暴露出了一些问题。特别是在高并发场景下,窗口内需要维护的请求数量可能非常大,这不仅占用了大量内存,而且在判定是否需要重试时还需要遍历整个窗口,这大大增加了算法的时间复杂度。
为了解决这个问题,我们进一步设计了进阶版的算法。在这个版本中,我们引入了ring buffer 来优化滑动窗口的实现。具体来说,我们不再以时间为窗口大小,而是使用固定数量的比特位来记录请求的超时信息。每个比特位对应一个请求,用1表示超时,用0表示未超时。当所有比特位都被标记后,我们从头开始再次标记。
原文链接:https://blog.bytebytego.com/p/a-crash-course-on-domain-driven-design
为复杂领域开发软件是一项具有挑战性的任务。
随着问题领域的复杂性不断增长,创建准确表示业务概念、规则和流程的软件变得越来越困难。设计不良的软件很快就会变成难以理解、难以维护和扩展的混乱代码。
领域驱动设计(DDD)为这个问题提供了解决方案。
DDD 是一种软件开发方法,它通过强调对核心领域和业务逻辑进行建模的重要性并使用这些模型作为软件设计的基础来解决领域复杂性。
原文地址:https://mainul35.medium.com/oauth2-with-spring-part-1-knowing-the-basic-concepts-5c4aa17884a
在本系列关于 Spring 的 OAuth2的文章中,我将尝试介绍和解释与 OAuth2 相关的每一个问题以及如何在 Spring 框架中实现这些问题。请记住,OAuth2 完全是一个概念性的东西,在不同的框架中,它有自己的实现。此外,许多应用程序开发人员开发自己的 OAuth2 实现,而不使用 Spring 框架提供的 OAuth2 框架支持。因此,我将就这个主题撰写一系列文章。
在上一篇文章中,我们讨论了使用 client_credential 的 OAuth2 授权服务器配置。在本文中,我们将讨论使用 authorization_code 授予类型的授权服务器配置。此授权流程将有一个 OIDC 客户端,它将通过使用授权码进行请求来获取 JWT 令牌。
在之前的文章中,我们学习了如何使用 OIDC 连接到我们自己的授权服务器。我们在自托管授权服务器中定义了我们自己的客户端应用程序。在今天的文章中,我们将使用 Google 和 GitHub 作为我们的授权服务器,并将我们的授权客户端应用程序连接到这些授权服务器并从它们接收令牌。应用程序登录屏幕将如下所示。
免责声明:本文技术性很强,需要清楚了解本系列前几篇文章,特别是第 1 部分和第 3 部分。
原文链接:https://ably.com/topic/websockets-kafka
Apache Kafka 是目前最强大的异步消息传递技术之一。 Kafka 由 Jay Kreps、Jun Rao 和 Neha Narkhede 等团队于 2010 年在 LinkedIn 设计,并于 2011 年初开源。如今,该工具被众多公司(包括科技巨头,例如 Slack、Airbnb 或 Netflix 使用)为其实时数据流管道提供支持。