Redis5.0之Stream案例应用解读

很是高兴有机会和你们在这里交流Redis5.0之Stream应用。今天的分享更多的是一个抛砖引玉，欢迎你们提出更多关于Redis的思考。

 

首先，咱们来个假设，这里有个杯子，这个杯子是去年我老婆送的，送的缘由是我之前的杯子保温性能太好，致使我不多能喝上水，而这样敞口的杯子能促使我多喝水。虽然这杯子在商家的货架上只是千千万万只杯子中的一只，可是它对我来讲仍然是不一样的。不一样的是过往，是记忆。这记忆提及来是数据的一类，这类数据也让咱们生活更美好。

 

这种数据的特色是什么呢？产生是一次产生的，可是咱们会但愿常常看到，但愿将这种美好填充到各类东西中。而杯子自己也能够说是一个生产-消费模型：数据出现，而后被各类消费。

消费的一种状况

 

所以，杯子不只仅是一个杯子，实际上背后的可挖掘的东西很是多。意义越多，链接越多，关系越复杂，咱们数据量也越大，因此，但愿价值最大化的咱们，就产生了大量但愿被高速处理的数据，这数据体如今系统上，每每就成了数据洪峰，成了系统难以承受之重。

 

在不少状况下，咱们采集端所包含的信息可能远远超出这个数值。例如，雾霾天里，咱们的房间，咱们的位置，它的空气质量是怎样的，各项污染物参数是多少？咱们这个办公区，这栋楼，这个房间的空气质量又是怎样的，电力消耗是怎样的，行人情况，车辆数据，等等。上亿的数据，涉及互联互通，须要保证高并发可靠传输。同时数据收集上来后要进行处理和存储、分析，对系统的挑战都是巨大的。

 

巨大的、网状的互联互通，须要带宽巨大、顺畅的管道；这么多的数据，会造成巨大的数据洪流，采集完成后在云端进行分析，也能够产生巨大的用户价值。

区域检测监控

 

这些数据虽然形式各不相同，可是也有共同的特色，就是和时间有关。例如，一户人家，从主卧到书房，从客厅到餐厅，不一样的房间不一样的位置放置一些空气监测仪，监测仪里面的化学药剂接触空气中的各类成分，随时间缓慢变化，变化过程当中产生信号，这些信号通过初步整理计算，造成一个平面的空气质量数据；从清晨到傍晚，从春到秋，不一样的时间点，甲醛、TVOC等各类污染物成分的数值也不同，所以平面的数据在这里造成了时序数据。

 

凑巧的是，Redis的流就是专门为时序数据设计的。咱们回顾一下Redis的流的存储设计：主线是一个消息链表，将全部消息按照顺序串起来。所以Redis的流在这方面支持度是很是不错的，咱们能够将平面内的数据按照时间序列加入到Redis流里面。固然这些数据咱们可能须要初步处理，所以咱们也可使用Redis的其它数据结构，例如list，再凭借Redis对Lua脚本的支持，用不多的外部应用逻辑驱动它完成处理。这处理由于是在Redis内部完成，因此总体上来讲，计算消耗是比较低的。Redis本来凭借它原生C的优点，还有内存实现和数据结构的优化，内存占用就比较小，CPU要求也低，使它在小型设备上高效率的运行成为可能。将来可能会有万亿级的智能设备基于ARM平台，前景仍是很是广阔的。

 

因此从设备端，咱们已经可使用Redis来完成数据的临时存储和基本的处理，加入Redis流后，再使用MQTT、TCP、808等协议，经过网络上传数据。一般咱们须要采集的区域会比较广，设备数量不少，所以数据也比较多，那数据可能还须要在局部，进行初步的汇总处理。这里数据洪峰每每就开始显露了。若是咱们指望保存进mysql等数据库，一般是顶不住压力的。由于数据库的原子性、一致性、隔离性、持久性等，对性能的损耗是比较大的。因此这里咱们可使用Redis来接收洪峰监测数据，而后分发给存储服务、处理服务、展现服务，等等。在分发处理完成前，Redis自己做为高速内存存储，流里面的数据也是能够做为普通的缓存数据，被反复访问的，因此也在必定程度上，对消息消费前的空档期，作了补充，也给予了后台更宽裕一些的处理时间。

 

咱们来回顾一下其中Redis的使用：快，Redis的性能很高；小，轻便简洁，对内存和CPU要求小；丰富，数据结构丰富，用法多样；时序，流是为时序应用设计的；支持Lua脚本，能自定义逻辑。

 

饭要一口一口吃，路得一步一步走。让咱们回到技术自己，从巨大的洪流里截取出一部分和Redis有关的，还原成基本的工做流程。

 

我这里截取的是空气监测的存储和处理。咱们来看一下示意图，仪器上报数据，Redis接收数据流，而且提供给存储、分析消费，同时供应用使用。

检测数据产生，组别创建

 

首先来了一条空气数据，检测数据产生，存储、分析消费组也创建起来了。空气数据包含了hcho和tvoc污染物值。咱们看看命令，这里有个maxlen，这是为了不队列过长，因此设置的最大长度。为何须要这么设置呢？由于Redis的流顺序消费后，甚至xdel后，数据并不会被清理，队列会愈来愈长，因此这里咱们设置个最大长度，避免溢出。

 

这里有两个存储服务。假设存储相对比较慢，为了能及时处理，咱们构建了更多的存储服务。

 

咱们看看存储和分析服务消费数据的过程。这里两个存储服务都尝试获取数据，可是很明显，只有一个获取到了数据进行处理。分析在这时尝试取3条数据加入分析处理，可是由于stream里只有1条，因此这里只取到1条。

存储、分析服务消费数据

 

分析服务率先完成了数据的消费，因此在分析服务里立刻答复了一个ack给stream，告诉它，已经消费完成了。随后存储服务也完成了存储，存储服务也发送了个ack给stream。

消费完成，答复ACK

 

分析服务刚刚答复完ack，由于某些缘由，重启了。分析服务启动的时候，不清楚消费到哪里了，因此尝试从初始位置开始消费。这里由于前面已经消费过而且返回了ack，因此没有取到任何可消费的数据。若是有数据没消费完成的，经过这种方式能够进行再次消费，因此服务在消费时须要可以处理重入。

分析服务重启，开头消费起

 

在这里咱们看到，检测数据也在不停地到来，存储和分析服务一样按照前面的规则消费。分析服务按照本身的能力，依然尝试一次取用3条，根据结果咱们能够看到，此次分析服务取到了两条消费数据。

新检测数据

 

分析服务消费数据

 

存储服务呢？两个存储服务也都取到了数据进行消费。

存储服务消费数据

 

这时候用户开始访问应用了，他打算看下污染状况是怎样的。咱们都能理解，刚刚购买一件新东西的时候，咱们会更倾向于立刻看看，因此这里用户确定是指望看到污染物状况的。可是这时数据既没有分析完毕，也没有存储完毕，咱们须要怎么处理呢？

 

应用服务能够先检测状态，发现须要的数据尚未处理完成，所以从常规缓存里面获取明显是获取不到的。因此应用直接从stream里获取了，咱们能够看到，用户顺利地秒看到了监测数值，对身边的情况立刻有了一个了解。用户想看看还有没有新数据，因此在应用上点了下刷新，咱们看到，此次仍然能从stream中获取到须要的数据。固然，若是用户想针对性地看看状况，应用中也能够指定ID读取。那还有没有其它方式呢？xrange也是批量取出须要消息的一种方法。

应用使用xread方式读取数据

 

应用使用xrange方式截取数据

 

从这里能够感觉到，虽然咱们的日子，在时间的流里面勇往直前，一去不返了，但幸运的是，在Redis的流里面，咱们仍然能够从过往里截取出任意一段，从新品尝，温故知新。

 

回到例子。用户刷完两次后，存储和分析服务处理好数据了，因此存储和分析服务再次向stream发送ack消息，示意已经处理完成。

消费完毕，返回ack

 

固然，这些Redis里面的处理，都是一如既往地高性能、高效的。

 

这里只是一个简单的截面，一个示意。实际上，Redis本来的使用场景就很是丰富，例如，做为会话缓存，做为页面的全页缓存，手机或者网页的验证码，服务访问的频率限制，密码防暴力破解，竞技场、吃鸡、短视频女神榜等各类排行榜，点赞、阅读数等计数器和排行，关注某个标签、或者某个明星的人，限时优惠活动，证券的实时指标计算，号码发放器，甚至还有geo地理信息，基于LUA的自定义逻辑，还有订阅发布，等等，很是丰富。这些都是基于Redis丰富的数据结构，开发出来的使用方式。

 

罗胖在时间的朋友演讲说，大趋势每每不是一个小趋势逐步成长起来的，而是趋势撞击趋势，改变带来改变，逐渐滚动、交织变大的。那么Redis的流，能在这些已经存在的应用场景里，提供怎样的碰撞？又能在新的领域里，带来怎样的趋势？欢迎你们前来共同讨论。

 

也欢迎你们到华为云分布式缓存免费领取Redis 5.0。如今Redis 5.0是公测阶段，能够免费体验。领取也很是简单，申请公测，而后花费几秒建立Redis 5.0实例，就能够了。