最近,在使用EventStore的.NET Client API采用大量线程池线程同步写入Event时(用于模拟ASP.NET服务端大并发写入Event的情况),发现EventStore的连接会随机中断,并且在服务端日志中显示客户端连接Heartbeat超时(如果不了解EventStore,请点击传送门)。由于系统中全局共享一个EventStore连接,当连接中断时,会导致所有的写入操作被Block,而EventStore连接的重连速度比较慢(测试机器上重连需要耗费20秒到1分钟),这样会导致比较严重的性能问题、甚至导致客户端请求超时。

示例代码如下:

for( int index=0;index<100;index++)
{
Task.Run( ()=> { connection. AppendToStreamAsync(...).Wait(); } );  
}

也许有人会问,为什么不为每一个请求单独建立一个EventStore连接?好吧,绕开官方文档推荐使用单连接这个问题不谈,似乎为每一个请求建立一个连接是一个好的解决方案,但是实际测试发现这个方案比单链接方案更不靠谱。经过测试发现(使用EventStore版本3.0.5.0测试),为每一个请求单独建立连接会有以下几个方面的问题:

1)每次请求都需要重新连接EventStore Server,耗费的时间比较长,性能比单连接差。

2)重复的建立和断开连接会导致EventStore服务端的TCP端口失去响应(大概30K次连接之后),在这种情况下除非重启EventStore Server,否则客户端再也无法连接上EventStore Server。

3)如果一个连接非正常中断,则所有的连接都会断开重连。

由于多连接存在上面的问题(中途也尝试过连接池,发现也同样存在上述问题),我们只能在单连接这个方向上继续前行,我尝试着将上面的代码修改为如下形式,竟然发现问题神奇的消失了。

for( int index=0;index<100;index++)
{
var tempThread = new Thread(()=>{connection. AppendToStreamAsync(...).Wait();});
tempThread.IsBackground = true;
tempThread.Start();
}

  这两段代码有什么区别呢?有问题的代码是使用线程池的线程来同步写入Event,而没有问题的代码则使用线程同步写入Event,貌似没有什么区别。会是什么问题呢?我又回过头将第一段代码修改为如下形式(将同步写入修改为异步写入,注意:将Wait方法调用去掉),竟然也发现没有问题。

for( int index=0;index<100;index++)
{
Task.Run( ()=> { connection. AppendToStreamAsync(...); } );  
}

  那么问题出在什么地方呢?会不会是EventStore本身的问题呢?由于使用HTTP接口来写入Event非常的稳定,可以基本排除是Event Store Server的问题,那么EentStore .Net Client API有问题的可能性就比较大了。

没有办法,从GIT上下载EventStore的源代码开始调试,最终发现了问题可能是下面的代码引起的:

public void EnqueueMessage(Message message)
{
Ensure.NotNull(message, "message"); _messageQueue.Enqueue(message);
if (Interlocked.CompareExchange(ref _isProcessing, 1, 0) == 0)
ThreadPool.QueueUserWorkItem(ProcessQueue);
} private void ProcessQueue(object state)
{
do
{
Message message; while (_messageQueue.TryDequeue(out message))
{
Action<Message> handler;
if (!_handlers.TryGetValue(message.GetType(), out handler))
throw new Exception(string.Format("No handler registered for message {0}", message.GetType().Name));
handler(message);
} Interlocked.Exchange(ref _isProcessing, 0);
} while (_messageQueue.Count > 0 && Interlocked.CompareExchange(ref _isProcessing, 1, 0) == 0);
}

  这段代码的目的是将客户端写入的自定义事件或者系统产生的事件(无论客户端写入的自定义事件还是系统事件都会被存储到一个唯一的Queue中),顺序的发送到服务端。说到这里就必须提一下EventStore TCP连接的心跳机制,当客户端与EventStore服务端建立连接之后,客户端会定期发送一个Heartbeat事件到服务端,通知服务端客户端还活着,如果在一定的时间内,服务端收不到来自客户端的Heartbeat事件,那么服务端会主动关闭连接,并且在日志中记录一条客户端Heartbeat超时日志。

那么这段代码与连接中断有什么关系呢?注意,客户端的Heartbeat事件也是通过这段代码发送到服务端的。如果,我说如果,由于什么原因导致Heartbeat事件不能及时的发送到服务端,会不会导致连接中断呢?答案是肯定的。

那么这段怎么看都没有问题的代码为什么在使用线程池线程并发写入的情况下会导致Heartbeat事件发送不及时呢?是不是这句话有问题?难道在大并发的情况下QueueUserWorkItem会导致ProcessQueue的调用会被延迟?

ThreadPool.QueueUserWorkItem(ProcessQueue);

  为了验证我的想法,我创建了一个System.Threading.Thread.Timer,定时100毫秒,在Callback中输出两次Callback之间的时间差,当大量的使用ThreadPool的线程时,发现两次Callback之间的时间差慢慢的从200毫秒,越变越大,直到到好几秒。问题到这里就已经很清楚了,当ThreadPool的线程被大量占用时,通过QueueUserWorkItem注册的回调方法会有一定的延迟,具体的延迟时间与ThreadPool的线程被占用的时间和数量有关系,对于实时性要求比较高的任务,比如EventStore的ProcessQueue来说,是不适合使用QueueUserWorkItem来注册回调的。

最后,我将EventStore代码中的QueueWorkItem调用替换为线程调用,发现问题解决。

后续,为了说明这个问题,我在EventStore的Group中发布了一个帖子说明这个问题,EventStore的作者认为Task.Run不能真实的模拟ASP.NET的情况,建议我到真实环境中测试。为此我创建了一个简单的ASP.NET MVC项目和一个简单的客户端,模拟大压力下两种实现的差别。通过测试发现,使用原版的API,随着并发线程数量的增长,Event的写入速度越来越慢,而使用修改后的API,则发现随着并发线程数量的增长,Event的写入速度变化不明显,基本上没有太大的差别,理论上来说在某一个并发下应该会导致Heartbeat超时。由于IIS默认并发访问数量的限制,又懒得去调整服务器,并且由于IIS本身又管理了一套连接池,想压出Heartbeat超时比较困难,就没有做Heartbeat超时的压力测试。

EventStore .NET API Client在使用线程池线程同步写入Event导致EventStore连接中断的问题研究的更多相关文章

  1. Java基础学习笔记: 多线程,线程池,同步锁(Lock,synchronized )(Thread类,ExecutorService ,Future类)(卖火车票案例)

    多线程介绍 学习多线程之前,我们先要了解几个关于多线程有关的概念.进程:进程指正在运行的程序.确切的来说,当一个程序进入内存运行,即变成一个进程,进程是处于运行过程中的程序,并且具有一定独立功能. 线 ...

  2. Java多线程面试题:线程锁+线程池+线程同步等

    1.并发编程三要素? 1)原子性 原子性指的是一个或者多个操作,要么全部执行并且在执行的过程中不被其他操作打断,要么就全部都不执行. 2)可见性 可见性指多个线程操作一个共享变量时,其中一个线程对变量 ...

  3. 运用JAVA的concurrent.ExecutorService线程池实现socket的TCP和UDP连接

    运用JAVA的concurrent.ExecutorService线程池实现socket的TCP和UDP连接 最近在项目中可能要用到socket相关的东西来发送消息,所以初步研究了下socket的TC ...

  4. android线程与线程池-----线程池(二)《android开发艺术与探索》

    android 中的线程池 线程池的优点: 1 重用线程池中的线程,避免了线程的创建和销毁带来的性能开销 2 能有效的控制最大并发数,避免大量线程之间因为喜欢抢资源而导致阻塞 3 能够对线程进行简单的 ...

  5. C# 显式创建线程 or 使用线程池线程--new Thread() or ThreadPool.QueueUserWorkItem()

    在C#多线程编程中,关于是使用自己创建的线程(Thread)还是使用线程池(ThreadPool)线程,一直很困惑,知道看了Jeffrey Richter的相关介绍才明白,记录如下: 当满足一下任何条 ...

  6. ThreadPool.QueueUserWorkItem引发的血案,线程池异步非正确姿势导致程序闪退的问题

    ThreadPool是.net System.Threading命名空间下的线程池对象.使用QueueUserWorkItem实现对异步委托的先进先出有序的回调.如果在回调的方法里面发生异常则应用程序 ...

  7. java 线程池线程忙碌且阻塞队列也满了时给一个拒接的详细报告

    线程池线程忙碌且阻塞队列也满了时给一个拒接的详细报告.下面是一个自定义的终止策略类,继承了ThreadPoolExecutor.AbortPolicy类并覆盖了rejectedExecution方法把 ...

  8. 线程池线程数与(CPU密集型任务和I/O密集型任务)的关系

    近期看了一些JVM和并发编程的专栏,结合自身理解,来做一个关于(线程池线程数与(CPU密集型任务和I/O密集型任务)的关系)的总结: 1.任务类型举例: 1.1: CPU密集型: 例如,一般我们系统的 ...

  9. 线程池+同步io和异步io(浅谈)

    线程池+同步io和异步io(浅谈) 来自于知乎大佬的一个评论 我们的系统代码从同步方式+线程池改成异步化之后压测发现性能提高了一倍,不再有大量的空闲线程,但是CPU的消耗太大,几乎打满,后来改成协程化 ...

随机推荐

  1. JavaScript基础练习(一)

    加法的案例改为 可以做加减乘除.求余五种运算 为抵抗洪水,战士连续作战89小时,编程计算共多少天零多少小时? (function(a){ alert("战士连续作战"+parseI ...

  2. go中操作json

    package main import ( "encoding/json" "fmt" ) type Server struct { ServerName st ...

  3. properties文件不能输入中文

    先把他关掉,然后对message.properties 文件右键--属性(properties), 右边最下面一行text file encoding选择other里面的最后一个utf-8, 再点击a ...

  4. 记一次前端问题解决历程(Cannot read Property 'call' of undefined)

    场景 echosong 回长沙两个多月了, 新公司的创业项目 App , 小程序, 公众号. 目前差app 没有 做完. 公众号在前端小美女同事 的主导下采用前端比较火的Vue 技术框架. 一直一来主 ...

  5. 【PAT】1007. 素数对猜想 (20)

    1007. 素数对猜想 (20) 让我们定义 dn 为:dn = pn+1 - pn,其中 pi 是第i个素数.显然有 d1=1 且对于n>1有 dn 是偶数.“素数对猜想”认为“存在无穷多对相 ...

  6. c++ 容器学习 理论

    [转载]http://blog.csdn.net/acosoft/article/details/4395468 在面向对象的语言中,大多引入了容器的概念.那么 什么 是 容器?实质上就是一组相同类型 ...

  7. [实战]MVC5+EF6+MySql企业网盘实战(21)——网盘操作日志

    写在前面 上篇文章介绍了一个bootstrap的分页插件,这篇将弄一个完整的例子,就以日志分页为例说明如何请求服务端然后进行分页. 系列文章 [EF]vs15+ef6+mysql code first ...

  8. 使用matplotlib绘图(四)之散点图

    # 使用matplotlib绘制散点图 import numpy as np import matplotlib.pyplot as plt # 设置全局刻度标签大小 plt.rcParams['xt ...

  9. luoguP3600 随机数生成器 期望概率DP + DP优化

    这篇题解更像对他人题解的吐槽和补充? 考虑答案 $E[X] = \sum\limits_{i = 1}^{x} i P(X = i)$ $P(X = i)$不好求................(其实 ...

  10. 【最小割】【Dinic】HihoCoder - 1252 - The 2015 ACM-ICPC Asia Beijing Regional Contest - D - Kejin Game

    题意:有一个技能学习表,是一个DAG,要想正常学习到技能x,要将指向x的技能全部先学到,然后会有一个正常花费cx.然后你还有一种方案,通过氪金dx直接获得技能x.你还可以通过一定的代价,切断一条边.问 ...