然后进行匹配查找再精准推送。事件广播机制看起来有扩展性问题，但是其实性能并不差，因为我们推送的数据很小就是 Topic 名称，而且相同 Topic 的消息事件可以合并成一个事件，我们线上就是默认采用的这个方式。
读放大：即消息按 Topic 进行存储，接受者根据订阅的 Topic 列表去相应的 Topic 队列读取消息。
写放大：即消息分别写到所有订阅的接受者队列中，每个接受者读取自己的客户端队列。
我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题；同理，我们只要保证代码实现是严格按照领域模型的意图来落地的
梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景；
梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等；
DDD切入点3 - 领域模型设计
这部分内容，我想学习DDD的人都很熟悉了。DDD原著中提出了很多实用的建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。
借助于PolarDB一写多读的架构，用户可以增加只读的RO节点以运行复杂只读查询，从而避免分析型查询对TP负载的干扰。
用户可以使用PolarDB集群中的一个RO节点作为分析型节点，在该RO节点上配置生成列存索引，复杂查询运行在列存索引上并使用所有可用CPU的计算能力，
因此设计一个一体化的存储引擎能同时服务OLTP型和OLAP型负载非常具有挑战性。目前市场上HTAP存储引擎做的比较好的只有几家有几十年研发积累的大厂
例如用户可以将需要分析的int/float/Double列加入列索引，而对于一般只需要点查但是又占用大量空间的text/blob字段，则可以保留在行存中。
最近分析型数据库在资本市场和技术社区都非常的火热，各种创业公司的创新型产品如雨后春笋般出现。这一方面是因为当前阶段企业日益依赖从数据中寻找增长潜力带来需求的增长，
