1、kafka发送端的参数：
ack: 当前acks 有3 个取值： 0 、l 和all 。
acks 参数用于控制producer 生产消息的持久性（ durability ） 。对于producer 而言， Kafka在乎的是“己提交”消息的持久性。一旦消息被成功提交，那么只要有任何一个保存了该消息的副本“存活”，这条消息就会被视为“不会丢失的” 。经常碰到有用户抱怨Kafka 的
producer 会丢消息，其实这里混淆了一个概念，即那些所谓的“己丢失”的消息其实并没有被成功写入Kafka 。换句话说，它们井没有被成功提交，因此Kafka 对这些消息的持久性不做任何保障一一当然， producer API 确实提供了回调机制供用户处理发送失败的情况。
///
acks = 0 ：设置成0 表示producer 完全不理睬leader broker 端的处理结果。此时，producer 发送消息后立即开启下一条消息的发送，根本不等待leader broker 端返回结果。由于不接收发送结果，因此在这种情况下producer.send 的回调也就完全失去了作用，即用户无法通过回调机制感知任何发送过程中的失败，所以acks=O 时producer 并不保证消息会被成功发送。但凡事有利就有弊，由于不需要等待响应结果，通常这种设置下producer 的吞吐量是最高的
acks = all 或者－ 1 ：表示当发送消息时， leader broker 不仅会将消息写入本地日志，同时
还会等待ISR 中所有其他副本都成功写入它们各自的本地日志后，才发送响应结果给producer 。显然当设置acks=all 时，只要ISR 中至少有一个副本是处于“存活”状态的，那么这条消息就肯定不会丢失，因而可以达到最高的消息持久性，但通常这种设置下
producer 的吞吐量也是最低的。
acks = 1 ：是0 和all 折中的方案，也是默认的参数值。producer 发送消息后leaderbroker 仅将该消息写入本地日志，然后便发送响应结果给producer ，而无须等待ISR 中其他副本写入该消息。那么此时只要该leader broker 一直存活， Kafka 就能够保证这条消息不丢失。这实际上是一种折中方案，既可以达到适当的消息持久性，同时也保证了producer 端的吞吐量。
buffer.memory
该参数指定了producer 端用于缓存消息的缓冲区大小，单位是字节，默认值是33554432,
即32MB 。如前所述，由于采用了异步发送消息的设计架构， Java 版本producer 启动时会首先
创建一块内存缓冲区用于保存待发送的消息，然后由另一个专属线程负责从缓冲区中读取消息
执行真正的发送。这部分内存空间的大小即是由buffer.memory 参数指定的。若producer 向缓
冲区写消息的速度超过了专属1/0 线程发送消息的速度，那么必然造成该缓冲区空间的不断增
大。此时producer 会停止手头的工作等待1/0 线程追上来，若一段时间之后1/0 线程还是无法
追上producer 的进度，那么producer 就会抛出异常并期望用户介入进行处理。
