请教下这种情况下有必要上消息队列吗

• 資深大佬 : ElmerZhang

  想一下如果你的任务如果套在一个死循环里一直执行的话会有多大压力，频繁执行的压力最大也就到那程度了。
  根据主的描述，取消息的应该只有一端并且是单线程执行的，不会有太大压力。
  redis 唯一的问题是消息可靠性，极端情况下有丢消息的可能。

• 主 資深大佬 : zypy333

  @ElmerZhang 主要怕 quartz 挂,我个人觉得这么频繁写在死循环更好,至于丢消息,如果都死循环了是不是就不用担心这件事了

• 資深大佬 : anonydmer

  假定采集的定时任务的时间间隔是 M，抽取的是 N，M+N 的时延能满足防盗消防之类的需求？

• 資深大佬 : hantsy

  现在只是异步的场景，不在同一个 Domain 的(可能还在同一个程序，为了以后扩展考虑，比如 MS 演进，各 Domain 之间业务尽量不使用太多直接的关联)，需要数据同步的情况，全部是用 Message Broker，当然 Spring 首选 RabbitMQ 。

• 資深大佬 : opengps

  消息队列的解耦目的更重要，主现在的系统压力有多大？小项目建议直接抗，因为你向来可能要扩展的东西还有很多。
  探索性业务，一开始不适合被大包袱前进，不适合直接套用各种规范的分布式，甚至 redis 也不应该想你现在说的用法，
  条件允许你可以考虑下直接入库，redis 只存需要频繁读写的最新数据

• 資深大佬 : keepeye

  为什么要用定时任务呢 redis 有 blpop

• 資深大佬 : haosamax

  之前用 schedule 做的也是一个负责采集数据到 redis，一个负责消费

• 資深大佬 : MoHen9

  可以先上 Redis 的发布订阅嘛，后面数据量大了，改成 kafka 或者 rabbitmq 也可以，代码风格也一样，改起来很容易。Redis 每秒处理几千条数据没问题的，每条数据最好小一些，当然跟 kafka 或 rabbitmq 还是没得比。

• 主 資深大佬 : zypy333

  @anonydmer 公司好像没人操心延迟….我们是先行开发,设备还没怎么对接呢

  @hantsy 抱歉都看不懂你说的 domain 和 MS 演进是什么

  @opengps 小项目,但是公司愿景很大,一口气上了二十几个模块,什么消防温湿度考勤停车场广播一卡通,很多都只是 demo,我称之为面向 ppt 编程,至于为啥分两个项目,是因为沿用以前二开的一个.net 项目,现在报警表里还有奇怪的字段压根没用到

  @keepeye 考虑过这个方案,项目负责人说目前没有必要,我自己写写试试

• 資深大佬 : xx6412223

  quartz 挂是啥意思？你想说的是数据太多，一次 job 的时间会超过 Interval ?

• 資深大佬 : solaya

  上 MQ

• 資深大佬 : Weixiao0725

  对于报警场景，我觉得你需要的是消息队列的 pub-sub 特性吧

• 資深大佬 : onion83

  建议不要自己造轮子，使用成熟的 MQTT 协议和专门的 MQ 队列，阿里云、腾讯云等都有成熟的一整套从接入到分析方案，而且费用很便宜。

• 資深大佬 : BeFun

  只要不是实时性非常高的的，我建议用队列，解耦对以后拆分项目，服务降级很友好，我们项目现在就在拆分阶段，改动量小，线上项目影响小

• 資深大佬 : laminux29

  物联网业务，要确保的是各种智能设备的稳定性、低负载与低功耗。

  从这个角度来说，智能设备与服务器的数据交互模式应该是，服务端把新增或修改的配置信息发给智能设备，智能设备根据配置信息里的数据采集规则，主动向服务端推送。这样做的好处是：

  (1).如果智能设备负载过高，它可以通过降低数据推送频率来保持稳定。不然如果是服务端主动采集的话，智能设备可能会因本来就负载过高，还得响应来自服务端的请求，很容易挂掉。另外，如果智能设备功耗过高，或剩余电量不足，它也可以自行调节数据推送的频率，来达到降低功耗，或增加续航时间的目的。

  (2).由于智能设备，把数据推往服务器的时间，通常设定为整点时间，比如 14 点 10 分 00 秒，那么服务端在处理接收数据的负载问题上，很容易出现差异很大的峰值现象。也就是说，对于服务端来说，要不在某一刻会同时接收到几乎大部分设备的推送数据，要不在某一时刻干脆就彻底闲着，因为没啥设备推送数据。比如：14 点 10 分 00 秒，1000 台智能设备同时推送数据，导致服务器负载 95%；然后 14 点 10 分 0 秒 – 14 点 19 分 59 秒，整台服务器负载却只有 1%；到了 14 点 20 分 0 秒，智能设备又同时推送，服务器负载飙升。

  这问题的本质，同于春运，解决方法只有 2 种：

  如果需要保证数据质量，就只能提供消化峰值的足够算力。这需要砸钱配置尽可能多、尽可能强的服务器或服务器集群；

  要不，就降低数据推送频率，以及错峰推送，来降低项目预算。错峰推送的意思是，比如：

  14 点 10 分 00 秒，ID 为 1-10 的 10 台设备进行数据推送。

  5 秒后，

  14 点 10 分 05 秒，ID 为 11-20 的 10 台设备进行数据推送。

  5 秒后，

  …..

• 資深大佬 : zarte

  无脑推荐 redis 改 kafka

• 資深大佬 : hyqCrystal

  我觉得还是推荐上队列 队列解耦太重要了 且不说定时带来的性能问题，延迟与数据不准确这块就很恼火

• 資深大佬 : mengbai

  我们是走 mqtt 协议,设备主动推送数据,服务端接收解析数据入库

• 資深大佬 : teddy2725

  redis 也可以 pub sub，也有 stream，重构下就可以了

• 主 資深大佬 : zypy333

  @xx6412223 是担心任务不能成功执行,以前定时任务都没这么高频用过,负载延迟都不清楚
  @onion83 我也觉得人家的很好,但是公司好像是想拿自己开发的系统申请专利,未来有机会提一

  感谢其他大佬们的建议,不一一回复了