@xidianzyf #3 如果是 AWS 的话，就非常简单，几乎不用写代码。
1. IoT Core 用于和所有设备保持连接，并收集消息。IoT Core 没有连接数上限。
2. 将消息流输出到 Kinesis Data Firehose 中，可以讲将原始数据存储到文件存储 S3 中。Firehose 具有完全弹性，因而可以承载足够多的设备消息。
3. 使用 Kinesis Data Analytics SQL，使用 SQL 语句从 Firehose 流数据中实时查询。可以配置使用滑动窗口查询，比如收集每分钟的数据查询一次，每分钟出一系列的查询结果。
4. 使用 AWS QuickSight 展示 Kinesis Data Analytics SQL 的查询结果。

我不熟悉国内的云，但如果有对应的组件，也可以极大地减少开发成本。比如说压力最大的 hold 连接、转发到队列这里可以用基本具备完全弹性能力的函数计算，或者你愿意用负载均衡器和弹性伸缩组也行；把消息丢到托管消息队列里面；然后你的服务基本就不会崩溃了，后面你怎么读消息怎么可视化就无所谓了。

大量是多大量？数万吗？
这个需求能上云的话随随便便就搭一个出来。不能上云就按楼上的办。

那不是有五个触点么。

图裂。

pac 脚本没问题吧。可以试试直接用 curl 取一下 pac 脚本，看看用时

老哥在 p2p 干来着？

@newbieRenew #3 纠正一下，辞退叫赔偿，不续签叫补偿。🐶

这相当于公司给你提供一个额外的选项，不选没有任何损失。

凡是概率低于 50%的，建议你们把题目中的参数改成“....目击者在当时能够正确辨认出这两种颜色的概率是 [100%] ”，带入你们的公式，看结果合逻辑不？

@crs0910 #18 @JimmyG #17 @wjfz #14 @Tardis233 #11 @iVeego #7

可以看看 Speedify

干啥能上两万连接？

@scf10cent #12
你提到自用的后端对性能不敏感，是 Flask ；前端是独立的函数。那你前端还是几乎不依赖框架裸写咯？在生产场景下，普通的后端程序员不依赖框架的工作效率是很低的。至于对性能不敏感的管理端，部署在 lambda 中也没有太大意义。

厂商是在优化冷启动问题，但更多的是用户代码之外的冷启动速度优化。Flask 作为用户代码，几乎没法优化冷启动效率。

我家的就有

@gwy15 #6 用 Flask 冷启动很慢吧。

请详述你的原始需求。

建议注明是 Android 平台。

七十五万转，认真的吗？

@ynyounuo #1 色情领域那种就是预告片，想看正片开会员。