在我们为银行设计金融系统的时候，消息分发利器是个非常关键的环节。
消息分发处理主要做什么？
银行金融系统每天有大量的交易发生，这些交易很多需要进行实时的检查与处理，比如一笔交易发生，这笔交易是否是欺诈交易，这笔交易是否已经达到限额了，相关用户是否在黑名单中，交易结果联动短信、Email等渠道通知用户……等等，也许一笔简单的交易，就要与反欺诈系统、黑名单系统、限额或授信管控系统、短信邮件系统进行通讯。
这还不是全部，银行金融系统在进行运行时，如果出现了问题，需要日志及时定位问题；为了及时发现问题，要将处理结果实施发送监控平台；为了预防突发事件发生，还需要备份系统做高可用处理。这就仍然需要与日志系统、监控系统、备份系统进行通讯。
最重要的是，上面这些处理必须在极短时间内完成，否则用户就会感到有卡顿，影响体验。
怎么解决这些问题呢？将交易处理相关的系统全部直连起来，似乎是个办法：
但明显不是一个好办法，你将面临极高的后续维护成本：
于是，消息分发处理的概念出现了，我们在各个系统之间搭建一个消息分发的总控系统，连接这个总控系统的主要有两方：
1、消息供应方（Producer）：他们会产生消息，并将消息送给消息分发系统。
2、消息消费方（Comsumer）：他们需要最新的消息以进行自身功能的处理，他们会从消息分发系统拿消息。
而消息分发系统就在中间，起到消息中介（Message Broker）的作用。
kafka系统就是一个消息中介，从kafka的官网可以找到kafka的官方介绍：
可以看出，介绍中也提到kafka很像是一个消息队列或者企业级消息分发系统。当然它不同于一般的消息队列系统，它的并发处理能力很强大，同时，通过分布式架构可以很灵活的增加处理能力。
上图展示了一个最简单的kafka分布式架构的情况，通过分布式架构，kafka集群可以横向扩容很多的broker，以增加自己的并发处理能力。集群通过Zookeeper或其它技术进行分布式调度（Zookeeper简单说就是分布式系统的一个指挥，它会对哪个broker做什么做好指挥，确保所有的broker可以协同工作。以后有机会单独写文章讲解）。
我们可以更加细致的看一下kafka的架构：
上方的Producers会产生很多的消息和信息送给kafka。
kafka会把这些消息存储下来。
下方的Consumers会从kafka获取它所需要的数据，然后自行处理，比如Consumers可能会降消息存储到hadoop、cassandra、Base。
右侧是流处理App。首先“流”是什么？“流”简单来说，就是不间断的一系列变化的数据或者消息。kafka可以很好的支持流处理（支持很多“流API”），一些流处理框架下的App可以接入kafka，并且可以实时的获取变化的数据和消息，对消息进行处理后可以立刻存回kafka，等待其它Consumers调用。
最后是左侧的connectors，通过它，你可以将kafka与不同的数据库或App联通，实现海量数据导入kafka或者从kafka导出。
总结一下，简单说，kafka是一个企业级的消息分发处理系统，可以帮助企业很好的进行多个系统间的消息处理事务，同时支持实时的流处理。
