Ube*_*rto 7 java concurrency disruptor-pattern
出于性能原因,我们的系统具有完全保留在内存中的结构化模型(大约30个具有多种关系的不同实体)(大约10 Gb).在这个模型上我们必须做3种操作:
目前,该体系结构是一个相当标准的体系结构,具有使用共享模型的servlet的线程池.在模型内部有很多并发集合,但仍然有很多等待,因为一些实体"更热",并且大多数线程想要读/写它们.另请注意,通常查询比写入更耗费cpu和时间.
我正在研究切换到Disruptor架构的可能性,将模型保持在一个线程中,在一个单独的消费者中将所有可能的(有效性检查,审计等)移出模型.
第一个问题当然是:它有意义吗？
第二个问题是:理想情况下,写入请求应优先于读取请求.在disruptor中优先考虑哪种方式？我正在考虑2个环形缓冲区,然后尝试从高优先级读取,而不是从低优先级读取.
澄清这个问题比LMAX Disruptor的实际代码更具架构性.
更新更多细节
数据是一个复杂的域,许多不同类型(~20)的许多实体(> 100k)在具有许多不同集合的树结构中链接在它们之间.
查询通常涉及遍历数千个实体以查找正确的数据.更新频繁但非常有限,就像10个实体一样,所以在整个数据中并没有太大变化(如小时为20%).
我做了一些初步测试,看起来并行查询模型的速度优势超过了偶尔的写锁定延迟.
“理想情况下，写入请求应优先于读取请求。”
为什么 ？大多数快速锁（例如 C# ReaderWriterLockSlim）会执行相反的操作。写入需要阻止所有读取以避免部分读取。因此，这样的锁允许许多并发读取，希望事情变得“相当”，然后进行写入..（写入确实按队列中的编号运行，但很可能在锁定之前处理它之后发生许多读取）。
优先写入是消除并发的好方法..
最终并发/CQRS 是一种选择吗？