消息队列 redis vs nsq

  为了解决高并发而形成阻塞的问题,通常是通过消息队列来解决问题。

  最近研究了下golang消息队列的nsq框架(http://nsq.io),也动手实现了这么个功能:通过nsq的生产者大量生产消息向nsq推送而形成消息队列,然后通过nsq的消费者从消息队列里接收消息,再利用websocket将接收到的消息给所有web客户端进行消息推送。这样所有客户端就都能接收服务器广播的消息。

  redis是NoSQL数据库,由于redis是将数据写入内存,所以redis处理的速度非常快。其实也可以通过redis来处理消息队列,所以就比较了一下redis和nsq处理消息队列的吞吐量和执行效率。

  消息队列执行效率和吞吐量测试方法:
  redis:
    生产者:LPUSH key value     // 往名为key的链表的表头插入数据value
    消费者:BRPOP key 0          // 阻塞式从名为key的链表的表尾弹出一个元素
  nsqd:
    生产者:Publish(topic, msg) // 往nsqd消息队列里推送主题为topic内容为msg的消息
    消费者:AddHandler(handle) // 注册handle,在handle里接收消息队列的消息

测试1(内网+发送小数据消息):

测试2(内网+发送大数据消息):

  条件有限,没有测试当redis和nsq服务器都处于外网的情况。其实这个很有必要,因为redis部署在外网时听说速度会慢很多。

时间: 2024-12-26 14:48:45

消息队列 redis vs nsq的相关文章

springboot2.0+redis实现消息队列+redis做缓存+mysql

本博客仅供参考,本人实现没有问题. 1.环境 先安装redis.mysql 2.springboot2.0的项目搭建(请自行完成),本人是maven项目,因此只需配置,获取相应的jar包,配置贴出. <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifact

Redis消息队列和KafKa优劣对比

Redis作为消息队列升级为KafKa记录项目当中运营人员发送指定匹配用户(最高用户量几十万的级别)特定的消息,所以这块是确确实实需要使用专业级别的消息队列中间件的,但是可能由于当时开发的各种历史原因导致使用了Redis的队列结构来作为消息队里lpush,blpop等命令,项目开发进展到现在,用户量不断增大,包括不同的消息继承进来,包括举报反馈,小纸条(用户间消息发送),活动奖励通知,等等一些不同的消息进来以后,Redis可能会变得不那么可靠. Redis作为消息队列Redis的pub-sub模

Redis消息队列

一般来说,消息队列有两种场景,一种是发布者订阅者模式,一种是生产者消费者模式.利用redis这两种场景的消息队列都能够实现. 生产者消费者模式:生产者生产消息放到队列里,多个消费者同时监听队列,谁先抢到消息谁就会从队列中取走消息:即对于每个消息只能被最多一个消费者拥有: 发布者订阅者模式:发布者生产消息放到队列里,多个监听队列的消费者都会收到同一份消息:即正常情况下每个消费者收到的消息应该都是一样的: 对应的使用场景包括:A系统向队列中存放数据:B系统在队列中取数据: 1.redis队列模式:可

redis中list模拟案例-消息队列

redis 数据类型:字符串string.list.set.zset.hash 主要的是list消息队列 消息队列的概念:先进先出 <?php//echo phpinfo();ini_set('display_errors','On');error_reporting(E_ALL);//连接本地的 Redis 服务$redis = new Redis();$redis->connect('127.0.0.1', 6379);print_r($redis);echo "<br/&

基于Redis实现分布式消息队列(1)

1.为什么需要消息队列? 当系统中出现"生产"和"消费"的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力. 再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送. 再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开.1:00到4:00和ERP联通,和电商系统断开. 再举个例子,服务员点菜

基于Redis实现分布式消息队列(2)

1.消息队列需提供哪些功能? 在功能设计上,我崇尚奥卡姆剃刀法则. 对于消息队列,只需要两个方法: 生产 和 消费. 具体的业务场景是任务队列,代码设计如下: public abstract class TaskQueue{ private final String name ; public String getName(){return this.name;} public abstract void addTask(Serializable taskId); public abstract

用redis实现支持优先级的消息队列

用redis实现支持优先级的消息队列 为什么需要消息队列 系统中引入消息队列机制是对系统一个非常大的改善.例如一个web系统中,用户做了某项操作后需要发送邮件通知到用户邮箱中.你可以使用同步方式让用户等待邮件发送完成后反馈给用户,但是这样可能会因为网络的不确定性造成用户长时间的等待从而影响用户体验. 有些场景下是不可能使用同步方式等待完成的,那些需要后台花费大量时间的操作.例如极端例子,一个在线编译系统任务,后台编译完成需要30分钟.这种场景的设计不可能同步等待后在回馈,必须是先反馈用户随后异步

基于Redis实现分布式消息队列(汇总目录)

基于Redis实现分布式消息队列(1)– 缘起 http://blog.csdn.net/stationxp/article/details/45595733 基于Redis实现分布式消息队列(2)– 分布式消息队列功能设计 http://blog.csdn.net/stationxp/article/details/45596619 基于Redis实现分布式消息队列(3)– Redis功能分析 http://blog.csdn.net/stationxp/article/details/457

基于redis的延迟消息队列设计

需求背景 用户下订单成功之后隔20分钟给用户发送上门服务通知短信 订单完成一个小时之后通知用户对上门服务进行评价 业务执行失败之后隔10分钟重试一次 类似的场景比较多 简单的处理方式就是使用定时任务 假如数据比较多的时候 有的数据可能延迟比较严重,而且越来越多的定时业务导致任务调度很繁琐不好管理. 队列设计 目前可以考虑使用rabbitmq来满足需求 但是不打算使用,因为目前太多的业务使用了另外的MQ中间件. 开发前需要考虑的问题? 及时性 消费端能按时收到 同一时间消息的消费权重 可靠性 消息