同时也对性能和数据准确一致性提出了挑战。但是有一个地方我们使用了写放大模式，就是通配符匹配，因为接受者订阅的是通配符和消息的 Topic 不是一样的内容，
既然每个请求都去读取相同的 Topic 队列，则可以复用本地队列 cache。
lookup组件
上面的推拉模型通过新消息事件通知机制来解决实时触达问题，
基于前面的理论和模型分析介绍，我们在考虑用什么架构形态来支持一体化的目标，我们从分层、扩展、交付等方面进行一下描述。
这个就和我们传统的数据库驱动开发的思路形成对比了。DDD中，我们总是以领域为边界，分析领域中的核心问题（核心关注点）
所以，就导致我们最后天天加班。
虽然，我们都知道这个道理，但是我也明白，人的习惯很难改变的，
一个大的目标。比如他只知道要做一个股票交易系统，一个灰度发布系统，一个电商平台，一个开发工具，等。但是他不清楚这些系统应该具体做成什么样子
我们还必须再进一步细化每个子域，进一步明确每个子域的核心关注点，即需求细化。我觉得我们需要细化的方面有以下几点：
发布了Database In-Memory套件，其最核心的功能即为In-Memory Column Store，通过提供行列混合存储/高级查询优化(物化表达式，JoinGroup)等技术提升OLAP性能。
其次行式存储格式在处理大量数据时大量拷贝不必要的列数据，对内存读写效率也存在冲击。
2 PolarDB 并行查询突破CPU瓶颈
优化器会同时对行存执行计划和列存执行计划做代价估算，并选中代价交代的执行计划。
