admin管理员组文章数量:1635850
spring也不是万能的
spring实现了STOMP协议,在用simpbroker时,当在线或者说订阅数非常大的时候,DestinationCache getSubscriptions非常慢,几乎所有线程都卡在那了,看了一会源码...发现这个设计真是烂
里面有两个cache,accessCache、updateCache:Map from destination -> <sessionId, subscriptionId>,因为要保证线程安全,所以第二个cache完全是用来加锁同步的,因为不想读取的时候加锁,所以释放第一个cache,只在写入的时候锁第二个cache,可以说是一种用空间换时间的方法。但是...当并发量很大的时候,第一次读取,注意是第一次读取,有这样一段代码:
for (SessionSubscriptionInfo info : subscriptionRegistry.getAllSubscriptions())
居然for循环便利所有在线session,然后找出符合destination条件的session,加入cache,所以你可以想了,当在线session非常多,这时候有一个人上线了,开始聊天,产生查询,缓存中没有,然后就开始便利所有session.......
而且这段代码是在updateCache对象锁中的,你可以想象新上线的用户用起来会多慢!
应该把所有 destination -> <sessionId, subscriptionId>在上线订阅的时候就存储在cache里,不要在读取的时候才放进去,session下线全部清除,这样既简单又高效!
本文标签: SpringDefaultSubscriptionRegistryDestinationCache
版权声明:本文标题:spring烂设计之DefaultSubscriptionRegistry DestinationCache 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/xitong/1729216109a1190451.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论