ServiceStack.Redis对多线程的支持

zycchen

　　上周四上线了一个东西
　　要在多线程的情况下访问Redis
　　以前也用过ServiceStack.Redis去访问Redis
　　加上这玩意在Redis官方网站推荐指数排第一
　　果断就选择用它了
　　


　　考虑到我是在多线程的环境下使用的
　　所以特意还去关注了它对多线程的支持
　　看着他们api图上大大的一排鸟语:ThreadSafe Access
　　我笑了
　　


　　结果今天早上一到公司
　　一看数据
　　所有的东西全挂
　　回顾了一下上周上线的内容
　　一下就确定是ServiceStack.Redis在作怪
　　立马停掉
　　然后拿下日志分析
　　发现报了很多很诡异的异常...
　　例如:
　　System.Runtime.Serialization.SerializationException: Type definitions should start with a '{', expecting serialized type 'SubscriptionModel', got string starting with: 1

ServiceStack.Redis.RedisResponseException: Unknown reply on integer response: 43OK, sPort: 8223, LastCommand:

ServiceStack.Redis.RedisResponseException: Unexpected reply: +OK, sPort: 8223, LastCommand:

然后东西就不明不白的假死了
　　看了下我的代码
　　所有可能的异常都处理了啊
　　这些小小的异常根本不可能搞死我的程序啊
　　于是猜想难道是ServiceStack.Redis内部的机制导致内存溢出了?
　　找运维查了下日志
　　一切正常
　　一点风吹草动都没有
　　于是拿着代码在本地各种疯跑各种乱七八糟调试
　　基本上出现的异常都被还原了
　　但是我的代码还是没死啊...
　　心里面一万头草泥马在奔腾啊...
　　然后再去运维那要了更详细的日志
　　回过头来看测试环境的程序
　　竟然完美的还原了线上的场景
　　跟进去一看
　　所有的线程都卡在Redis的Get方法里
　　这是什么情况?!
　　确定了下Redis没有挂
　　那就只能把问题锁定在ServiceStack.Redis里咯
　　不由怀疑
　　这玩意到底支持多线程不哦...
　　然后详细看了下ServiceStack.Redis的文档
　　然后发现一个惊天的秘密:
　　这坑爹的ServiceStack.Redis不支持我们传统认为的线程安全啊
　　


　　ServiceStack.Redis对多线程采用的是连接池


　　也就是说:
　　每一个线程可以从连接池里获取一个连接供本线程使用
　　在使用完毕过后还回给连接池
　　这样来保证每一个线程使用的Redis连接都是独立的而不会互相干扰
　　这就是ServiceStack.Redis所谓的ThreadSafe Access
　　ServiceStack.Redis就是这样来保证线程安全的...


　　


　　坑爹呢这是...
　　我们传统意义的线程安全可是多个线程并发访问一个对象啊
　　而不是多个线程访问不同的对象啊...
　　都怪我学艺不精啊...
　　竟然不知道还有这种ThreadSafe Access啊...

版权声明：本文为博主原创文章，未经博主允许不得转载。