kafka是平常用的比较常见的一种消息队列。在项目中为何使用消息队列呢？
使用消息队列，有很多好处。
①比如说，系统其实不是所有的操作都必须实时完成了再进行下一步的，那么用消息队列，就可以提高系统的负载能力，同一时间可以接受更多的访问。
②使用消息队列，可以降低系统的耦合性，比如发短信的事情，可以另外开发，而不需要跟其他业务做到一起。不同的功能，可以分微服务，部署到不同的机器，运维也方便。
③对用户而言，可以得到实时的响应。比如抢购的时候，用户一点，就显示抢到了。（然后，用户提交订单的时候，有可能提示商品不够了，哈哈，很多网站都是这么做的，也没什么毛病。当然这个可能就扯远了，要尽量让用户在秒杀的时候，确实是真实的抢到或者没抢到，方式很多，但目前我还没找到100%可靠方案。）
kafka的可靠性在以下几个方面：
1. 消费者不重复消费
2.消费者消费消息不遗漏
3.生产者不重复发消息
4.生产者发消息不遗漏
5.生产者发消息不乱序
保证消费者不重复消费
可以根据业务指定唯一性的key, 存放到一个地方（数据库、redis等），推荐redis或者mongodb.每次消费的时候，如果发现已经消费过，则直接跳过。
消费者消息不遗漏
关闭自动提交offset, 消息消费成功后，手动提交offset.
生产者不重复发消息
只要保证消费者不重复消费，少量的重发，其实没什么影响。但是如果生产者死循环了，一直发同样的消息，也是个麻烦。当然，这种情况，是程序逻辑问题，压测的时候肯定过不了，也很容易修复。
生产者发消息不遗漏
这个问题比较棘手。我的处理方式是，记录失败的消息，然后定时任务批量处理失败的消息。当然，有时候，失败也不是真的失败，也许是消息发了，但是没有返回成功的值。不过，这个没关系，因为消费端已经做了处理，不会重复消费的。
保证生产者消息的顺序是正确的
其实，不难发现，解决上一个问题的时候，就可能导致顺序乱掉。是否需要保证顺序，这个跟业务也是相关的，如果系统刚好无所谓顺序，比如广告的短信晚点发也没关系，这种情况就不处理。
一般情况讨论的乱序，是出现在消息分到不同partition，然后导致的错乱，可以通过代码控制，让需要保证顺序的消息发到同一个partition即可。
