在这篇文章中，我们将讨论以下话题：

  • 9 大最流行的 API 测试类型
  • Passkey 正在塑造无密码未来吗？
  • 缓存系统如何出错？
  • 大端 vs. 小端
  • 我们如何将事件溯源纳入系统？

Passkey 工作原理

Google 最近宣布 Android 和 Chrome 支持 PassKey。

Passkey 由 Apple 和 Microsoft 支持，号称是比密码更安全的替代品。

下图显示了 Passkey 如何工作。

步骤 1 - 创建 Passkey

最终用户需要确认账户信息并提供凭据（面部 ID、指纹 ID 等）。

基于网站提供的公钥生成私钥。私钥存储在设备上。

步骤 2 - 在设备上使用 Passkey 登录

当用户尝试登录网站时，他们使用生成的私钥。只需选择账户信息并提供凭据来解锁私钥。

因此，没有密码泄露的风险，因为网站数据库中没有存储密码。

Passkey 基于行业标准，可在不同平台和浏览器之间工作 - 包括 Windows、macOS 和 iOS，以及 ChromeOS，具有统一的用户体验。

缓存系统出错的 4 种情况

下图显示了缓存可能出错的 4 种典型情况及其解决方案。

1. 雷群问题（Thunder Herd Problem）

当缓存中的大量键同时过期时会发生这种情况。然后查询请求直接击中数据库，使数据库过载。

有两种方法可以缓解这个问题：

  • 一种是避免为键设置相同的过期时间，在配置中添加随机数
  • 另一种是只允许核心业务数据击中数据库，防止非核心数据在缓存恢复之前访问数据库

2. 缓存穿透（Cache Penetration）

当键在缓存或数据库中都不存在时会发生这种情况。应用无法从数据库检索相关数据来更新缓存。这个问题给缓存和数据库都带来了很大压力。

为此，有两个建议：

  • 一种是为不存在的键缓存空值，避免击中数据库
  • 另一种是使用布隆过滤器首先检查键是否存在，如果键不存在，我们可以避免击中数据库

3. 缓存击穿（Cache Breakdown）

这与雷群问题类似。当热键过期时会发生这种情况。大量请求击中数据库。由于热键占查询的 80%，我们不为其设置过期时间。

4. 缓存崩溃（Cache Crash）

当缓存宕机且所有请求都转到数据库时会发生这种情况。有两种方法可以解决这个问题：

  • 一种是设置断路器，当缓存宕机时，应用服务不能访问缓存或数据库
  • 另一种是为缓存设置集群以提高缓存可用性

大端 vs. 小端

微处理器架构通常使用两种不同的方法在内存中存储单个字节。这种差异称为”字节序”或”端序”。

小端（Little Endian）

Intel x86 处理器存储两字节整数时，最低有效字节在前，然后是最高有效字节。这称为小端字节序。

大端（Big Endian）

在大端字节序中，最高有效字节存储在最低内存地址，最低有效字节存储在最高内存地址。较旧的 PowerPC 和 Motorola 68k 架构通常使用大端。在网络通信和文件存储中，我们也使用大端。

当数据在不同系统之间传输或由具有不同端序的系统处理时，字节序变得重要。正确处理字节序对于在不同系统之间一致地解释数据非常重要。

事件溯源应用案例

事件溯源改变了编程范式，从持久化状态到持久化事件。事件存储是真相来源。让我们看三个例子。

1. 纽约时报

该报纸网站自 1851 年以来将每篇文章、图像和署名存储在事件存储中。然后原始数据被去规范化为不同视图，并输入到不同的 ElasticSearch 节点用于网站搜索。

2. CDC（变更数据捕获）

CDC 连接器从表中拉取数据并将其转换为事件。这些事件被推送到 Kafka，其他接收器从 Kafka 消费事件。

3. 微服务连接器

我们也可以使用事件溯源范式在微服务之间传输事件。例如，购物车服务为从购物车添加或移除物品生成各种事件。Kafka 代理充当事件存储，包括欺诈服务、计费服务和电子邮件服务在内的其他服务从事件存储消费事件。由于事件是真相来源，每个服务都可以自行确定领域模型。

本文为学习目的的个人翻译，译文仅供参考。

原文链接：EP93: Is Passkey Shaping a Passwordless Future?。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。