V2EX › sujin190 的所有回复 › 第 76 页 / 共 122 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 72 73 74 75 76 77 78 79 80 81 ... 122

❮

❯

2019-04-25 16:36:50 +08:00

回复了 zhze93 创建的主题 › Tornado › Tornado 如何拿到传输的文件流

@zhze93 #2 正常 request.files 肯定是解析好的，requests.post 上传文件不是这么写的吧，你这是把文件内容读出来整个放到 body 里了，所以服务端 request.body 就是文件内容吧，直接写入文件就行了

2019-04-25 15:45:01 +08:00

回复了 zhze93 创建的主题 › Tornado › Tornado 如何拿到传输的文件流

RequestHandler 上有 request 属性，request 这个有 body 原始字节属性，和 files 属性吧，files 就是已经被解析成 file 对象，body 则必须你自己解析了

再说调试下就知道了啊，python 用 pycharm 啥的还是调试很方便的

2019-04-18 14:26:12 +08:00

回复了 litp 创建的主题 › 投资 › v2er 们我要入股市的坑了，求推荐交易 APP 和良心叮嘱！

如果毫无经验平均预计 9 成可能会亏损超过百分之 30，所以悠着点啊，别一开始就想着赚钱，牛市起飞啥的都是扯淡，你仍然极大可能会亏损

2019-04-18 14:11:20 +08:00

回复了 void1900 创建的主题 › 程序员 › 一天 2 亿 pv 左右一般需要多少台机器，目前 swoole+redis+mysql

看业务复杂度吧，如果只是简单的 redis inc，那么一台都绰绰有余
一般来说，只是 redis inc，每个请求时间顶多 1ms，一个进程每秒 800 到 900 完全可以吧，swoole 8 核 cpu8 进程不要太轻松

2019-04-17 17:14:17 +08:00

回复了 fdgdbr 创建的主题 › Redis › 有没有支持 jdk5 的 redis 客户端

如果你们操作的命令也不多就直接 socket 构造指令发过去算了，redis 协议也不复杂
可以抓个包，替换下参数轻松搞定，请求量低还长连接都不用考虑，直接短连接直接用就是了

2019-04-16 17:30:10 +08:00

回复了 cwbsw 创建的主题 › 宽带症候群 › 工信部又打 IPV6 的鸡血了

@undeflife #7 恰恰不行，正因为太多了，网络会使用自动配置，家里固定宽带弄成固定地址都很难，但是移动设备基本不可能，再加上本来升级 ipv6 就是所以入网设备都有独立地址，到时接入设备量增加到海量，追踪查询更加难了吧

2019-04-08 18:25:58 +08:00

回复了 wuchengkai0 创建的主题 › Docker › docker 开启 BBR 有什么好的方式？

@Havee docker 容器里边不是单独内核单独网络栈的么？通过网桥连接网络，宿主机开 bbr 为啥会影响容器里边的 tcp 拥塞控制算法？

2019-04-04 14:48:46 +08:00

回复了 hfbb 创建的主题 › 奇思妙想 › 关于扑灭森林大火的一点想法

山林大火的难点，不是在于明火扑灭，而是烧后未完全熄灭的木头之类的东西即使在低氧环境依然能烧十几个小时，干燥的环境借着山风很容易复燃，往往是你刚扑灭转身又烧起来了，而且很多木头烧成木炭的时候在被强风吹都有炸裂成小痰屑随风吹走的问题，单纯从扑灭明火来说我觉得不难，也不那么危险，复燃问题才危险，想想看正在前面战斗，一转头发现已经被大火包围，多恐怖

2019-04-04 14:39:24 +08:00

回复了 hfbb 创建的主题 › 奇思妙想 › 关于扑灭森林大火的一点想法

想多了，大山上用导弹消灭可燃物，你怕是嫌烧的不够旺，大山里，几颗导弹能造出云？你不是逗的吧，一阵风就吹不知道哪去了

@Very0ldMan #26 你这个只对平原小树林也许有点用吧，大山上，山风加低处茅草，推进速度比你跑的还快，而且未燃尽的草灰一飞上百米，再来阵风，瞬间就是熊熊大火，再说一旦大火，山势陡峭，凭人力快速砍出隔离带完全不现实

2019-04-04 10:57:15 +08:00

回复了 baiyun888 创建的主题 › 奇思妙想 › 关于儿童定位的一个想法

其实这种的问题估计还是完全做的掩蔽很难，你做出来了，人贩子学的也很快，应对太简单了，比如走出一点就会搜身，不具备门槛，这样的话就没用了，而且地下室、偏远地区，更甚人贩子会有专门的屏蔽安全屋之类的，完全没用，如果只是想离你远一点就报警，那么手表是最好的，现在也有很多人做这个了吧

硬件上来说，做到硬币大小应该是没问题的，iot 设备也很省电，普通 gps+gprs 方案，平时完全可以关闭 gprs，gps 的话，只需要快速移动的时候提高扫描频率，平时分钟以上扫描，估计撑个一个月也没啥问题吧，真出事有 gps 帮助，两三天了还找不到，那啥也别说了，所以这不是个技术问题

2019-04-03 17:53:27 +08:00

回复了 1oNflow 创建的主题 › 问与答 › 为什么中小企业的技术栈不喜欢 Java ？

效率低，入门门槛高，招人换人麻烦，大多框架配置文件怎么写都得看三天，费劲死了，部署发布还麻烦，要有这时间 php python 都快做完了

2019-04-02 11:55:34 +08:00

回复了 yanluya 创建的主题 › PHP › PHP 异步通知（微信通知，短信通知，邮件通知）怎么做？如果全部等待返回结果会卡死

另外弄个小发送服务呗，用 grpc、thrift 啥的弄个也很快了，几分钟就搞定，单量少，也就不需要考虑那么多了，加到 supervisor 进程管理里，很简单了

或者更简单的，另外写个接口发送通知，再用 fscokopen 构造一个 http 请求，但是不等待返回就是了

2019-04-01 11:37:25 +08:00

回复了 blueorange 创建的主题 › 程序员 › mysql 单表数据过大最好的处理方式

如果只是 4 到 5 项索引，写性能影响不大吧，除非你写特别多，如果每秒过千的写，估计也不是单表千万数据的问题了
千万级别对 mysql 数据真不算大，如果索引超过内存很多，倒是可以多加点内存，索引和查询缓存的效果还是很明显的

2019-03-28 17:04:19 +08:00

回复了 im3feng 创建的主题 › 问与答 › 关于软路由硬件配置的一点想法

@jimmy #70 忽略不计，既然是梯子，这点流量就算 cpu 计算影响也可以忽略不计了吧