An Ontroduction to Chana
- 3. 问题域 Domain 到计算机模型 ● 理想 - 正确的逻辑会带来简洁的实现（bug free） ○ 每种/个实体 <--> 内存中一个数据实例 ○ 实例接受消息（事件/命令）并改变自身状态（Status）甚 至行为模式（Behavior） ○ 将自身状态的变化历史以时间序列记录下来 ● 过去 - EJB etc ● 现在 - Actor Model ○ Actor 满足理想的想像 ○ 大量 Actor 可以异步并行行事 ○ 一个实时、不会被 blocked 的响应式系统
- 4. 限制及对策 ● 内存 - 分布式、分片 ● 处理能力 - 分布式、并行 会遇到分布式、并行所有的问题
- 5. 架构的演变 ● 数据在硬盘（数据库），业务应用直接读写数据 库 - 瓶颈 ● 数据在缓存服务器（redis 等），业务应用将数 据从缓存取出拼成内存中的业务对象实例，同 步调用，用后销毁或放自己的缓存池 ● 业务对象实例一直在内存（或者，虚拟形式-在 硬盘上但即调即起，随时经重演恢复） ○ snapshot + event sourcing ○ 异步 + 分布 + 并行
- 6. Chana - 每个业务实例都具备利用多核 的主动能力 ● 单个实例（Actor）- 串行处理，无并发冲突 ○ 接受消息 ○ 改变状态 ○ 发送消息 ● 大量实例（Actors）- 异步并行，Blocked 粒度最 小 ● 天生的分布式、并发能力 ○ 水平扩展 ○ 动态扩容 ○ HA
- 8. 数据的几种存在形式 ● 消息 （Event Stream） ○ 驱动状态的变化 ● 状态（Status Snapshot） ○ 业务对象的此刻快照，通常直接用于业务逻辑 ○ 压缩成时间序列，记录历史 ● 时间序列（Time Series） ○ 可供分析和长久保存的对于对象的信息 ○ 时间戳隐含了不同对象之间因果关系的线索 ○ 体现了对象的行为模式 ○ 不同时间尺度的时间序列展现不同的细节
- 9. Chana 三定理 ● 定理一 ○ 大部分查询都是或将是相对固定的业务需求，也即，一 个查询 pattern 是会被反复使用的 ● 定理二 ○ 当我们试图得到系统的状态而又不阻塞系统时，得不 到完全准确的状态 ● 定理三 ○ 对于一个给定的查询，冷数据只需调取一次
- 10. 你不能 block 交易所 ● 你看到的是交易所发出的带时间戳的 snapshot ● 你不能在开始交易时 block 整个交易所 ● 事务只会在最核心的成交撮合处（最小粒度）。 只需要 Block 这个微小粒度 界定事务的边界（到最小），就可以与不确定的世 界实时交易
- 11. 实时计算三要素 ● 在内存 ● 分布式并行 ● 增量计算
- 12. JPQL on Chana 对 Chana 集群中管理的实体做实时的全 局查询、聚合 SELECT a.registerTime, a.lastChargeRecord.time FROM Account as a WHERE a.registerTime >= 5 ORDER BY a.registerTime
- 13. JPQL on Chana 设计思路 ● 给系统注入一个查询 ● 首先会对全部数据包括冷热数据查一 个起始结果集 A，这个集合常驻系统 ● 实体实例（actor）在数据变更时根据查 询语句主动将自己当前的结果 push 到结果集 ● 从此以后的结果集就一直是实时的 ● 而冷数据如果不被激活因而不再变 化，就不需要再查了
- 14. JPQL 的实现 ● 解析 JPQL 语法 -> JPQL 语法树 AST ○ PEGs - Parsing Expression Grammars ● 每个实体实例做 Mapper 计算 ○ 是否满足 Where ○ 满足则 push 一个最小集的数据投影到 Reducer ○ 数据投影表达为化简的 avro 结构，最紧凑的序列化 ● Reducer 对 push 来的投影： ○ 计算 groupby 子句并分组 ○ 计算 Aggregate 函数 ○ 收集 Select 项 ○ 计算 Having 子句 ○ Orderby ● Reducer 始终实时保持最新的 JPQL 结果集
- 15. Chana 可能的应用模式 1. 设计业务的数据结构 schema 2. 将 schema 发布到 chana 3. 导入会引起 数据/状态 发生变化的消息流（事 件、命令、日志等） 4. 编写 JPQL 获得各种实时结果