直接搭个redis,用list派发就完了，折腾，性能也不会

--
👇
Borber: 收到， 感谢大佬的指点

--
👇
hax10: 对，这个方案就是简单的轮询连接，没有长连接，类似于你在发帖时提的REST接口。好处在于简单易写，但是性能会差点。

分布式数据同步的好处是你的数据量大到无法在单台服务器上存储时，就能利用多台机器以各存部分数据的方式实现大规模的数据处理。按你说的数据量，这肯定没必要这么做。

收到， 感谢大佬的指点

--
👇
hax10: 对，这个方案就是简单的轮询连接，没有长连接，类似于你在发帖时提的REST接口。好处在于简单易写，但是性能会差点。

分布式数据同步的好处是你的数据量大到无法在单台服务器上存储时，就能利用多台机器以各存部分数据的方式实现大规模的数据处理。按你说的数据量，这肯定没必要这么做。

对，这个方案就是简单的轮询连接，没有长连接，类似于你在发帖时提的REST接口。好处在于简单易写，但是性能会差点。

分布式数据同步的好处是你的数据量大到无法在单台服务器上存储时，就能利用多台机器以各存部分数据的方式实现大规模的数据处理。按你说的数据量，这肯定没必要这么做。

--
👇
Borber: 可以， 我觉得这个方案不错， 确实可以一上线就获取，但这样的话汇报是否应该直接设置为请求接口而不是长连接呢？

哇， 分布式数据同步这块我着实不太熟悉啊，这个能解决的问题是哪块呢？

--
👇
lithbitren: 感觉模型就是异步tcp/websocket长连接+分布式数据同步算法（raft等等）比较合适，轮询感觉不是解决之道啊。

可以， 我觉得这个方案不错， 确实可以一上线就获取，但这样的话汇报是否应该直接设置为请求接口而不是长连接呢？

--
👇
hax10: 如果大部分时间都在等第三方服务器的反应那还好。

假如每一个网址对象比较固定的话，就没必要每几秒推请求到消费端，只要让消费者上线时拿一批网址，每几秒查询固定的这批网址后把最新结果值发到生产端就可以。消费者下线时告知一下生产端，到时候中央端重新分配任务即可。

用Rust写个这样的HTTPS服务不难，比如你可以参考一下Poem这样的框架，它的basic-auth代码示例能设置密码，这样的安全性会比直接使用消息队列好，网址对象库可以放在服务器的HashMap里。

感觉模型就是异步tcp/websocket长连接+分布式数据同步算法（raft等等）比较合适，轮询感觉不是解决之道啊。

如果大部分时间都在等第三方服务器的反应那还好。

假如每一个网址对象比较固定的话，就没必要每几秒推请求到消费端，只要让消费者上线时拿一批网址，每几秒查询固定的这批网址后把最新结果值发到生产端就可以。消费者下线时告知一下生产端，到时候中央端重新分配任务即可。

用Rust写个这样的HTTPS服务不难，比如你可以参考一下Poem这样的框架，它的basic-auth代码示例能设置密码，这样的安全性会比直接使用消息队列好，网址对象库可以放在服务器的HashMap里。

--
👇
Borber: 并发请求呀， 因为他们的任务就是去请求一下网站或者接口然后正则拿到信息之后就好了， 所以并发应该是没问题的

并发请求呀， 因为他们的任务就是去请求一下网站或者接口然后正则拿到信息之后就好了， 所以并发应该是没问题的

--
👇
hax10: 兄弟，这资源只能算杯水车薪啊。

拿你说的最慢情况说事，1万个任务处以6个消费者 = 平均每一消费者五秒内要处理1667个对象

但是一个对象可能要0.1秒才处理完。所以要在5秒内完成166.7秒的工作量。你要启动200个消费者才能应付的了？

--
👇
Borber: 只有生产者的IP是固定的， 安全措施纯靠别人不知道我在运行这样一个服务 ， 哈哈哈哈。 流量限制无。

同时只有 6 个消费者在线， 单个任务一般在 50-100ms内 每个任务大概1k以内的直接， 数据库中所有对象大概一万左右，每次开机会全部拿到内存中

兄弟，这资源只能算杯水车薪啊。

拿你说的最慢情况说事，1万个任务处以6个消费者 = 平均每一消费者五秒内要处理1667个对象

但是一个对象可能要0.1秒才处理完。所以要在5秒内完成166.7秒的工作量。你要启动200个消费者才能应付的了？

--
👇
Borber: 只有生产者的IP是固定的， 安全措施纯靠别人不知道我在运行这样一个服务 ， 哈哈哈哈。 流量限制无。

同时只有 6 个消费者在线， 单个任务一般在 50-100ms内 每个任务大概1k以内的直接， 数据库中所有对象大概一万左右，每次开机会全部拿到内存中

只有生产者的IP是固定的， 安全措施纯靠别人不知道我在运行这样一个服务 ， 哈哈哈哈。 流量限制无。

同时只有 6 个消费者在线， 单个任务一般在 50-100ms内 每个任务大概1k以内的直接， 数据库中所有对象大概一万左右，每次开机会全部拿到内存中

--
👇
hax10: 一切看具体情况而定吧。

处理单个任务一般要多久？每一任务大概有多少字节？同时会有多少消费者在线？同时有多少对象在数据库里？

而且如果消费者和生产者不处于同一内网那要通过公共IP地址进行连接。有何安全措施或流量限制？

一切看具体情况而定吧。

处理单个任务一般要多久？每一任务大概有多少字节？同时会有多少消费者在线？同时有多少对象在数据库里？

而且如果消费者和生产者不处于同一内网那要通过公共IP地址进行连接。有何安全措施或流量限制？

-- 👇 Borber: ...

不处于同一内网, 所有对象进内存没问题, 但 redis 内存占用会不会比较大? 我也想着既然所有对象每五秒都要更新, 那我不进行查找, 直接每五秒全部更新一次应该也没啥问题, 没必要每秒都去查找了。然后队列A里面一次放入全部的任务等待消费者， 然后另起一个队列B接收返回的数据， 更新内存中储存的对象中的地址，

只是这种方法不知道会不会因为在一瞬间加入大量的消费者以及每次都是消费单个对象组成的任务比较耗时，想着可以将多个对象的任务打包为一个消息，然后也合并返回， 到消费者这边就并发请求， 减少耗时

--
👇
hax10: 要是生产者和消费者都属于同一内网，并且所有对象都能装进中心服务器的内存，可以考虑使用Redis。它的有序集合能存储每一对象的更新时间，这样方便找出最近没更新的对象。

看起来一个消息队列中间件会比较符合你的需求

要是生产者和消费者都属于同一内网，并且所有对象都能装进中心服务器的内存，可以考虑使用Redis。它的有序集合能存储每一对象的更新时间，这样方便找出最近没更新的对象。

可以试下这个 https://github.com/svix/svix-webhooks 生产端往钩子上推送.

抱歉, 很多基础名词都是自己乱造的, 那确实是消费者.

消费者处于可以访问外网但无法被外网直接访问的服务器环境, . 主要就是爬取第三方服务的一些数据, 我也意识到了保持长连接是比较好的方式.

现在的想法是和底下一位大佬的想法一样使用 MQ , 每一秒扫描一次数组, 找出超时的对象建立任务添加到消息队列中, 消费者来获取任务, 返回结果之后更新对应对象的时间

--
👇
hax10: 首先，你说的生产端一般叫消费者，而处于中心位置的节点才叫生产者，因为任务是从它那里发出来的。

既然每一位消费端要上线四个小时，最好让它们跟中心节点保持长连接，而不要使用你说的轮询方式断断续续跟服务器联系。

不知道你的消费者们处于内网还是外网，又不确定它们是什么样的软件（网页？手机应用？桌面软件？服务器？）。这些具体情况也会影响最佳的设计方案。无论如何，生产端要负责把任务请求分批发出去，也要处理消费端突然下线无法及时返回结果值的情况。

首先，你说的生产端一般叫消费者，而处于中心位置的节点才叫生产者，因为任务是从它那里发出来的。

既然每一位消费端要上线四个小时，最好让它们跟中心节点保持长连接，而不要使用你说的轮询方式断断续续跟服务器联系。

不知道你的消费者们处于内网还是外网，又不确定它们是什么样的软件（网页？手机应用？桌面软件？服务器？）。这些具体情况也会影响最佳的设计方案。无论如何，生产端要负责把任务请求分批发出去，也要处理消费端突然下线无法及时返回结果值的情况。

发现这个更多的是订阅数据, 收集边缘产生的数据,分发给订阅者的. 不知道我理解的对不对, 但我这边其实每个对象每5秒仅需要更新一次, 而且是想着 a,b,c,d,e... 生产端能负载均衡均匀的进行各类型对象的处理, 并且每个对象在周期内仅被一个生产端处理. 感觉在这块 zenoh 是不是不太符合, 还是我的理解有误

再补充一下就是, 生产端每个大概一次仅运行 4小时就会被销毁, 同时会有另一个被生产出来,

--
👇
sanri: 建议参考下 zenoh项目， https://zenoh.io/

好, 我去了解一下

--
👇
sanri: 建议参考下 zenoh项目， https://zenoh.io/

数据总线，那么zenoh是个待选项

--
👇
github.com/shanliu/lsys: 我也在找类似的数据总线实现 找到好的可以分享下 我目前用MQ来做,不直接通讯