@libook #12 比如各种 fd 传到 native 读取数据去了，之后通过 callback 回传，你 callbak 函数很大可能并没有引用 fd ，那就是此时 fd 可能只被 native 使用了，应用层并没有持有 fd 是不是可以被 gc 了

@ysc3839 #13 每次 dup 可能有性能问题不合适，毕竟文件 IO 可能非常频繁

量化算法只是一小部分，毕竟玩这个的都是顶级聪明人，规则又在那，真能搞出一个别人都不知道就你能挣钱的算法那不是白日做梦么

你去真玩一下就知道以上基本废话没啥用，要这么简单策略就能挣钱大家还上啥班啊，就算历史数据回测看着还行也意义不大，具体为啥你真金白银搞个几十万进去玩一下就能体会了

同感，特别是服务端都是单 module 小项目，idea 打开项目构建编译那卡的，而且比 maven 耗资源多多了，就算放到 ci 服务器上也比 maven 慢很多，而且对通过启动在 docker 容器构建编译一点都不友好，都也还得再 ci 宿主机去一台一台设置好各个版本的 jdk

还有个毛病就是如果同时使用不同版本 gradle ，ci 服务器会同时存在多个 demon 进程，分分钟撑爆服务器内存，不知道大家都咋解决这些问题的

不过说起来你都收到解码了，转码换更低分辨率确实毫无意义吧，分辨率低搞更高分辨率除非用最近搞出来的超分 AI 算法，否则毫无意义吧，所以既然发送端不支持改分辨率改码率，你这个需求本身就毫无意义了吧

接收端修改的意思应该是向对方发送申请新分辨率的视频流吧，应该不是让本地转码改变分辨率吧，看你这情况对方肯定不接受啊，所以显然改不了，视频分辨率不重新转码应该是改不了分辨率的吧，否则各大视频网站也就不需要为每种分辨率在服务端提前转码并单独保存了，或许你应该在收到视频流后先用媒体扩展转个码再发送给 video 标签吧

@yustation 就 iptables 呗，可靠性和性能都没啥问题啊，不方便用也可以搞个端口转发程序也行啊

@yustation 主机内部端口 rewrite 就好吧

有啥需求要这么干？

只同步数据的话那分享下项目

https://github.com/snower/syncany-sql

把 SQL 当作脚本执行，内部有自动依据主键增删改同步数据的逻辑，可以用 crontab 来调用

set @use_output_type='UPDATE_DELETE_INSERT';
insert into `pg2`.`adata` select `id`, `name`, `create_time` from `pg1`.`bdata` where `id`>=2;

使用 set @use_output_type 设定更新目标库方式，可选值有 INSERT 、UPDATE_DELETE_INSERT 、UPDATE_INSERT 、DELETE_INSERT ，不设置时和正常 insert into 一样默认 INSERT ，select 的第一个字段自动认为是主键，相同主键执行 update ，否则插入

大概率不能，串口就没状态线

nfs 呗，直接挂载磁盘

在你这假设下，宇宙有没有都不好说，还关心啥世界啊

@chaleaochexist 可以这么认为，数据层是对数据准确、严谨并且完整无歧义的读写封装，理论上不应该和具体的需求场景上有关联，虽然吧数据结构完全是按产品和业务需求来设计的，但在软件分层架构中按产品和业务需求设计完数据结构后，我们却首先应该抛弃产品和业务的具体需求和场景，完全按照数据结构自身来设计标准数据读写封装层，而且吧现实情况下太多时候一个具体的产品和业务需求可能只有一个数据读写，如果没按标准分层架构设计，后续一部分变更需求逻辑后，很大可能就越来越混乱一塌糊涂了

数据层和业务层不难区分吧，数据层主要封装的是对数据结构逻辑的读写，这个包含着完整数据逻辑，大多数情况下一个数据逻辑只有一个读写操作，但有时候也会有多个，也许层对应的自然是现实需求和产品表达的具体实现了

举个简单例子，判断是都是超级用户这显然是一个数据逻辑，在用户登陆成功后需要判断是否是超级用户提示不可用这显然是业务逻辑

数据层不应该对应使用场景，而业务层必定应该对应具体使用场景，就这样啊

@hez2010 话说似乎 garnet 是多核多线程的吧，redis 似乎是单线程的，应该是负载一样的来比吧

@hez2010 没懂你这是服务端多线程还是测试工具多线程，否则就算单核也不可能这么低吧，话说咱要测的是服务端性能吧，而且差距这么大 128 核心？

.net sdk 在这 https://github.com/snower/slock4net