kafka背景、使用场景介绍
参考：
[1]http://www.jasongj.com/2015/03/10/KafkaColumn1/
[2]https://www.cnblogs.com/qingyunzong/p/9004509.html
简介
背景
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
概述
主要应用场景是：日志收集系统和消息系统。
Kafka主要设计目标如下：
- 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
- 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
- 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
- 同时支持离线数据处理和实时数据处理。
- Scale out:支持在线水平扩展
为什么要使用MQ (消息队列)
1. 解耦
现在我有一个系统A，系统A可以产生一个userId
然后，现在有系统B和系统C都需要这个userId去做相关的操作
又过了几天，系统D的负责人接了个需求，也需要用到系统A的userId
又过了几天，系统E的负责人过来了，告诉系统A，需要userId。
又过了几天，系统B的负责人过来了，告诉系统A，还是重新掉那个接口吧。
又过了几天，系统F的负责人过来了，告诉系统A，需要userId。
系统A的负责人，每天都被这给骚扰着，改来改去，改来改去
系统A将userId写到消息队列中，系统C和系统D从消息队列中拿数据。这样有什么好处？
系统A只负责把数据写到队列中，谁想要或不想要这个数据(消息)，系统A一点都不关心。
即便现在系统D不想要userId这个数据了，系统B又突然想要userId这个数据了，都跟系统A无关，系统A一点代码都不用改。
系统D拿userId不再经过系统A，而是从消息队列里边拿。系统D即便挂了或者请求超时，都跟系统A无关，只跟消息队列有关。
这样一来，系统A与系统B、C、D都解耦了
2. 异步
当使用带有消息队列的异步处理的时候，将信息写入消息队列之后就可以立马返回，无需进行后续的调用。
响应时间大大缩减。
3. 流量削锋
流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。
应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。
将所有的请求写入到消息队列中，业务根据消息队列中的请求信息，再做后续处理
作用：
a、可以控制活动的人数。用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
b、可以缓解短时间内高流量压垮应用
4. 日志处理
日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题
日志采集客户端：负责日志数据采集，定时写受写入Kafka队列
Kafka消息队列：负责日志数据的接收，存储和转发
日志处理应用：订阅并消费kafka队列中的日志数据
- 消息通讯
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯
与常用MQ的对比
<……未完待续……>