fwq

详解RedisStream做消息队列 0浏览 收藏 亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《详解RedisStream做消息队列》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下队列、消息、RedisStream，希望所有认真读完的童鞋们，都有实质性的提高。 List 众所周知redis数据结构中的list的lpush与rpop可以用于常规消息队列，从集合的最左端写入，最右端弹出消费。并且支持多个生产者与多个消费者并发拿数据，数据只能由一个消费者拿到。 但这个方案并不能保证消费者消费消息后是否成功处理的问题（服务挂掉或处理异常等），机制属于点对点模式不能做广播模式（发布/订阅模式） Pub/sub 于是redis提供了相应的发布订阅功能，为了解除点对点的强绑定模式引入了Channel管道。 当生产者向管道中发布消息，订阅了该管道的消费者能够同时接收到该消息，而且为了简化订阅多个管道需要显式关注多个名称提供了pattern能力。 通过名称匹配如果接收消息的频道wmyskxz.chat，consumer3也会收到消息。 但这个方案也有很大的诟病就是不会持久化，如果服务挂掉重启数据就全丢弃了，也没有提供ack机制，不保证数据可靠性，不管有没有消费成功发后既忘。 Stream stream的话结构很像kafka的设计思想，提供了consumer group和offset机制，结构上感觉跟kafka的topic差不多，只是没有对应partation副本机制，而是一个追加消息的链表结构。客户端调用XADD时候自动创建stream。每个消息都会持久化并存在唯一的id标识 Consumer Group 消费者组的概念跟kafka的消费者概念如出一辙，消费者既可以用XREAD命令进行独立消费，也可以多个消费者同时加入一个消费者组。一条消息只能由一个消费者组中的一个消费者消费。这样可以在分布式系统中保证消息的唯一性。 其实这个特性我后来仔细琢磨了一下当时自认为无懈可击的流式图表为了保证分布式系统消息唯一做了redis分布式锁。有点鸡肋，明明消费者组已经保证了数据的唯一性。只能说加锁可以压缩资源成本 last_delivered_id 用于标识消费者组消费在stream上消费位置的游标，每个消费者组都有一个stream内唯一的名称，消费者组不会自动创建，需要用XGROUP CREATE显式创建。 pending_ids 每个消费者内部都有一个状态变量。用来表示已经被客户端消费但没有ack的消费。目的是为了保证客户端至少消费了消息一次（atleastonce）。如果消费者收到了消息处理完了但是没有回复ack，就会导致列表不断增长，如果有很多消费组的话，那么这个列表占用的内存就会放大 curd xadd 追加消息 xdel 删除消息，这里的删除仅仅是设置了标志位，不影响消息总长度 xrange 获取消息列表，会自动过滤已经删除的消息 xlen 消息长度 del 删除Stream pending_ids如何避免消息丢失…

redis秒杀系统的实现 0浏览 收藏 知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《redis秒杀系统的实现》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！ 1.如何设计一个秒杀系统 在设计任何系统之前，我们首先都需要先理解秒杀系统的业务背景 下面我简单的举一个例子： 在某个时间点，某某电商网站要低价卖某件商品，而且限量1千件，抢购人数超过数十万人。所以我们面临的第一个秒杀的问题就是：时间极短，然后瞬间流量非常大我们的系统必须保证秒杀抢购的结果不出错，达到抢购的预期目的。而且秒杀库存的实现也需要保障秒杀结果的准确性。总结几个特点就是： 高性能：秒杀中有大量的并发读写，所以需要使系统能支撑起高并发访问，这是一个关键点。 高可用：藐视瞬间流量非常大，很有可能会导致系统宕机，所以需要从各方面保证系统的可用性。 一致性：由于秒杀请求量非常大，此时就需要我们的秒杀结果要准确。因为一旦出错，那么波及面会非常广，损失非常大。 2.秒杀流程 我们先从秒杀的入口开始说起在秒杀入口的地方会有这些问题需要解决： 2.1 前端处理 静态资源处理 秒杀商品一般都会包含很多静态资源，所以这些图片什么的静态资源一定要放到CDN（Content Delivery Network，即内容分发网络），能放的尽量放进去。让秒杀时后端服务器的压力尽可能小。说到此处，我重点描述讲解CDN 为了能在传统IP网上发布丰富的宽带媒体内容，提出在现有互联网基础上建立一个内容分发平台专门为网站提供服务。由于CDN是为加快网络访问速度而被优化的网络覆盖层，因此被形象地称为“网络加速器”。首先要说的是应用服务器和资源服务器应该解耦，也就是应用服务器只处理逻辑，而资源服务器存放内容或者叫资源。 CDN专注于「内容」，也就是CDN的C所代表的Content，专注于静态资源的分发和访问，比如一张图片，一个文本文件，一个视频，一个CSS，一个JS等等，任何以文件形式存储的，为了提高在互联网上的访问速度和质量，都可以将这个资源部署在CDN这个网络上。 CDN动作是「分发」，也就是如何让刚才提到的那些「内容」快速的部署在这个网络中，从而快速为用户服务，其实还有一层更重要的含义是用户的快速访问与就近接入，分发的目的是为了用户更好的体验。 CDN落定于「网络」，是部署于全国或者全世界的一大堆服务器，这些服务器基于当前互联网的基础架构在其上层再构成一个网络，这个网络专为资源分发而生。 那CDN的原理是什么呢？为什么用户可以接入离他最近的服务器呢？主要是利用了DNS来判断用户位置，再返回给用户最近的机房的服务器的资源地址。下面我再通俗的解释一下：肯德基的总部在美国，可是你家楼下也有一家肯德基，并且汉堡包是一模一样的，这就是CDN（这个比喻来自知乎，觉得非常的恰当）。肯德基部署了很多个CDN在世界各地提供服务，用户都是找到最近的店，这个计算过程就是刚才讲的「就近接入」。 什么是CDN的调度呢？ （1）DNS调度是最常用和最通用的调度方案，缺点是存在DNS劫持的风险，调度的精确度也会差一些；（2）302调度非常适合用在大文件下载和视频点播这两个应用场景，优点是可以提高调度的精确度，缺点是将会增加首包的时延（在大文件下载和视频点播场景下对首包时延不太敏感，而对调度精确度要求更高）（3）HTTPDNS调度的优点是有较高的安全性（可以规避DNS劫持风险）和调度精确度，但是有个很大的缺点，需要客户端提供支持（例如在手机APP上嵌入SDK），通用性较差。 通俗来讲： 在一个商圈有两家肯德基，有一家组织活动，鸡腿随便吃，所以顾客全部涌到这家店，已经水泄不通，另一家店则门可罗雀。这个时候CDN的调度功能就要发挥作用了，另一家店也发布了一个消息说，买一个汉堡，打五折。这个时候，在第一家店抢不上鸡腿的顾客，马上跑去了第二家店，这个时候两个店的流量处于均衡状态。这就是CDN的调度。…