PHP轮训mysql导出技巧_技能贴 操作进级实操将Kafka作为存储系统

除了构建 API 来提升开拓者体验，我们还做了一些优化：

基于这些缘故原由，在构建这个 API 所依赖的回放系统时，我们利用了 Account Activity API 现有的实时系统设计。
这有助于我们重用现有的事情，并最小化高下文切换包袱和培训事情。

实时系统采取了发布和订阅架构。
为了保持架构的同等性，构建一个可以读取数据的存储层，我们想到了传统的流式技能——Kafka。

两个数据中央产生实时事宜，事宜被写入到跨数据中央的主题上，实现数据冗余。

但并不是所有的事宜都须要被通报，以是会有一个内部运用程序卖力对事宜进行筛选。
这个运用程序消费来自这些主题的事宜，根据保存在键值存储中的一组规则来检讨每一个事宜，并决定是否该当通过我们的公共 API 将通报给特定的开拓者。
事宜是通过 Webhook 通报的，每个 Webhook URL 都有一个开拓职员卖力掩护，并有唯一的 ID 标识。

图 1：数据天生管道

常日，在构建一个须要存储层的回放系统时，人们可能会利用基于 Hadoop 和 HDFS 的架构。
但我们选择了 Kafka，紧张基于以下两个缘故原由：

要利用实时管道来构建回放管道，首先要确保事宜被存储在 Kafka 中。
我们把 Kafka 主题叫作 delivery_log，每个数据中央都有一个这样的主题。
然后，这些主题被交叉复制，实现数据冗余，以便支持来自数据中央之外的重放要求。
事宜在被通报之前经由去重操作。

在这个 Kafka 主题上，我们利用默认的分区机制创建了多个分区，分区与 WebhookId 的散列值（事宜记录的键）逐一对应。
我们考虑过利用静态分区，但终极决定不该用它，由于如果个中一个开拓职员天生的事宜多于其他开拓职员，那么这个分区包含的数据将多于其他分区，造成了分区的不屈衡。
相反，我们选择固天命量的分区，然后利用默认分区策略来分布数据，这样就降落了分区不屈衡的风险，并且不须要读取 Kafka 主题的所有分区。
重放做事基于要求的 WebhookId 来确定要读取哪个分区，并为该分区启动一个新的 Kafka 消费者。
主题的分区数量不会发生变革，由于这会影响键的散列和事宜的分布。

我们利用了固态磁盘，根据每个韶光段读取的事宜数量来分配空间。
我们选择这种磁盘而不是传统的硬盘驱动器，以此来得到更快的处理速率，并减少与查找和访问操作干系的开销。
由于我们须要访问低频数据，无法得到页面缓存优化的好处，以是最好是利用固态磁盘。

为了最小化存储空间，我们利用了 snappy 压缩算法（https://opensource.google/projects/snappy）。
我们知道大部分处理事情都在消费端，之以是选择 snappy，是由于它在解压时比其他 Kafka 所支持的压缩算法(如 gzip 和 lz4)更快。

在我们设计的这个别系中，通过 API 调用来发送重放要求。
我们从要求体中获取 WebhookId 和要重放的事宜的日期范围。
这些要求被持久化到 MySQL 中，相称于进入了行列步队，直到它们被重放做事读取。
要求中的日期范围用于确定要读取的分区的偏移量。
消费者工具的 offsetForTimes 函数用于获取偏移量。

图 2：重放系统吸收要求，并将要求发送给配置做事（数据访问层），然后被持久化到数据库中。

重放做事处理每个重放要求，它们通过 MySQL 相互折衷，处理数据库中的下一个须要重放的记录。
重放进程定期轮询 MySQL，获取须要被处理的挂起作业。
一个要求会在各种状态之间转换。
等待被处理的要求处于开放状态（OPEN STATE），刚退出行列步队的要求处于启动状态（STARTED STATE），正在被处理的要求处于进行中状态（ONGOING STATE），已处理完成的要求将转换到已完成状态（COMPLETED STATE）。
一个重放进程只会选择一个尚未启动的要求(即处于打开状态的要求)。

每隔一段韶光，当一个事情进程将一个要求退出行列步队后，它会在 MySQL 表中写入韶光戳，表示正在处理当前的重放作业。
如果重放进程在处理要求时去世掉了，相应的作业将被重新启动。
因此，除了将处于打开状态的要求退出行列步队之外，重放操作还将读取处于已开始或正在进行中的、在预定义的分钟数内没有心跳的作业。

数据通报层：重放做事通过轮询 MySQL 来读取作业，消费来自 Kafka 的，并通过 Webhook 做事通报事宜

在读取事宜时会进行去重操作，然后事宜被发布到消费者真个 Webhook URL 上。
去重是通过掩护被读取事宜的散列值缓存来实现的。
如果碰着具有相同散列值的事宜，就不通报这个事宜。

总的来说，我们的办理方案与传统的将 Kafka 作为实时、流式系统的用法不一样。
我们成功地将 Kafka 作为存储系统，构建了一个 API，在进行事宜规复时提升了用户体验和数据访问能力。
我们利用已有的实时系统设计让系统的掩护变得更加随意马虎。
此外，客户数据的规复速率达到了我们的预期。

原文链接：

https://blog.twitter.com/engineering/en_us/topics/infrastructure/2020/kafka-as-a-storage-system.html

延伸阅读：

关注我并转发此篇文章，私信我“领取资料”，即可免费得到InfoQ代价4999元迷你书，点击文末「理解更多」，即可移步InfoQ官网，获取最新资讯～