有啥需求要这么干？

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

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

@drymonfidelia #4 看流出流量没有，流入只有 75 字节，IOCP 空闲状态但是线程池很高，估计不是连接管理有啥异常就是 await 调度异常了，想要解决只能慢慢加日志压测调试了，Sub/Pub 也算一种可行方案了吧，只不过实现起来就麻烦多了

不知道你们部署环境是啥，不介意加新服务的话，可以考虑下我们做的原子操作服务来提供加锁

https://github.com/snower/slock.git

有.net 的 sdk ，只需要换一下你这个加锁的逻辑就好，因为全异步的通信协议，所以不需要循环服务会主动异步通知，我们也在生产环境用很多年了，只是加锁没遇到啥问题，就你这请求量大概需要 100M 内存吧，也支持集群高可用模式

这个 LockTakeAsync 看下底层实现也就一个 setnx 指令，这请求量 redis 层面不可能超时吧，所以超时肯定是软件这边的问题了，线程池这么高不合理，要么是 redis 连接管理问题要么是 await 调度有死锁了吧，而且怎么记得 Task.Delay(1);似乎是延时 1 毫秒吧，这么短不合理也没必要吧，也很容易导致死锁和并发异常什么的，好歹延时个 50 毫秒吧

话说以用户 ID 加锁，那么客户端批量是统一用户的？ redis 的加锁 req 和 resp 协议加锁确实费劲，要不换个其它加锁服务试试？

300tps 要用 256GB 服务器内存真豪啊！！！

可以，就是这么干的，很好用

@tool2dx #5 你做一个就知道了，能通但是会丢包，有一次做网线就是这么想也是这么干的，好几间房几十根网线搞了一天搞完了用就是一直丢包，怎么调都不好

其实这个问题是网线是串行传输差分线，同一对构成差分线传输一路信号，百 M 就是两路千 M 就是 4 路同时传输，差分线的原理决定了同一路需要是双绞的，否则就会无法抵消环境干扰而有信号丢失就是丢包，这个其实就是 RJ45 网口坑的设计并不是一对组成的差分线不是完全挨着在一起的，就是 RJ45 网口设计历史遗留问题的锅，不过问题也不大，照着标准来就好了

握手阶段用 rsa 公钥加密和签名后续通信用的对称加密密钥呗，应用数据都是通过这个协商的密钥对称加密通信

@gold888 #25 其实射灯不需要单个分开控制吧，就算这样也可以再搞个智能开关在前面做总开关吧，设定下全部都关的时候就自动关闭总开关，不但可以解决你这个问题，还能省电不少

window 函数加 group by 不一下就查出来么

end 发送 fin 后，客户端暂时不给你回 fin2 而是继续发送数据，那你就是能继续收到数据的啊，就算客户端立刻关闭，那已发送的数据就应该继续收完了，本来你就需要等 close 事件，没啥问题啊，否则你直接 destory 就好了