开发者学堂课程【MongoDB 快速入门：ChangeStreams 使用及原理】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/49/detail/1004
ChangeStreams 使用及原理（一）
内容介绍：
一、概述
二、功能介绍
三、使用介绍
四、原理介绍
一、概述
本节课介绍 ChangeStreams 的使用和原理。在介绍为什么要 ChangeStreams 之前,介绍一下什么是 ChangeStreams 。首先介绍一个例子，今年某一天，坐上公交车从地铁大屯路前往立水桥，然后打开地图，搜索路线，地图给了一个路径，751路公交车，地图还提供了比较好的功能，就是公交车还有几站，大概多少分钟后会到达，等一会按刷新按钮，车已经更近了，现在只有两站了，时间还够，于是打开手机玩了会游戏，玩着玩着发现还在等公交车，结果抬头一看公交车刚好错过了，很懊悔。于是打开地图看下一辆公交车还有多久，下一辆公交车还有十多分钟就到了。因为北京的公交车比较多，所以两路之间时间会比较短。假设是别的城市或者说一些比较冷门的城市，两路之间时间会比较长，就会很崩溃。如果手机提出一个推送功能，比如说还有一站的时候提醒，751路即将在一站后到达，请做好准备。那这个时候就可以放下手机去等公交车了。这里老师介绍了这个例子。由这个例子可知手机的推送功能很重要。实现这种推送模式可以有两种。第一是手机端或其他端不断请求一个数据库查询还有几站，数据库返回有五站，再次查询，还是返回五站，因为公交车的位置没有变更。这是一种反复请求应答轮询的模式。
还有一种模式是数据库主动告知公交车的位置发生变更了，主动去告知手机端，这是一种异步通知的模式。这种模式更加适应当下需求。这个就是需要介绍的 MongoDB Change Streams 的功能。这就是本节课介绍的一个大纲，主要分为四大部分。概述，功能介绍，使用介绍，原理介绍四部分。首先是概述部分，概述会介绍什么是 Change Streams，还有 Change Streams支持的场景， Change Streams 的版本，还有具体的一些场景举例。
1、什么是 Change Streams
Change Streams 的功能是什么，Change Streams 最主要的功能是基于 MongoDB oplog 实现的，oplog 就相当于 mycricle 的binlog，register 的AUF一样，都是提供一个增量数据， Change Streams就是oplog之上，包裹一层应用，对外提供一个 API 接口，实时地把数据推送出来，推送的数据有以下几种，比如 Insert 类型, Delete 类型, Update 类型， Invalidate 类型。Invalidate 类型主要是使用于用户物，比如说监控某个表，但是这个表最终被删除了，这时监控已经没有任何意义了，这时就会返回Invalidate事件。DDL事件就是数据库的一个操作语言，比如 credie base,drop date base 等等之类的。总的来说 Change Streams 的功能就是基于oplog实现，推出一个实时增量的功能。
2、Change Streams 支持的场景
Change Streams 支持的场景，首先是版本的要求 Change Streams 支持的 MongoDB 的版本包括副本集和分片集群都是支持的，只要是>=3.6版本。 Change Streams 支持的有粒度有三个维度，第一个是全部db，监控 MongoDB 下面所有的db,第二个是单个db，就是某个db下面的表，第三个是只是单个表。Change Streams对于引擎的要求是 wriedTiger 的引擎。对于readconcern的要求是<=4.0是要求的一个mojority的concern，>4.2是没有要求的。这主要是考虑到用户对于实时性的要求，可能对数据一致性的要求比较弱，所以在4.2里放开了这个要求。建议去配置一个majority的readconcern级别，当然用户自己的场景会不同，可以适当的放开一致性的要求。
3、Change Streams 发展版本的历史
接下来介绍一下关于 Change Streams 发展版本的历史，在MongoDB3.6 以前，用户想要拿到增量变更数据，用户只能是从oplog 表拉取，从 local.oplog.rs 拉取 oplog 数据，拉取完之后还需要自己设置过滤条件，比如用户想要得到 excert 和 update 的操作语句，剩下的语句都不关心，就可以过滤掉，需要自己去设置一个过滤条件，另外分片集群的处理比较复杂，比如分片集群发生了movecreact 事件，对于ddi在分辨集群上有不同的 concertion 的操作，还需要去重处理，去重的逻辑会非常的复杂，另外用户还需要自己管理一个断点续传的位点。从3.6之后，MongoDB，Change Streams 正式发布，它能够提供实时吐出增量变更信息，去方便用户的运维处理，它支持 PostImage,PostImage 就是数据发生变更，发生update操作，数据发生之前它就是一个 preImage，数据发生之后就是一个 PostImage,3.6提供了PostImage 这样的一个镜像，另外它还更好的支持断点续传。4.0和4.2Change Streams 的性能不断优化，更好的去支持了分片集群的场景。4.0.7支持PostBatchResumeToken，使得位点能够更好的推进，防止用户在发生MongoDB重启，或者是在客户端重启，导致数据位点回退，重启之后位点大批量无效的数据扫描，对于数也进行了支持，包括4.0的多文档事务，4.2的分布事务这些都进行了很好的支持。另外还支持了一个指定时间点启动/恢复的功能，用户可以指定任意时间点，然后可以在指定的时间点进行启动一个 Change Streams 流，以及恢复数据。4.4以后MongoDB 的 Change Streams 功能，持续性优化，比如即将要支持的 PreImage，在性能上也是进行了比较大的支持。总的来说，Change Streams 的版本不断进行迭代，MongoDB 的版本不断进行迭代，功能上和性能上也都做了很大的优化。
4、使用场景
Change Streams 的使用场景，举出了几个例子，首先监控场景，比如用户有一些比较敏感的表，账户的表，这个表发生变更用户希望能够及时去感知，Change Streams 就可以提供监控的功能，这个表发生变更就把变更的消息实时的推送出来。还有一个分析场景，比如用户希望基于增量去分析用户的行为，就可以基于 Change Streams ，把数据拉出来，推送到一些平台，比如像 flink、spack等等的平台之类的。此外还有数据同步的功能，比如基于 Change Streams ，用户可以搭建一个额外的 MongoDB 的集群，这个集群是从云端的 MongoDB 拉取过来的，这个集群可以做一个备份，比如云端发生挂掉或者网络不通等等之类的，被集群就可以接管过服务，另外还可以做一个冷备份，用户可以基于 Change Streams 把数据同步到文件，如果云端数据库发生不可服务，可以从文件里面恢复出完整的 MongoDB 数据库继续提供服务，数据同步不仅仅限于同一个地域，可以跨地域，比如从北京到上海，甚至是从中国到美国等等。此外还可以提供一个消息推送功能，就比如在最开头提到的对公交车的信息比较感兴趣，如果公交车的位置发生了变更，希望能够实时的把公交车变更的数据推给自己，非常便捷使用。总的来说，用户可以去 MongoDB 的 Change Streams 功能可以进行平台化构建，满足用户的各项需求，当然这里只是举几个例子，用户的需求可以使多样化，不仅局限于此。
二、功能介绍
接下来进行功能介绍，首先 Change Streams 的特性是什么，另外Change Streams 对比 oplog 拉取有什么优缺点。
1、Change Streams 的特性
归纳来说一共有五部分，首先是持久化，它是 Majority-Committed Changes,即数据能保持持久化，不会被回滚，当然用户可以自己配置，比如配置不是Majority 的话，就能保持持久性。第二个是断点续传，可以根据通过 ResumeToken 保证断点续传，另外还可以保证顺序性，副本集保证的是线性一致性，对分辨集群保证的是因果一致性，另外还有安全性，Change Streams 可以进行安全上的控制。灵活性，因为Change Streams 本身是基于 Aggregate 框架来实现的，用户还可以去添加s tage 去实现过滤、计算等需求。
2、Majority-Committed Changes
下面介绍 Majority-Committed Changes 的持久化，比如用户写请求，将请求写到了 primary 上，这时 primary 上产生 oplog,这时Change Streams 不会将 oplog 直接吐出来，还会将数据写到secondary,secondary 写成功之后才会将数据吐出来，这样防止未将 primary 写成功，primary 当机了，secondary 成为了一个新的primary，这时数据被回滚掉，所以 Change Streams 吐出的数据都是持久化成功的数据。
3、断点续传
举例，比如用户从 MongoDB 拉取实时的数据，拉取的数据是根据时间戳递增的，比如8点钟、9点钟、10点钟，突然在10点钟的时间戳以后，MongoDB 发生当机了，或者是用户本身的服务挂掉了导致连接断开，之后 MongoDB 又恢复服务，或者是 server 端恢复服务，希望继续接着10点钟进行拉取，恢复以后可以向服务端发送一条消息，说请给我从10:00以后的数据， MongoDB 收到消息以后，继续将10:00之后的数据源源不断的用过 Change Streams 推送出来，10:00之后是11:00、12:00，服务就可以进行正常的运行，这里介绍的是关于 MongoDB 的 Change Streams 断点续传的功能。
4、顺序性-满足因果一致性
在分片集聚下，是如何保证顺序性，也就是满足因果一致性。首先举例，比如用户有一个写请求 insert{_id:1,a=1},写到了shard2上，这时语句就通过 Change Streams 吐出来，后来又将 update 文档update{_id:1}=>{_id：1，a=2}将 a=1，改成了 a=2，这条操作同样是落在shade2上，这时 Change Streams 也会将第二条文档吐出来，也就是这两条文档是具有前后因果性的，不会说是 Change Streams 吐出来的文档，先是第二条文档再是第一条文档，它的顺序是严格的因果顺序。假设另一个例子insert{_id:1,a=1}，落到了shade2上，又有一条数据insert{_id:2,a=2}，它落到了shade3上，两条数据同时落在不同的 shade 上，在 Change Streams吐出的数据可能先是insert{_id:2,a=2}，再是insert{_id:1,a=1}，这两条数据在不满足因果顺序的时候，吐出的结果也是不能保证顺序性的。
5、Change Streams VSoplog 拉取
接下来进行 Change Streams VSoplog 拉取的对比，首先在对接成本上，oplog 是远远高于 Change Streams ，因为用户需要自己去监听表，需要 Change Streams 拉取，需要过滤等等一系列处理，第二个是对于副本集支持以及 DML支持，oplog 拉取和 Change Streams 都是支持的，对于 DDL支持，oplog 是全部 DDL,Change Streams 目前支持 dropCollection,dropDatabase,renameCollection。但是后续MongoDB 官方会持续去完善DDL语句，会去支持更多的 DDL语句。像 dropDatabase 等等之类的。对于集群版的支持，oplog 拉取必须关闭Balancer，否则的话拉取出来的 oplog 不能保证因果一致性，另外DDL需要去重，这些在 Change Streams 都不需要额外处理。这些成本都很低。在事务处理方面，oplog 拉取处理事务比较繁琐，比如事务里面有两条同步语句，两条同步语句断开了，进行重启事务处理会很繁琐，Change Streams 处理就很好，不需要额外的对接在普通的语句当中。断点续传，oplog 拉取是根据时间戳的，Change Streams可 以根据时间戳也可以根据 Token。实时性和吞吐性，oplog拉取是更高的，Change Streams 相对较低一点，因为 Change Streams 为了兼顾一致性，加上目前实现是在副本集在shell上通过单线程拉取，所以它性能上略低于 oplog。但是后面 MongoDB 官方会进行优化，也就是去保证 change stream 的性能去追上 oplog，缩小 gap。另外权限上控制上，oplog 拉取只能是两种权限，一种是 all or nothing。all 的意思是说全部的权限，要么能够监听所有的表，监听所有的数据，要么就是一条拿不到。change stream 的权限控制会更加的细粒化，可以根据目前账户的权限，能看到有哪些表的权限就提供那哪些表的权限。
