Akka管理百万级设备Actor时查询全量设备的实现模式咨询

你遇到的是事件溯源+Actor模型架构下的典型读侧查询痛点，行业通用解法是CQRS（命令查询职责分离）读写分离架构，你当前的预设方案已经非常贴合主流实践，下面给你几个适配Akka生态的优化方案和落地建议：

不用自己手写Kafka消费逻辑，Akka官方已经提供了专门用来生成读侧视图的组件Akka Projection，优势非常明显：

• 内置精确一次消费语义、偏移量持久化、失败自动重试机制，不需要自己处理消费位点丢失、重复消费、异常重试等问题，稳定性比自行实现高很多
• 可以直接对接Akka Persistence的Cassandra Journal消费事件，不需要额外把事件先转发到Kafka，减少链路复杂度；如果你的业务本来就已经把所有事件写入Kafka，也可以直接对接Kafka作为数据源
• 支持直接批量写入Elasticsearch、Cassandra、JDBC等存储，完全匹配你的需求

你的预设方案选Elasticsearch是非常合理的：

• 100万台设备的元数据量对ES来说压力极小，还能灵活支持多维度筛选、模糊搜索、分页查询等业务查询需求，远优于你考虑的Cassandra额外Keyspace方案（Cassandra对非主键查询的支持非常差，很难满足列表筛选的需求）
• 如果你的查询需求非常固定，只有简单的列表分页和persistenceId精确查询，也可以选择Redis Cluster存储全量设备元数据，查询延迟会更低，但是多维度筛选的灵活性不如ES，可以根据你的实际业务需求选择

如果你的业务对读侧数据和Actor实时状态的一致性要求很高，不能接受秒级的同步延迟，可以加两个优化点：

• 设备状态修改命令执行成功后，主动异步触发对应设备元数据的索引更新，优先保证用户刚修改的设备可以立刻查到最新状态
• 用户点击单个设备查看详情时，直接请求对应Akka Actor查询最新状态，不要直接返回ES的缓存数据，同时可以异步刷新ES中该设备的元数据

• 读侧索引只需要存业务展示需要的字段即可，不要存全量事件数据，减小索引体积，提升查询效率
• 可以配置Akka Projection的批量写入参数，比如每100条事件或者每1秒批量写入一次ES，降低ES的写入压力，就算是全量重放100万设备的历史事件也能快速完成索引构建
• 如果后续需要调整读侧索引结构，只需要重放Akka Persistence的全量历史事件就能重新生成完整的索引，不需要做复杂的数据迁移

内容的提问来源于stack exchange，提问作者posthumecaver