正文
Scut 上线后遇到的问题
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
1. 上线后的大并发问题：
var sem = new Semaphore(_accepts, _accepts); while (true)
{
sem.WaitOne();#pragma warning disable 4014
_listener.GetContextAsync().ContinueWith(async (t) =>
{
try
{
sem.Release();
var ctx = await t;
await ProcessListenerContext(ctx, this); return;
}
catch (Exception ex)
{
TraceLog.WriteError("Http request unknow error:{0}", ex);
}
});
#pragma warning restore 4014
}
这段消息监听的代码在大并发时遇到了重大的问题，无论初始化多少信号量，都会进入等待消息的状态，只有完整地接受完一条消息，才会释放一个信号量出来。因此，特别是在单个协议较大，或者并发访问量较大的情况下，服务端很快会陷入大部分信号量被锁死在等待接收消息的情况。
解决方案则是在“建立连接-接收消息”上不做限制，而在消息处理阶段进行过滤；
2. .NET 嵌入 lua 虚拟机：
同事用 Lua 编写了一个静态的战斗逻辑处理器，可想而知，大量对这个处理器的使用，会导致各种各样的内存占用与GC问题。
因此对 Lua 虚拟机资源，还是要进行池化处理，进行资源管理。
3. Scut 对接受完整消息、逻辑处理、发送完整消息的超时控制缺失，这样会因为用户不稳定的消息传递、错误的逻辑代码导致资源被占用，一定要对各阶段进行超时控制，防止资源被超长时间占用。
4. Scut 的协议部分，在常规协议之外还支持追加更多消息，以其规定的分隔符进行分隔，但其采用的是“字符串匹配”的方式查找分隔符，而不是直接在包头中指定追加消息的起始索引，当常规协议的包身非常大时，字符串匹配会消耗较多的性能。
