TL;DR
消息队列是现代化软件架构中在消息系统中最为核心的中间件, 可以想象在还不存在pub/sub模式下的软件架构为了解决传统点对点的queue模式, 迫切需要推出一些高效的方式解决多消息发送接收瓶颈.kafka并不是唯一一个解决这种问题的消息队列模型, 但是具备一定的代表性. 为了进一步探讨消息传输模式设计, 了解并剖析kafka是很有必要的, 同时为了深层次的设计, 一定程度上需要对比部分MQ之间的设计差异.
TOC
Introduction
Core
Compare
Apply
Introduction
kafka拥有一个简洁的架构. 消息队列总是不像http网络传输那样, 如果说http像是在即时打电话进行消息传递, 那么消息队列就是写信传输消息, 这允许一定程度上的延时消息, 或者说是一种非即时消息的传递. 在现实中也能切实体会到: 并不是总有人能够有空闲时间来进行一通长对话. 事实也是如此: 即时消息具备易丢失的特点, 信件消息往往能够存储一定时间范围内的消息, 至少确保了消息的可靠. http的设计从功能上而言就是需要尽可能快速, 那么消息队列就是尽可能保持准确同时兼顾速度, 显然今天没有人愿意为一封迟到30天的信的送信邮局付费.
如果将kafka类比为邮局, 那么显然producer一定是寄信人了, consumer并不一定是收信人, consumer其实更像邮递员和收信人的集合, 这样就很好理解consumer group就是不同地区邮递员的集合或者收信人集合. 当让这里的不同地区指的是一定范围的邮递员指挥负责自己范围内的信件的派送, 那么当邮递员到邮局取信时, 在一个区域的邮递员显然会到统一位置取与自己地区相关的信件, 但是不同的邮递员不会重复拿到同一个信件. 同理, 即使是按照区域划分的用户来拿信件也不可能出现同一封信件被多个收信人取走. 邮局本身提供信件服务属于broker, 作为寄信人和收信人, 寄信和收信能够完成就需要按照broker内部的规则来. 显然寄信需要一些基本信息, 其中最重要的就是目的地. 可以简单认为: 世界上总可以使用一种唯一的形式标识出一个地方, 在标识完备的情况下, 不存在不同地方采用相同标识表示. 为什么这里收件人不用标识? 显然, 收件人标识在信件内部, 邮局内部没有理由也无需得知. 即通过邮件编码和地址就可以找到唯一的信箱, 至于信件最终到哪个收件人手上, 邮局并不保证. 这很大程度上由收件人自己或者邮递员保证. 也就是说, consumer和consumer group后续保证消息的可靠传输, 而kafka只是一个消息传递的中间代理, 因为显然寄信人完全可以自己写信并通过特殊手段直接送到收信人, 但是一般而言这样的成本较高. 邮局为了取信件时的有序性, 受限可以采取窗口模式. 即按照区域划分多个窗口, 指定区域的收信人到指定窗口获取信件. 但是显然很快便出现了问题: 某个区域收件人特别多, 需要排队等待. 这导致了很多问题, 收件人的部分窗口堆积显著影响邮局的处理效率, 指定窗口的邮递员也需要一起等待. 一种最简单高效的方法就是增加窗口. 这确实很有效, 但是可以知道的是, 邮局容量并不是无限大的, 因此窗口需要增加, 但是也需要上限. 一种合理的方式是: 如果该区域的邮递员较多, 那么显然该地区收信量大, 那么窗口至少要和邮递员的数目相当. 为什么? 可以想到当空闲状态时, 如果邮递员比窗口数多, 那么多出的邮递员仍然需要等待, 显然这个等待时间比起送信时间是一种浪费, 邮递员不应当较长时间等待. 在kafka中如果设计topic的partition也会认为consumer group中的consumer不应空闲或者等待而是立刻处理消息. 因此, 这里的特定编号窗口就是topic, 而多个相同的编号窗口就是partition. 不难看出kafka其实就是一个现代化的邮局送信的模型抽象.
在具备了基本抽象模型后, 就需要针对一些具体情况做出合理的处理与优化. 因此, 还需要接触到一些核心的部分.
