1.9_深入场景
本章节对Datalink可以支持的【架构模式】做一下介绍，将列举一些典型架构场景（但datalink能支持的并不仅限于这些场景）
使用了【分库分表】技术后，数据的多维度查询是一个常见的棘手问题（如：打车场景下，订单以member_id做sharding后，需要解决以driver_id进行查询的需求；电商场景下，以买家ID做sharding后，需要解决以卖家ID进行查询的需求），借助Datalink我们可以将member维度的数据实时同步到driver维度，并在同步过程中进行ReSharding操作，这样，当通过driver_id进行查询时去对应维度的数据库进行查询即可。在我们的场景中，ReSharding是通过MysqlTaskReader+SddlTaskWriter实现的。
搭建大数据平台，第一步需要解决的就是数据来源的问题，目前借助Datalink提供的MysqlTaskReader、HbaseTaskReader和HdfsTaskWriter，我们可以将Mysql和HBase的数据实时同步到Hadoop中，然后在Spark中通过ETL任务对数据进行清洗和整合。当引入其它类型DB时，开发对应的TaskReader即可，有些DB做增量Reader插件难度可能会比较大，此时可以考虑使用DataX，做定时增量或定时全量，当然，还是优先使用实时增量最好，一是部署运维方便，二是实时性更高一些。超出Datlink的范畴，谈一下Datax，从大数据平台向外同步数据，我们基本上都是基于Datax来实现的，Sqlserver数据同步到大数据平台，也是使用的DataX，但目前正在考虑写一个增量版的SqlServerReader插件用来替换Datax-Job定时方案。
这里套用一下CQRS这个名词，C代表【领域模型】，Q代表【查询模型】，【领域模型】强调的是规范化，以保证系统的高可扩展性，【查询模型】强调的是快速响应，以保证查询的高效性。系统越复杂，【领域模型】和【查询模型】能一起复用的概率就越低，所以现在很多的互联网应用都采用了CQRS架构，一级系统（即C端系统）基于领域模型执行交易，二级系统（即Q端系统）构建查询模型支撑查询，构建这样一个架构的核心关键就是数据同步，并且我们可以在数据同步的过程中进行模型转化，如过滤掉查询不用的数据、将多条数据合并成一条数据、将多个字段合并成一个字段等等，二级系统中还会针对查询场景做单独的索引优化等。
同样套用一下EDA这个名词，系统间交互，除了RPC之外用的最多的便是消息了，一条条的消息就是一个个的事件，通过事件的传播和消费，不断驱动业务流程的演进，这是EDA的基本架构思想，目前大部分公司也都在使用这种架构模式。在EDA架构中，核心基础设施是MQ，核心设计工作是定义事件，在一些复杂场景必须去精心定义【领域事件】，但在很多简单场景下直接复用DB的事件模型即可（如：Mysql-Binlog的增、删、改Event），在Datalink中通过组合使用MysqlTaskReader + MQTaskWriter，实现把Mysql的【增删改Event】不断发送到Mq，就可以提供一套通用的EDA解决方案，来满足大部分场景的使用需求，并且数据一致性还可以轻松得到充分保证（自行设计的话很多团队应该都是显示调用API发送事件，这种方式不仅增加开发工作量，极端场景还存在事件漏发的情况）。基于DB的Log-Event-EDA，下面举几个例子：
- 获取到订单表插入事件时，触发短信通知，通知用户下单成功
- 获取到用户表修改或删除事件时，清空缓存服务器中该条数据对应的信息
- 当Datalink提供的通用功能无法满足使用需求时，业务应用也可以自己消费binlog实现自己的定制化需求
上面列举了Datalink可以支持的几个【架构模式】，其它的一些具体场景还有
- 基础参数共享
- 实时归档（只需在源端删数据即可，往归档库同步过程中将Delete-Event过滤掉）
- 数据镜像
- 支持迁库、拆库、合库
- 灾备
- 构建二级索引
- SearchBuild
- 等
场景是千变万化的，希望使用该产品的朋友可以发掘更多的架构模式和使用场景