最近公司要做一个秒杀活动，结合大量的预热然后估算了现目前的网站真实用户数据，结合我们一系列的数据统计后（这里面就不一一细讲了，大致就是平时的峰值流量的150%），我们得出的是qps在300左右。其实这流量并不算高，我们就没有采用rebittmq这些专门的消息队列来进行处理，因为学习成本较高，而且并不是特别的需要，所以我们决定用redis的list来进行消息队列的实现。
这里讲一点题外话，redis依旧发布的5.+版本中有一个stream流的类型，那么这个是什么呢。Redis Stream本质上是在Redis内核上（非Redis Module）实现的一个消息发布订阅功能组件。相比于现有的PUB/SUB、BLOCKED LIST，其虽然也可以在简单的场景下作为消息队列来使用，但是Redis Stream无疑要完善很多。Redis Stream提供了消息的持久化和主备复制功能、新的RadixTree数据结构来支持更高效的内存使用和消息读取、甚至是类似于Kafka的Consumer Group功能。Redis Stream是一个作者已经谋划多年的feature，本质是一个消息队列，但是和kafka、RocketMq等消息中间件相比也有其独特之处。Redis Stream本来是计划放在4.0这个大版本中发布（原计划4.2）,但是由于确实是个比较重磅的feature，对内核的改动也比较大，目前已经提升到Redis 5.0发布
所以以后大家可以尽可能的多使用redis的消息队列了，像我这种懒人就不喜欢去为了一个功能实现去搞一堆复杂的东西，传言说的是redis的stream的某些方面处理数据的性能可以接近甚至超过kafka的处理能力，所以我们的大数据也完全可以处理了，但是目前来说，就我所接触到的公司都还没开始正式投入使用，可以等一段时间后各大社区开始投入使用后，我会出一篇具体的文章来蹭蹭热度。
首先吐槽下自己吧，这篇文章本来打算昨天就应该发了，结果不小心关机了（没电，心里是万马奔腾，是我在代码上写了很多注释都没保存，哎）首先我们讲讲我们的原理吧，我们首先在服务端起一个php服务，监控秒杀队列，如果有数据进入list队列中，就将数据读取到数据库。下面就是简单的demo示例，我们主要用的linux环境。
首先·是我们的秒杀代码，秒杀开始主要走这里的逻辑。这里没啥可讲的。
服务端监控代码。我们可以在秒杀前1小时进行服务开启，也可以用定时任务进行启动，当然时间就可能不是1小时了。此处我们就是执行了一个死循环不断的读取list的值，当记录值i的值为10的时候进行终止程序。读取的值呢我们可以进行排队发短信或者存入数据库之类的。
我们开始试验，首先，我们开启脚本，在终端执行php redis_contab.php
因为服务器是新配置的，所以我直接在终端操作，执行插入数据
然后呢，监控端就可以看见这个了
其实这里代码还有很多可以进行优化的，这里我只是提出的一个样板，一般消息队列需要一定的容错性，就是如果一个人从rpop弹出来，插入到数据库失败，那么这个人应该被lpush到redislist队列中去。
