sujin190

.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 就好了