想买黑色，但是没有 12G 内存的。。

vpn 搭建内网，然后直接访问或者主从同步或者热备份 sync 就是了啊

cython 之前用过，似乎无法完全自动解析 struct 或是 class 提供的指针，不过标准类型比如 char 的支持还是不错的，建议可以写一个 c 文件返回 char 字节流，然后在 python 中导入调用这个函数接收字节流，再用 cython 把 python 文件编译成扩展就行了，性能也不错的，不过我觉得写一个 python 扩展也不难啊

@coderluan #8 go 的文档没有特别强调，那估计是生成的代码是一样的，没有特别优化，而且编译号运行和 go run 直接运行似乎看不出性能差距，感觉应该是一样的

用又拍或者七牛

Thrift 编码协议自己也用了很久了，我感觉设计上还是有很多缺点的，效率也不高，感觉 grpc 和 protobuf 设计更好一点吧，如果自己重写 gen，那么工作量不小吧，如果修改 thrift rpc 协议，感觉兼容性或弱很多了

nas 就是存储啊，这就是最大的价值，拓展电脑手机容量，自动备份，最大的点就是容量大，数据不丢失，访问快

就好像现实世界的储藏室一样，你说一储藏室还要有啥特殊功能，就没用么

当然有人喜欢网盘，有人喜欢 nas，看自己喜好了

底层数据结构是的，只不过数组保存的是 object 指针，所以相比 c，即使保存数字这样的基础数据结构，仍然需要一次额外内存访问

可以动态增长是每次分配数组内存都是 2 的倍数，有额外空间，空间不足 resize 会申请一个新内存，然后 copy 过去，不过保存指针在数组值是大对象 resize 时性能又影响不那么大了

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

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

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

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

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

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

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

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

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