消费：先commit再处理消息。如果在处理消息的时候异常了，但是offset 已经提交了，这条消息对于该消费者来 说就是丢失了，再也不会消费到了。
网络抖动 生产者服务器异常 设置成手动提交offset broker挂了 消息是先写到page cache，再刷新到磁盘上。如果page cache没有刷新到磁盘，broker宕机了，重启可以解决。但如果此时操作系统或物理机宕机，page cache里的数据还没有持久化到磁盘，这种情况下数据就会丢失。
先说明下最近的情况，最近项目上线很忙，没有时间写，并且组里有个同事使用 Kafka 不当，导致线上消息丢失，在修复一些线上的数据，人都麻了。
1、高吞吐：Kafka拥有很高的吞吐量，即使是在单节点性能比较低下的商用集群中，也能保证单节点每秒10万条消息的传输。高容错：Kafka在设计上支持多分区、多副本的策略，拥有很强的容错性。
2、首先，Kafka以至少一次的传递语义为基础，这意味着生产者发送的消息在得到确认后，至少会被消费者消费一次。尽管网络分区和故障可能导致重复，消费者端需要通过幂等处理确保数据一致性。接着，Kafka的In-Sync Replicas （ISR）机制扮演了关键角色。
3、服务器处理消息需要是幂等的，消息的生产方和接收方都需要做到幂等性； 发送放需要添加一个定时器来遍历重推未处理的消息，避免消息丢失，造成的事务执行断裂。 该方案的优缺点 优点： 在设计层面上实现了消息数据的可靠性，不依赖消息中间件，弱化了对 mq 特性的依赖。 简单，易于实现。
4、应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性） （2）扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。 （3）消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。
5、Kafka则以其高吞吐量和实时处理能力见长，适用于对实时数据流处理有严格要求的场景。Yahoo开发的开源工具Kafka Manager简化了Kafka集群的管理，包括主题、分区和消费者组的管理。在服务架构、持久化、吞吐量和消息模式等方面，每种消息队列都有其独特的优势。
按Ctrl+C退出发送消息 启动consumer bin/kafka-console-consumer.sh --zookeeper 20179：2181 --topic test --from-beginning 启动consumer之后就可以在console中看到producer发送的消息了 可以开启两个终端，一个发送消息，一个接受消息。
启动服务 31 启动zookeeper 启动zk有两种方式，第一种是使用kafka自己带的一个zk。 bin/zookeeper-server-startsh config/zookeeperproperties& 另一种是使用其它的zookeeper，可以位于本机也可以位于其它地址。
可以开启两个终端，一个发送消息，一个接受消息。如果这样都不行的话，查看zookeeper进程和kafka的topic，一步步排查原因吧。
可以连接到一个网络服务器并且能够从这个服务器下载指定的URL，程序中直接使用HTTP协议。