sujin190

19 金币了。。

@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 服务器内存真豪啊！！！

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