go 吃了 goroutine 设计的亏吧
goroutine 有最小内存负担

nodejs 的 promise 和 C#的 Task 都是简单对象，内存负担很小

tokio 就不太清楚了

这个 benchmark 最不好的地方在于，任务太不实际了，10s 空转，任务本身没有内存负担，又是高耗时
如果一个任务本身的内存负担比较大，那 goroutine 的最小内存负担相对来说就不那么明显了
实际场景里，真正关注的还是吞吐/内存效率

取决于需不需要 i18n ，如果不需要 i18n ，那就应该把所有环境时间统一设定为+8
如果需要 i18n ，那就所有环境时间统一设定为 utc

这种技术方案在遥测领域有很多
粗看下来我的直觉方案是：
缓冲（内存+本地），使用 WAL
批量填入 tsdb
甚至可以不写入 tsdb ，取决于你有多少传感器，如果是有限数量的话，可以直接写入文件，看使用数据的场景来决定是否需要 parquet+bloom filter
如果传感器数量很多又是动态的话，可以使用云对象存储来做

口头答应 拿到补偿后追缴

涉钱要征信很正常吧

涉命应该也要征信的，比如飞行员之类

严格说的话其实花不了这么多钱
先查炎症反应 再查当前季节的流行病 一般有的话一个一个查，或者 3 合 1 查，大多数情况下很快就命中了，医生肯定知道最近哪些流行病比较严重
这种 N 合 1 就是医院/医生图省事不把患者/医保的钱当钱

可怜

@blessingcr

你这交互是 请求-响应 模式的，内部实现可以用 http grpc 或者 mq 都行

> 有的在内网有的在外网，MQ 不能暴露在外网
mq 是个内部系统的基础设施，和外界交互肯定还是得用 [接口] 啊
比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口
或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息
或者 更简单的，直接建立 websocket 连接，使用类似聊天室的框架（比如 signalr ），单播、广播也一块支持了
类似的方案到处都是

> 确保对于某一业务而言消费串行

这个和区块链有啥关系，用区块链性能不更低了
这就看一致性在哪保证，如果是数据库来保证就是用数据库事务，你反正也是中心存储的
如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性

槽点过多……
这不就是并发一致性问题么

无论是同步的 http ，还是异步的 mq ，你这业务场景都是命令消息，都是请求-响应模式的
一致性冲突的话直接把该失败的请求失败掉不就行了

http 就不说了，mq 的话

1.：发送请求上架消息，等待上架结果消息
2.：处理请求上架消息，发布上架结果消息
3.：收到上架结果消息，完成上架

如果这个流程时间很长的话，就给个“上架中”的中间状态来跟踪
锁用来保证局部的一致性

关区块链啥事啊，你这不是中心化的数据存储吗

你这个图也挺抽象的，第一次见到这种图，solidworks 画的吗

如果能稳定盈利确实可以不上班

走个牛熊周期验证下是不是能稳定盈利呗

赛博魔怔人

我自己的选择是买实体金条
不作为建议

另外一个也许有点不合时宜的提醒是：别轻信买美股买美债的说法