Kafka Q&A

1、为什么Kafka有很高的吞吐量？

1、分区设计，分区分散在多个服务器中实现水平扩展。
2、批量写入和读出，查看kafka的实现会发现，kafka写入和读出的单位是一个消息集合，而不是单条消息。
3、Kafka 使用零复制技术向客户端发送消息一一也就是说， Kafka 直接把消息从文件（或者更确切地说是Linux文件系统缓存）里发送到网络通道，而不需要经过任何中间缓冲区。

2、分区可以随时增加或减少吗？

不可以，在设计一个topic时要考虑具体需要多少分区，一旦决定好就不能改了。

3、可靠性

Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心。把消息写入多个副本可以使Kafka在发生崩愤时仍能保证消息的持久性。只有当消息被写入分区的所有同步副本时（但不一定要写入磁盘），它才被认为是“提交”的。生产者可以选择接收不同类型的确认，比如在消息被完全提交时的确认，或者在消息被写入首领副本时的确认，或者在消息被发送到网络时的确认。

生产者发送的消息被写入本地磁盘。在Linux系统上，消息会被写到文件系统缓存里，并不保证它们何时会被刷新到磁盘上。 Kaflka不会直等待数据被写到磁盘上一一它依赖复制功能来保证消息的持久性。（千兆网卡比机械磁盘要快，不过这个方案有赌运气的成分，因为还是有消息在写入磁盘之前所有节点都宕机的可能性，虽说概率比较低但一旦发生就丢数据了）。

4、据说有些银行也在使用Kafka

1、银行在重新思考基于 Kafka 改造他们的基础流程和系统。
2、在银行里，管理员可能把整个集群设置为可靠的，但把其中的个主题设置为非可靠的，用于保存来自客户的投诉，因为这些消息是允许丢失的。
3、我们也见过有些银行使用5个副本（一个分区5个副本！），以防不测。
4、只要使用failover，就会有丢数据的风险；大部分银行系统宁愿选择在几分钟甚至几个小时内不处理信用卡支付事务，也不会冒险处理错误的消息。failover不适合非常关键的业务。

5、Kafka的复制机制不能提高读吞吐量

因为生产者和消费者都是在主节点上写入和读取消息，从节点唯一的作用是复制主节点的消息，并在主节点宕机后参与主节点选举。从节点不能提供读服务那么自然就无法提高集群的读吞吐量。

参考资料

《Kafka权威指南》
Kafka源代码