上一篇讲数据库复制，对非常大的数据库，非常高的数据吞吐量，往往需要同时采用分区。每条数据记录只属于一个分区，但是它可能存储在多个不同的副本节点上。

这一章讲数据库复制（Replication），目标很简单就是保存数据副本在多个机器上，但是实现却没那么容易。首先需要数据复制的几个原因：

1. 数据中心地理上更靠近用户
2. 增强可用性，即便部分服务器节点失败，整个系统依然可用
3. 提高读取的吞吐量

首先讨论传统关系性数据库使用的存储引擎，分为两类：日志结构存储引擎和页面结构存储引擎。

最近读到的最好的一本技术书，评价非常高，堪称经典。书还未读完，收获很大，值得记录的很多。
这一篇博客先讲事务，真心觉得这本书解释的非常清楚，胜过很多的博客。

同事推荐的一本书，只有英文电子版。作者是Alex DeBrie，之前介绍过，是单表设计的推崇者。

这本书前面部分几个章节介绍 DynamoDB 的基本概念，后面部分是一些实际的设计案例。

大多数开发都有关系数据库设计经验，在初次使用 DynamoDB 设计数据模型的时候，很容易陷入关系数据库的思维陷阱, 不自觉的遵守关系数据库设计的范式， 尝试将数据模型规范化，每个实体或实体关系都有对应的单独的表，通常称之为多表设计。
与之对应的是，将所有实体和实体关系都存储在同一张表中，毕竟 DynamoDB 是 Schemaless 的数据库，称之为单表设计。
这儿要强调的是，这两种设计只是极端的两点。可能也不是一个合适的命名，因为在实际应用中，单表设计并不意味着只能有一张表。
在两个极端之间，单表设计更倾向于将相关实体存入在同一张表中，多表设计则倾向将不同实体类型存入不同的表中。

在官方文档中，单表和多表设计比较时也较为推荐单表设计。本文就来根据实际经验，讨论下实际实践中单表设计的优势。
我们自己的项目采用的是单表设计，很大程度上受 《The DynamoDB Book》影响，作者 Alex DeBrie 是单表设计的推崇者。当然，我们项目中已经有十几张表，尽管我们已经尽量将相关实体存入同一张表中。

需求

最近接到一个需求，需要将客户来电转接到最近与客户通话的客服。这个需求很容易理解，
客户可能因为各种各样的原因中断通话，再次来电很可能是因为同一个诉求，比如保险索赔，可能需要多次来回沟通。
将通话转给同一个客服，客服可以接着继续处理而不用熟悉客户场景，这样做能够提高处理效率。
尽管这个需求看起来很基础，但是并没有一个开箱可用的方案。我们的呼叫中心是 Amazon Connect，不过并没有启用 Profile，一些方案也不能采用。

最近，在我们系统中引入了 AWS Cloud Map 作为我们的服务发现系统。部署几周后没有问题，今天突然抛出错误，日志显示错误 getaddrinfo EMFILE events.ap-southeast-2.amazonaws.com。
当然，并非所有请求都触发了此错误，只是在高流量时段才出现了这个错误。

问题

一般来说在我们的系统中，消息处理必须保证幂等性，以防止消息重复处理。在我们的系统中，下面两种情况可能导致相同消息被重复处理：

1. 调度器和消息生产者：调度器或消息生产者可能会被多次触发，比如时不时有些任务因为超时而被多次触发。
2. 队列管理：如果一个 Lambda 实例处理消息超时，另一个实例可能会在 visibility timeout 设置不合适的情况下得到重新处理相同消息的机会。

如果消息被多次处理，我们可能会向客户发送重复的电子邮件和短信，甚至礼品卡都可能重复发送。所以，我们需要一个通用的机制来确保相同消息不会被多次处理。

书名有点大，其实书中更偏向于一些架构场景介绍，书中讲解了作者经历过的十几次架构设计，介绍了场景，技术选择以及相关的权衡。书很快就能读完，对我个人来说多少有些收获。