@TtTtTtT #14 通用沙箱 python 这种想对性能影响不大确实不容易，但看楼主需要似乎做的是类似 Google colab 的服务，应该是需要在调用特定算法库或者访问网络磁盘计费，这种就还好了吧，毕竟静态编译的 ast 分析分歧小但是加钩子还挺麻烦的，python 加钩子拦截可就容易的很了，安全调用和 cpu 内存限制其实放给容器或者其他通用沙箱环境就好了，没必要在 python 层面弄吧，毕竟系统层面弄这些可比 python 层面弄这些容易多了性能损失也最小

@f1ynnv2 #10 确定不是写的问题，我们十多个进程每天写入数十 G 的时候没发现有错行的问题，也这样运行好多年了，没发现啥异常

https://gist.github.com/snower/adcf300f3daff99549dbe1949982a5dc

我们项目就是重写了 doRollOver ，使用文件锁来处理，这样就算多个进程是独立创建的也没有问题，只是似乎不能在 windows 上用，而且这个函数只有在需要重新创建日志文件的时候才会调用，正常写日志的时候不会有影响，所以也没啥性能问题

如果你日志是有时许的，每个进程写单独文件，看日志的时候还不累死了，不就是时间的文件归档有问题么，修改下 doRollOver 加个锁就是了呗，也不是啥麻烦的事情

@mythjava 那我猜你需要计费的代码应该是 numpy 和 pytorch 这样重数学计算库，或者大量文件和网络请求吧，参考 gevent monkey patch 的思路做拦截计费就行吧

@mythjava 提取出来用途是啥？ python 好多都是运行起来才知道的，静态分析还是有限，如果想有限运行，那还不如搞沙箱来的容易一些

@TtTtTtT #3 加上闭包动态属性什么的一周都不一定能搞定吧

说不定还是直接运行一下然后通过 trace 追踪一下那些行被调用了实现起来更快呢，话说你干嘛呐？多余的代码就多余呗，耗点性能也无所谓吧

@julyclyde #13 是的，需要 pip install sevent

python -m sevent.helpers @arproxy -p 80 -T none @arproxy -p 443 -T none

一条命令行就可以，不但会解析 sni ，普通 http 还会解析 header 通过 HOST 字段提取域名，如果你还有上级代理得话也可以指定转发到上级代理来访问

如果你已经有代理了话，其实可以不需要再境外 VPS ，指定 hosts 后，通过 iptables 重定向流量到命令行启动的端口，然后再转发到代理就好了

或许可以更粗暴点，从 RocketMQ 收到消息通过新的交换机再次发送 RocketMQ 各个不同的数据源队列去，然后各数据源各自消费者，反正不成功消息不会从队列消息，自动就有重试

顺势顺周期，金融周期，货币周期，库存周期，信心情绪周期，科技商业周期

@MFWT #5 CA 的体系不就是你说的这个么，只不过系统都集成好了，标准的证书校验本来就是用预制 CA 来校验证书签名，你说的这个预共享的 Hash 其实就是预先安装的 CA 证书，如果不方便安装的话而且似乎大部分语言发起 TLS 的时候都能手动指定 CA 证书吧

既没人认真写，写了也不会有人认真看，这才是现实

@SANJI59 处理跟不上慢的话看日志应该很好区分吧

@SANJI59 #24 就是服务器收到设备返回的开启成功的通知但是数据库看订单状态没改？这订单状态应该是服务器改的吧，这还会有问题？莫非是主从延迟导致的？或者是事务提交延迟？不过正常应该是订单创建完成强制事务提交了之后才给设备发的指令的吧，用 spring 这种框架的话要注意框架的自动事务管理逻辑啊，一般来说如果你的设备操作只是一个简单的电磁锁开关的话，估计延时能在几十毫秒到 200ms 以内吧，数据库负载上来事务提交延时超过应该还是很容易的吧

@SANJI59 #16 顺便说，小程序要使用 ws 的原因一般也是因为 Http 接口服务和 mqtt 服务不是同一个，服务返回结果，分享一下我们再用的 Spring Boot 可以跨服务的 Event 吧

https://gist.github.com/snower/f8ef25e57c72f9b41fb31ee8b164193b

逻辑也毕竟简单，创建完成订单给设备发送命令前用订单号为 key 创建一个 Event ，然后接着给设备发送命令，设备执行成功后服务的收到结果通知更新万订单状态后，用相同的订单号为 key 也创建一个 Event ，接着调用 set 设置 Event ，http 接口这边 wait 就可以收到反馈了，具体订单信息可以再读数据库就好了

不过依赖一个外部服务来完成的

https://hub.docker.com/r/sujin190/slock

@SANJI59 #16 其实如果订单通过 http 请求发送的话，结果通过一个 long poll http 接口来获取应该是更简单可靠的

https://segmentfault.com/a/1190000041190907

我们直接也搞过不少这种，还是 http long poll 更方便，搞过 openrest 的，用 spring boot 的话担心连接占用过多线程，其实可以用 DeferredResult ，工作线程会被释放，连接放到底层 nio 了，也可以支持大量并发请求

@sujin190 #15 那就是说小程序其实是通过单独的 http 接口创建订单然后给设备发送指定的，那话说你怎么保证这时候 ws 是已经建立好的了啊？那会不会高峰期无论是带宽紧张还是应用负载原因导致 ws 建立成功时间变长了那是不是要出错了？设备执行命令成功给服务器通知结果其实应该是更新数据订单状态了吧，小程序通过数据库订单信息补偿就好了啊

1500 个设备都很少了，话说都没写日志的么？你这描述了半天看起来也没弄清楚是设备给服务器回开启成功有问题还是服务器给小程序回开启成功有问题，你这设备接入用的 mqtt ？而且你小程序是用 ws 发送给的开启指令么？其实阿里云的 IOT 云的 RR 消息就很容易处理这种，小程序这边短时请求用 ws 确实费劲，几千台设备么单体服务也足够也不复杂