EventStore

旅程8：后记:经验教训 我们的地图有多好?我们走了多远?我们学到了什么?我们迷路了吗? “这片土地可能对那些愿意冒险的人有益。”亨利.哈德逊 这一章总结了我们旅程中的发现。它强调了我们在这个过程中所学到的最重要的经验教训，提出了如果我们用新知识开始这段旅程，我们将以不同的方式做的一些事情，并指出了Contoso会议管理系统的一些未来道路。 你应该记住，这个总结反映的是我们的具体旅程，并非所有这些发现都适用于你自己的CQRS旅行。例如，我们的目标之一是探索如何在部署到Microsoft Azure并在利用云的可伸缩性和可靠性的应用程序中实现CQRS模式。对于我们的项目，这意味着使用消息传递来支持多个角色类型和实例之间的通信。您的项目可能不需要多个角色实例，或者没有部署到云中，因此可能不需要如此广泛地(或者根本不需要)使用消息传递。 我们希望这些发现能够被证明是有用的，特别是当您刚刚开始使用CQRS和事件源时。 我们学到了什么 本节描述了我们学到的主要经验教训。它们没有以任何特定的顺序呈现。 性能问题 在我们的旅程开始时，我们对CQRS模式的一个概念是，通过分离应用程序的读和写方面，我们可以优化每个方面的性能。CQRS社区的许多人都认同这一观点，例如: “CQRS告诉我，我可以分别优化读和写，而且我不必总是手动的反规范化到平面表中。” Kelly Sommers - CQRS顾问

本文详解canal的整体架构。 一、整体架构 说明： server代表一个canal运行实例，对应于一个jvm instance对应于一个数据队列 （1个server对应1..n个instance) instance模块： eventParser (数据源接入，模拟slave协议和master进行交互，协议解析) eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作) eventStore (数据存储) metaManager (增量订阅&消费信息管理器) 二、各模块架构 2.1 Parser 整个parser过程大致可分为几步： Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点） Connection建立连接，发生BINLOG_DUMP命令 Mysql开始推送Binary Log 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功 存储成功后，定时记录Binary Log位置 2.2 Sink 说明： 数据过滤：支持通配符的过滤模式，表名，字段内容等 数据路由/分发：解决1:n (1个parser对应多个store的模式) 数据归并：解决n:1

昨日浏览公众文章时，偶尔发现阿里开源的这款软件，初步了解，是基于mysql binarylog的增量发布订阅服务。网上也有客户端针对.net平台的支持。 下面关于canal的介绍，搜集了网上的一些资料，可供大家参考学习之用。 canal的介绍 canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL（也支持mariaDB）。 起源：早期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于trigger的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。 基于日志增量订阅&消费支持的业务： 数据库镜像 数据库实时备份 多级索引 (卖家和买家各自分库索引) search build 业务cache刷新 价格变化等重要业务消息 工作原理 mysql主备复制实现： 从上层来看，复制分成三步： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）； slave将master的binary log