这是我在与卡夫卡合作时遇到的有趣文章、最佳实践、案例研究和一些书籍 (关于数据和日志) 的集合。
文章
- 卡夫卡在一个坚果壳。2015年9月25日发布, 由 kevin sookocheff 发布。凯文的文章简单地说就是关于卡夫卡的。他说: “卡夫卡正在迅速成为许多组织数据管道的支柱–而且理由很充分。通过将卡夫卡用作消息总线, 我们实现了数据生成器和数据使用者之间的高度并行性和解耦, 使我们的体系结构更加灵活, 更易于适应变化。如果你还没有读到关于卡夫卡的书, 你必须经历它。这更像是对卡夫卡的内容、地点和原因的执行总结。
- 你应该在同一个卡夫卡主题中放置几种事件类型吗？martin k克莱普曼于2018年1月18日出版。马丁·克莱普曼关注的是为什么分区的数量很重要。他说, “根据经验, 如果你关心延迟, 你可能应该瞄准 (数量级) 每个代理节点上百个主题分区。如果每个节点有数千个甚至数万个分区, 您的延迟将受到影响。大多数时候, 我们会搞不清楚在同一主题上有多个事件是一个很好的做法, 还是我们应该有一个事件。当您对类似的事件使用不同的主题时, 您可能会遇到排序问题。k莱普曼在本文中讨论了有关延迟、性能、排序和最佳实践的所有要点。
- 如何选择卡夫卡群集中的主题分区数量？jun rao出版, 他说, “在使用者 (在消费者组中) 中的并行度受到所使用分区数量的限制。因此, 一般来说, 卡夫卡集群中的分区越多, 您所能实现的吞吐量就越高。分区直接映射到代理中的文件系统。本文介绍了文件系统在分区中的行为与增加的关系。此外, 讨论的是受分区数量影响的延迟。
- 为什么我不是阿帕奇·卡夫卡的粉丝。马克·伦德尔出版。mark 有一些观点, 如 “如果您使用的是 javaa/scala\ clojure/kotlinn 任何内容, 并且可以使用官方 java 客户端, 那么我相信卡夫卡对于消息总线来说是一个完全合理的选择, 尽管在我看来, 还有很多其他的人的想法要少得多。卡夫卡不能解决你所有的问题。这篇博客文章更多的是关于为什么卡夫卡不是一个很好的选择, 在某些情况下, 以及有哪些替代方案。
- 托尼·曼希尔的最佳做法, 2018年8月1日。tony 说: “卡夫卡已经受到应用程序开发人员和数据管理专家的欢迎, 因为它大大简化了数据流的工作。但卡夫卡可以在规模上变得复杂。如果你真的担心卡夫卡的行业标准和适应性, 这是关于最佳实践的伟大文章之一。本文有不同的最佳实践部分, 如分区、使用者、生产者和经纪人
- 《纽约时报》: boerge svingen 在 con流畅的博客中撰写了这篇文章, 重点介绍了后端系统, 并介绍了他们为解决问题而开发的新方法, 该方法基于 apache 卡卡 (apache kafka) 提供的基于日志的架构。他们称之为“发布管道”。这都是关于卡夫卡如何被用来存储《纽约时报》发表的所有文章的。
- netflix 的keystone 管道, 由netflix 技术博客.本案例研究是关于 netflix 的数据管道称为 keystone 管道, 这是用于用于批处理和流处理的发布、收集和路由基础结构的统一事件。
- linkedin 的比例: 有多大？卡夫卡的创作者已经回答了这个问题, 你会看到在一个尺度上运行卡夫卡的经验。卡夫卡提供了可靠性、弹性和保留性, 同时以高吞吐量运行。
关于数据和日志的书籍
“数据比代码寿命更高”-马丁·克莱普曼
当您真正关注数据时, 您会出手相救, 这是系统设计中最大的挑战, 并且您担心的是可伸缩性、一致性、可靠性、效率和可维护性等问题。
这是一本关于日志及其在分布式系统上的工作方式的书。jay 在数据集成、企业架构、实时流处理、数据系统设计和抽象计算模型方面给出了实用的思路。
这些是我最喜欢的一些文章、案例研究或书籍。如果你有任何值得分享的东西, 请把它放在评论部分。
直到下一次, 保持微笑!