软件开发中的Kafka和数据库的关系是什么呢？

首先明确说明Kafka不是数据库，它没有schema，也没有表，更没有索引。

1.它仅仅是生产消息流、消费消息流而已。从这个角度来说Kafka的确不像数据库，至少不像我们熟知的关系型数据库。

那么到底什么是数据库呢？或者说什么特性使得一个系统可以被称为数据库？经典的教科书是这么说的：数据库是提供 ACID 特性的，我们依次讨论下ACID。

1、持久性(durability)

我们先从最容易的持久性开始说起，因为持久性最容易理解。在80年代持久性指的是把数据写入到磁带中，这是一种很古老的存储设备，现在应该已经绝迹了。目前实现持久性更常见的做法是将数据写入到物理磁盘上，而这也只能实现单机的持久性。当演进到分布式系统时代后，持久性指的是将数据通过备份机制拷贝到多台机器的磁盘上。很多数据库厂商都有自己的分布式系统解决方案，如GreenPlum和Oracle RAC。它们都提供了这种多机备份的持久性。和它们类似，Apache Kafka天然也是支持这种持久性的，它提供的副本机制在实现原理上几乎和数据库厂商的方案是一样的。

2、原子性(atomicity)

数据库中的原子性和多线程领域内的原子性不是一回事。我们知道在Java中有AtomicInteger这样的类能够提供线程安全的整数 *** 作服务，这里的atomicity关心的是在多个线程并发的情况下如何保证正确性的问题。而在数据库领域，原子性关心的是如何应对错误或异常情况，特别是对于事务的处理。如果服务发生故障，之前提交的事务要保证已经持久化，而当前运行的事务要终止(abort)，它执行的所有 *** 作都要回滚，最终的状态就好像该事务从未运行过那样。举个实际的例子，

第三个方法是采用基于日志结构的消息队列来实现，比如使用Kafka来做，如下图所示：

在这个架构中app仅仅是向Kafka写入消息，而下面的数据库、cache和index作为独立的consumer消费这个日志——Kafka分区的顺序性保证了app端更新 *** 作的顺序性。如果某个consumer消费速度慢于其他consumer也没关系，毕竟消息依然在Kafka中保存着。总而言之，有了Kafka所有的异质系统都能以相同的顺序应用app端的更新 *** 作，

3、隔离性(isolation)

在传统的关系型数据库中最强的隔离级别通常是指serializability，国内一般翻译成可串行化或串行化。表达的思想就是连接数据库的每个客户端在执行各自的事务时数据库会给它们一个假象：仿佛每个客户端的事务都顺序执行的，即执行完一个事务之后再开始执行下一个事务。其实数据库端同时会处理多个事务，但serializability保证了它们就像单独执行一样。举个例子，在一个论坛系统中，每个新用户都需要注册一个唯一的用户名。一个简单的app实现逻辑大概是这样的：

4、一致性(consistency)

最后说说一致性。按照Kelppmann大神的原话，这是一个很奇怪的属性：在所有ACID特性中，其他三项特性的确属于数据库层面需要实现或保证的，但只有一致性是由用户来保证的。严格来说，它不属于数据库的特性，而应该属于使用数据库的一种方式。坦率说第一次听到这句话时我本人还是有点震惊的，因为从没有往这个方面考虑过，但仔细想想还真是这么回事。比如刚才的注册用户名的例子中我们要求每个用户名是唯一的。这种一致性约束是由我们用户做出的，而不是数据库本身。数据库本身并不关心或并不知道用户名是否应该是唯一的。针对Kafka而言，这种一致性又意味着什么呢？Kelppmann没有具体展开，

希望能帮到你，谢谢！

Kafka的高吞吐能力、缓存机制能有效的解决高峰流量冲击问题。实践表明，在未将kafka引入系统前，当互联网关发送的数据量较大时，往往会挂起关系数据库，数据常常丢失。在引入kafka后，更新程序能够结合能力自主处理消息，不会引起数据丢失，关系型数据库的压力波动不会发生过于显著的变化，不会出现数据库挂起锁死现象。

依靠kafka的订阅分发机制，实现了一次发布，各分支依据需求自主订阅的功能。避免了各分支机构直接向数据中心请求数据，或者数据中心依次批量向分支机构传输数据以致实时性不足的情况。kafka提高了实时性，减轻了数据中心的压力，提高了效率。为了帮助大家让学习变得轻松、高效，给大家免费分享一大批资料，帮助大家在成为大数据工程师，乃至架构师的路上披荆斩棘。在这里给大家推荐一个大数据学习交流圈：658558542 欢迎大家进群交流讨论，学习交流，共同进步。

当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。

但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有有效资源还是很有必要的。

消费者是以consumer group消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个partition。在图中，有一个由三个消费者组成的group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。

在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。

消费方式

consumer采用pull（拉）模式从broker中读取数据。

push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

对于Kafka而言，pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞（并且可选地等待到给定的字节数，以确保大的传输大小）。

消费者组的偏移量等信息存储在zookeeper中的consumers节点中。

6.1 Kafka Producer 压力测试

record-size 是一条信息有多大，单位是字节。

num-records 是总共发送多少条信息。

throughput 是每秒多少条信息，设成-1，表示不限流，可测出生产者最大吞吐量。

作者 | Normcore Tech

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

可能有人没有听说过Kafka，这是一个非常复杂的分布式软件，可协调多台计算机之间的数据传输。更具体地说，该软件的功能是“展平”数据，然后快速地将数据从一个地方移动到另一个地方。一般来讲，如果你有很多数据需要快速处理并发送到其他地方，那么就可以考虑一下Kafka。Kafka还可以在一定期限内保留数据，比如设置数据保存2天、3天或7天，如果你的下游流程失败，那么你还可以利用存储在Kafka中的数据重新处理。

许多处理汇总数据的公司（比如Facebook和Twitter等社交网络数据，以及每晚需要处理大量星体运动的天文学家，或需要快速了解车辆周围环境数据的自动驾驶车辆公司等）都在使用Kafka，将任意地方生产的数据（即用户通过键盘输入的数据，通过望远镜读取的数据，通过车辆遥测读取的数据等）移动至下游流程进行处理和分析。

最近，WeWork更为名The We Company，他们在共享工作间领域取得了成功，其官网宣称公司的使命为：

“提升世界的意识。”其核心业务是从房地产出租公司那里租下办公室，然后转租给无法按照传统流程租赁办公室的个人和小公司。

为了“提升世界的意识”，该公司致力于为世界各地的个人和公司的团队打造独特却又不完全相同的办公空间。最近，该公司还开始涉足教育。

最近，因为上市，WeWork曝光了一些财务信息：

从好的方面来看，根据A xi os的数据，2018年WeWork的入住率为90%，且会员总数在不断增加。

有人常常将WeWork视为硅谷地区的公司过高估值的完美例子。作为一家房地产企业，WeWork烧钱的速度非常快，毫无疑问他们必须努力让公众市场投资者相信公司有长远的发展，同时和还要维护其作为 科技 公司的地位。

这家公司再三强调说它不是一家房地产公司（毕竟它在不断烧钱对吧？），那么一家消息中介技术公司究竟能提供什么？WeWork曾宣布，它使用Kafka来实现“内部部署的物联网需求”。这是什么意思？

“我们的产品是物理空间，”WeWork的首席开发负责人David Fano说，他在会议期间穿着一件印有“bldgs = data”字样的T恤。

每个办公室都有10个环境传感器——小巧的壁挂式绿色盒子，这些传感器可跟踪室内温度、湿度、空气质量、气压和环境光线水平。还有20个白色的壁挂式信标，呈三角形分布在公共空间（开放式办公区和会议室），用于测量WeWork成员的室内位置（数据是匿名的）。顶部四分之一的传感器通过计算机视觉观察成员的活动。

换句话说，WeWork会跟踪WeWork的多个物理事件并记录所有这些数据。但是......他们真的有必要这样做吗？记录Keith Harring壁画周围开放区域的环境温度能给他们带来怎样的竞争优势？更重要的是，他们能否将这些信息用到重要的项目中？

对于公司而言，重要的是要了解办公室的“单位组合” ——私人办公室、会议空间和开放式办公桌——的比例，我们可以利用这些信息对下一个办公间作出调整。

我觉得这家新闻报道机构需要建立一种思考技术的心理模型。Ben Thompson为Stratechery提供了出色的服务，他建立了聚合理论（https://stratechery .com /concepts/），我在努力为这些理论建立一个网站，如果必须从中选择一个的话，那便是：

大多数创业公司（以及大公司）现有的技术栈都没有必要。

在此，我想挑战一下那些自认为可以在一个周末期间独自建立Facebook的Hacker News上的开发人员，我认为WeWork的实际业务和架构问题在于：

WeWork需要的只不过是清点进出的人数，然后对容量规划做优化而已，追踪“气压”有什么用？只要你有WeWork的ID，那你肯定是个人或公司。那么，在大堂里安装一个登记系统，并要求会议系统发放名牌，不是更简单吗？

第一项要求根本就不需要Kafka：

目前WeWork有280个办公间。假设每个办公间平均每天有1000个（有这么多吗？）成员出入。那么每天会产生280,000个事务。我们假设每个人在早餐时间进来一次，在午餐时间出入各一次，然后离开。那么每个人会产生4个事务。那么每天大约是100万个事务，这点数据量存储在最常用的开源关系数据库Postgres中就可以了。保守地说，Postgres每秒可以提供10,000次写入（如果设置得当，其写入次数会更高）。每天100万个事件，也就是每秒11次。根本就不是问题。

至于第二项要求，受预订会议室人数的影响，产生的数据量可能更高，但你不需要实时传输数据。你完全可以等到一天结束时批量处理或收集，这同样可以利用司空见惯的关系数据库。

与大型Postgres（或者是BigQuery，或选择其他关系数据库连接到接收JSON传感器数据的Web服务）相比，Kafka的日常开销要高出很多，因为分布式系统非常非常复杂，比传统的系统复杂得多。

Kafka是一个非常优秀的强大的工具，但各个公司在采用该软件时，需要三思而后行。杀鸡焉用牛刀，WeWork用Kafka来记录开放办公间的气压，实属大材小用。

虽然很多时候我们都不需要Kafka，但开发人员很喜欢推荐这个工具，因为他们可以借机积攒经验和谈资。开发人员喜欢用最尖端的技术来完成工作，有时甚至他们自己都没意识到这一点。

过度架构真实存在。 Nemil在一篇文章中说：

在职业生涯的早期，你遇到的大量设计不良的软件系统都要归咎于那些传播错误观点的工程媒体。

在大学和培训班中，你对工程的了解主要来自工程媒体，例如 Hacker News、聚会、会议、Free Code Camp和Hacker Noon等。这些网站广泛讨论的技术（比如微服务、前端框架或区块链）自然会现在你的技术栈中，虽然不是很必要。

使用这些技术栈会导致各个公司承担不必要的债务，导致他们不得不在风险投资周期中寻求更多的资金，无法迈向精益或从别人的资金中解脱出来。

这种不幸的趋势只会持续下去，我们唯一能做的就是公之于众。

原文：https://vicki.substack .com /p/you-dont-need-kafka

【END】

---