在并发场景中，我们往往会使用队列将一些耗时的行为给暂存起来，然后后台启用业务程序去消化它。 

能够提供这种队列服务的，redis，kafka各算一个。先说redis.  redis有个list类型，有排序功能，能存亿级别的数据，并且从头或尾出数据复杂度O1，并且有原子级别的锁机制，讲这么多就是为了证明它有能力使用于高并发场景接收C端的必要业务数据入队。技术角度分析:C端10万级别请求来了，redis的list入队有个原子性操作可以保证快去并且最终有序的入队，这样一来无论你同一时刻多少请求来了，最终redis总是一个一个来处理的，只是它会很快速，最终的结果就是它们有项先后顺序的进入了redis的list，就成了我们常说的入队列了。再说出队，后台启用多进程/线程/协程并行去队列里面取数据进行业务处理，当然尽管你后台程序可以是并行去redis队列取数据并使用，但是对于redis服务端来说都是一个个客户端，可以做到让所有客户端只能一个个来pull队列里面的数据，划重点啦！！！强调下redis服务端是异步行为将数据发送到客户端的，这就会造成服务端单方面认为从它这里出去的数据都是按队列里面的先进先出的顺序发送给客户端，它才不管你达到客户端实际接受到的是不是还是原有的那个顺序，反正服务端是按那个顺序异步发的，有趣的地方也是这里了，比如服务端先数据a出队，其次数据b，但说不定实际到达客户端的是数据b，道理很简单异步行为，让a先走，但接收a的客户端可能卡了，花了3秒才接住a，但接收b的客户端信号很好，1秒就接住了，那你a虽然比b先出队半秒也还是比b慢。

再谈kafka，kafka用到了zookeeper，意味着它可以分布式的集群部署便的简单可靠强大并响应快速，redis你自己去部署一个集群说实话我有点懵，毕竟我没有从它文档里面直接获取我该怎样去配置它它就是集群了，但kafka有，kafka有订阅通知那一套，redis我印象中它也有，但是redis不保证推送过去的消息客户端一定就接受到了，所以对于redis的订阅通知来说，而且redis万一挂了呢，你可能会说有持久化啊，快照级别的，跟秒级别的持久化redis也都是有的，但是服务不能停啊！！！哪怕是一刻，可见并不是它的拿手好菜，想反kafka的集群对于数据有效写入的标准是可以根据实际写成功服务器的数量为参考依据去保证的，打个比方集群3台，2台写入成功了，1台失败了，它就认为写入成功了，并且它有自己的一套机制去保证集群服务器最低存活数量，重启挂掉的服务器，并且它总是建议你配置的服务器数量为奇数。再回正题，kafka订阅通知发消息是以组为单位，一个组里面的成员应该保持小于或者等于该主题创建时设置的分区个数，并且发送过来消息只会让该组中的一个客户端消费，划重点啦！！！！！  3个kafka客户端进一个H组了，订阅了一个3分区的A主题，现在A主题有一个M消息过来了，它会直接发到订阅该主题的组，那么我们的H组就获取到了M消息，但kafka内部机制可以保证M消息只会被该组的一个成员客户端给消费掉，这不就是提供了多进程并行处理队列的数据的类似场景么，想想一下主题就是队列，组里面的成员就是多个不同服务器里面进程，不就是多个进程同时等着该主题的消息发送过来，最终总有也只有一个客户端成功处理掉该消息，并且由于kafka支持分区，组内的成员可以各自对接一个分区，实现并行！！！而且kafka消费是支持同步与异步的噢，这个可以对比redis了队列和订阅了。

kafka是基于zookeeper上玩耍的，所以可以先去大概了解一下zookeeper受分布式场景喜爱的。我感觉到了kafka主题分区并行，以及配置选举，leader，flower等还有很多秘密，估计只能实战中慢慢再挖掘了，ok！