对 SQL 的调用会导致我的多线程应用程序出现瓶颈吗？

Question

在我的多线程应用程序中调用 SQL 是否会导致应用程序成为瓶颈？

我使用的逻辑有效并且符合最佳实践吗？

static void Main(string[] args)
    {
        try
        {
        TcpListener listener = new TcpListener(IPAddress.Any, 8000);
        TcpClient client;
        listener.Start();

        while (true) // Add your exit flag here
        {
            client = listener.AcceptTcpClient();
            ThreadPool.QueueUserWorkItem(ThreadProc, client);
        }
        }
        catch (Exception ex)
        {
        Console.WriteLine(ex.Message);
        Console.ReadLine();
        }

    }//Main


    private static void ThreadProc(object obj)
    {
        var client = (TcpClient)obj;
        // Do your work here...

        NetworkStream ns = client.GetStream();

        using (StreamWriter writer = new StreamWriter(ns))
        {
           writer.WriteLine("220 SMTP server ready.");
           writer.Flush();

           using (StreamReader reader = new StreamReader(ns))
           {
              //parse + persist smtp message here...
              //save email message parts to a Email table in SQL SVR(from, to, body...)
           }
        }
    }//ThreadProc

Answer 1

我解决这个问题的方法是拥有一个队列，您可以在其中添加要解析和持久化的内容，然后由一组线程（甚至只是一个线程）提供服务，这取决于预期的吞吐量。这里的关键是尽快为队列提供服务，但如果有积压，也不会影响添加更多项目。

编辑：

你的场景中有很多未知因素，所以我的解决方案同样模糊，但我应该解释一下。

你的问题是我不知道你的sql将运行多长时间，或者如果失败/超时应该采取什么操作，或者你期望排队或运行多少个sql语句。

我的解决方案是首先提取面向公众的接口，用于 a) 对操作进行排队和 b) 处理操作。这使您有机会在以后甚至现在将排队机制切换为更合适的机制。

因此，假设您正在对工作项进行排队，并且数据库停止响应。突然之间，什么都没有被保存。这会影响您的应用程序的功能吗？这里是否存在任何交易问题？将工作项写入 MSMQ 之类的东西也许会更好吗？ SQL Server 还有一个代理服务，它可以很好地满足您的需求。

所以我不打算添加任何代码，而是从这些角度思考：

1）指定接口 接口：

public interface QueueWorkItem
{
无效AddWorkItemToQueue（工作项项目）；
ConsumeWorkItem

公共接口
{
布尔 ItemsInQueue {获取;}
工作项 GetNextItem();
。

您不必使用这些，这只是示例

2）构建一个实现接口的类
这是有趣的一点，您必须担心线程和阻塞（寻找生产者消费者模式）您始终可以使用线程池并让 ConsumeWorkItem 实际上什么都不做。

最后，我们来谈谈线程池。很好，但是您对它没有太多控制权，并且不能保证其中运行的所有线程都是您的。

希望有帮助。