AWS Aurora, ElastiCache Patterns & DynamoDB — The Complete Data Layer
AWS Aurora, ElastiCache Patterns & DynamoDB — The Complete Data Layer
AWS Aurora、ElastiCache 模式与 DynamoDB — 完整的数据层
Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session completes the database picture — Aurora’s read/write architecture, ElastiCache caching strategies, and DynamoDB from table creation to production-ready query patterns. 这是我 AWS 学习之旅的一部分——从系统工程师转型为云/DevOps 工程师。本节内容补全了数据库版图——涵盖了 Aurora 的读写架构、ElastiCache 缓存策略，以及从表创建到生产级查询模式的 DynamoDB 知识。
📋 Topics Covered
📋 涵盖主题
| # | Topic | Type |
|---|---|---|
| 1 | Aurora Endpoints — Writer vs Reader | Concept + Interview |
| 2 | What Happens When the Aurora Writer Fails | Concept + Cert |
| 3 | ElastiCache Caching Patterns — Lazy Loading, Write Through, Session Store | Concept + Interview |
| 4 | Cache Invalidation | Concept + Interview |
| 5 | DynamoDB — What It Is and When to Use It | Concept + Interview |
| 6 | DynamoDB Table Creation — Keys and Settings | Concept + Lab |
| 7 | Table Classes — Standard vs Standard-IA | Concept + Cert |
| 8 | Capacity Modes — On-Demand vs Provisioned | Concept + Cert |
| 9 | Warm Throughput | Concept + Cert |
| 10 | DynamoDB Items & Attributes — CRUD Operations | Concept + Lab |
| 11 | Query vs Scan — The Critical Difference | Concept + Interview |
| 12 | Local Secondary Index (LSI) vs Global Secondary Index (GSI) | Concept + Cert |
| 13 | Bonus Concepts — Streams, DAX, Consistency, Transactions | Concept + Interview |
| 14 | Interview Questions | Interview |
| 15 | Practice Tasks | Practice |
| # | 主题 | 类型 |
|---|---|---|
| 1 | Aurora 端点 — 写入器与读取器 | 概念 + 面试 |
| 2 | Aurora 写入器故障时会发生什么 | 概念 + 认证 |
| 3 | ElastiCache 缓存模式 — 懒加载、直写、会话存储 | 概念 + 面试 |
| 4 | 缓存失效 | 概念 + 面试 |
| 5 | DynamoDB — 是什么以及何时使用 | 概念 + 面试 |
| 6 | DynamoDB 表创建 — 键与设置 | 概念 + 实验 |
| 7 | 表类 — 标准版 vs 标准-IA 版 | 概念 + 认证 |
| 8 | 容量模式 — 按需 vs 预置 | 概念 + 认证 |
| 9 | 预热吞吐量 | 概念 + 认证 |
| 10 | DynamoDB 条目与属性 — CRUD 操作 | 概念 + 实验 |
| 11 | 查询 vs 扫描 — 关键区别 | 概念 + 面试 |
| 12 | 本地二级索引 (LSI) vs 全局二级索引 (GSI) | 概念 + 认证 |
| 13 | 进阶概念 — 流、DAX、一致性、事务 | 概念 + 面试 |
| 14 | 面试题 | 面试 |
| 15 | 练习任务 | 练习 |
Aurora Endpoints — Writer vs Reader
Aurora 端点 — 写入器与读取器
Aurora doesn’t give you just one database endpoint — it gives you two, each serving a different purpose and routing to different parts of the cluster. Aurora 不仅仅提供一个数据库端点，而是提供两个，每个端点服务于不同的目的，并路由到集群的不同部分。
Writer Endpoint (Primary Endpoint): Always points to the current primary/writer instance. All write operations (INSERT, UPDATE, DELETE) go here. If a failover happens and a replica is promoted, Aurora automatically redirects this endpoint to the new writer — your application’s configuration never needs to change. 写入器端点（主端点）： 始终指向当前的主/写入器实例。所有的写入操作（INSERT、UPDATE、DELETE）都发送到这里。如果发生故障转移且副本被提升为主节点，Aurora 会自动将此端点重定向到新的写入器——你的应用程序配置无需进行任何更改。
Reader Endpoint: A load-balanced endpoint that distributes read-only queries (SELECT) across all available Aurora Replicas. You don’t manage which replica serves each query — Aurora handles the routing, spreading read traffic evenly across however many replicas exist. 读取器端点： 一个负载均衡端点，将只读查询（SELECT）分发到所有可用的 Aurora 副本。你无需管理哪个副本处理哪个查询——Aurora 会处理路由，将读取流量均匀地分布到现有的所有副本上。
Why this architecture matters: In a typical application, reads far outnumber writes — a product page might be read thousands of times per second but updated once a day. Without a reader endpoint, all reads and writes compete for the same primary instance. With Aurora’s reader endpoint, reads are offloaded to replicas — the writer handles only writes, and read capacity scales horizontally by adding more replicas. 为什么这种架构很重要： 在典型的应用程序中，读取量远多于写入量——一个产品页面可能每秒被读取数千次，但每天只更新一次。如果没有读取器端点，所有的读写操作都会争抢同一个主实例。有了 Aurora 的读取器端点，读取操作被卸载到副本上——写入器只处理写入，而读取容量可以通过增加更多副本实现水平扩展。
🎯 Interview Q1: Why do we need a Reader Endpoint? To distribute read-only queries across multiple Aurora Replicas. This reduces load on the writer instance, improves response times for reads, and lets you scale read capacity horizontally by adding replicas — all without any change to the application connection string. 🎯 面试题 1：为什么我们需要读取器端点？ 为了将只读查询分发到多个 Aurora 副本。这减轻了写入器实例的负载，提高了读取响应时间，并允许你通过增加副本实现读取容量的水平扩展——所有这些都无需更改应用程序的连接字符串。
🎯 Interview Q2: What happens if the Aurora writer fails? Aurora automatically promotes one of the existing replicas to become the new writer. The Writer Endpoint automatically redirects to the new primary. Because the endpoint itself doesn’t change (only what it resolves to), the application needs zero configuration changes. Aurora’s failover is typically faster than standard RDS Multi-AZ — often under 30 seconds. 🎯 面试题 2：如果 Aurora 写入器发生故障会怎样？ Aurora 会自动将现有的一个副本提升为新的写入器。写入器端点会自动重定向到新的主节点。由于端点本身没有改变（只是它解析的目标变了），应用程序无需进行任何配置更改。Aurora 的故障转移通常比标准的 RDS 多可用区（Multi-AZ）更快——通常在 30 秒以内。
Connection to last session: This is exactly the same principle as RDS using a DNS endpoint instead of a static IP — the endpoint is a stable address that AWS reroutes behind the scenes. Your application always connects to the same string, and AWS handles where that string points. 与上节课的联系： 这与 RDS 使用 DNS 端点而不是静态 IP 的原理完全相同——端点是一个稳定的地址，AWS 在后台对其进行重定向。你的应用程序始终连接到同一个字符串，而 AWS 负责处理该字符串指向的位置。
ElastiCache Caching Patterns
ElastiCache 缓存模式
ElastiCache isn’t just “put stuff in cache” — how you cache data matters significantly for consistency, performance, and staleness. There are three standard patterns, each designed for a different use case. ElastiCache 不仅仅是“把东西放进缓存”——你如何缓存数据对于一致性、性能和数据陈旧度至关重要。有三种标准模式，每种模式都针对不同的用例而设计。
Pattern Comparison / 模式对比
| Pattern / 模式 | How it works / 工作原理 | Stale data? / 数据陈旧？ | Best for / 适用场景 |
|---|---|---|---|
| Lazy Loading / 懒加载 | Cache data only on the first read (cache miss triggers DB query + cache write) / 仅在首次读取时缓存数据（缓存未命中触发数据库查询 + 缓存写入） | Yes (possible) / 是（可能） | Product catalog, blogs, non-critical reads / 产品目录、博客、非关键读取 |
| Write Through / 直写 | Update cache and database together on every write / 每次写入时同时更新缓存和数据库 | No (always in sync) / 否（始终同步） | Banking, inventory, user profiles / 银行、库存、用户资料 |
| Session Store / 会话存储 | Store temporary session data in cache with a TTL / 在缓存中存储带有 TTL 的临时会话数据 | N/A (time-bound) / 不适用（有时限） | Shopping carts, login sessions, user state / 购物车、登录会话、用户状态 |
Lazy Loading (Cache-Aside): Application checks cache → Cache Hit: return data immediately → Cache Miss: query the database, write result to cache, return data to caller. 懒加载（旁路缓存）： 应用程序检查缓存 → 缓存命中：立即返回数据 → 缓存未命中：查询数据库，将结果写入缓存，返回数据给调用者。
- The good: Only data that’s actually requested gets cached — no wasted cache memory on data nobody reads. Very simple to implement.
- 优点： 只有实际被请求的数据才会被缓存——不会浪费缓存内存去存储没人读取的数据。实现非常简单。
- The trade-off: On a cache miss, the call takes longer because it hits the database AND writes to the cache. And there’s a window where the cache can serve stale data if the database was updated without invalidating the cache entry.
- 权衡： 在缓存未命中时，调用耗时更长，因为它既要访问数据库又要写入缓存。此外，如果数据库在没有使缓存条目失效的情况下进行了更新，缓存可能会在一段时间内提供陈旧数据。
How stale data is handled in Lazy Loading: When a database record is updated, the corresponding cache entry is explicitly deleted (invalidated). On the next read, a cache miss occurs, the latest data is fetched from the database, and the cache is refreshed with the fresh value. A TTL (Time To Live) is often set on cache entries as a backup — even if something isn’t explicitly invalidated, the cache automatically expires it after the TTL elapses. 懒加载中如何处理陈旧数据： 当数据库记录更新时，相应的缓存条目会被显式删除（失效）。在下一次读取时，会发生缓存未命中，从数据库获取最新数据，并用新值刷新缓存。通常会为缓存条目设置 TTL（生存时间）作为备份——即使某些内容没有被显式失效，缓存也会在 TTL 过期后自动将其清除。
Write Through: Every database write also updates the cache at the same time — both happen together, never independently. 直写： 每次数据库写入也会同时更新缓存——两者同时发生，绝不独立进行。
- The good: The cache is always synchronized with the database. No stale data ever. When an application reads from cache, it always gets the current value.
- 优点： 缓存始终与数据库同步。绝无陈旧数据。当应用程序从缓存读取时，总是能得到当前值。
- The trade-off: Every write incurs extra latency because two writes happen (DB + cache) instead of one. Cache memory may be used for data that’s written often but rarely read.
- 权衡： 每次写入都会产生额外的延迟，因为发生了两次写入（数据库 + 缓存）而不是一次。缓存内存可能会被用于那些写入频繁但读取很少的数据。
🎯 When to choose which:
- If consistency is critical (banking, inventory, anything financial) → Write Through.
- If reads dominate and occasional staleness is acceptable (product listings, blog content) → Lazy Loading.
- If you’re storing temporary state that shouldn’t live in the database at all → Session Store.
🎯 如何选择：
- 如果一致性至关重要（银行、库存、任何金融相关）→ 直写。
- 如果读取占主导地位且偶尔的陈旧是可以接受的（产品列表、博客内容）→ 懒加载。
- 如果你要存储不应该存在于数据库中的临时状态 → 会话存储。
Session Store: Temporary session data (login tokens, shopping cart contents, user preferences) is stored in ElastiCache with a TTL. When the TTL expires, the session data is automatically deleted. 会话存储： 临时会话数据（登录令牌、购物车内容、用户偏好）存储在带有 TTL 的 ElastiCache 中。当 TTL 过期时，会话数据会自动删除。