gydtep
发表于 2021-2-15 15:51:02
为了保证对于DRC消息顺序的接收，首先想到的是采用单机消费的方式，而单机带来的问题是数据传输效率慢。针对这个问题，涉及到并发的能力。大家可能会想到基于表级别的并发，但是如果单表数据变更大，同样有性能瓶颈。这里我们实现了主键级别的并发能力，也就是说在同一主键上，我们严格保序，不同主键之间可以并发同步，将并发能力又提高了N个数量级。
gydtep
发表于 2021-2-15 16:29:01
同时单机消费的第二个问题就是单点。所以我们要实现Failover。这里我们采用Raft协议进行多机选主以及对主的请求。当单机挂掉之后，其余的机器会自动选出新的Leader执行同步任务。
gydtep
发表于 2021-2-15 16:51:37
为了很好的支持跨单元数据同步，我们采用了MNS（阿里云消息服务），MNS本身是个分布式的组件，无法满足消息的顺序性。起初为了保证强一致性，我采用消息染色与还原的方式
gydtep
发表于 2021-2-15 18:43:30
通过实践我们发现，这种客户端排序并不可靠，我们的系统不可能无限去等待一个消息的，这里涉及到最终一致性的问题，在第3点中继续探讨。其实对于顺序消息，RocketMQ是有顺序消息的，但是RocketMQ目前还没有实现跨单元的能力，而单纯的就数据同步而言，我们只要保证最终一致性就可以了，没有必要为了保证强一致性而牺牲性能。同时MNS消息如果没有消费成功，消息是不会丢掉的，只有我们去显示的删除消息，消息才会丢，所以最终这个消息一定会到来。
gydtep
发表于 2021-2-15 19:12:57
既然MNS无法保证强顺序，而我们做的是数据同步，只要能够保证最终一致性就可以了。2012年CAP理论提出者Eric Brewer撰文回顾CAP时也提到，C和A并不是完全互斥，建议大家使用CRDT来保障一致性。CRDT(Conflict-Free Replicated Data Type)是各种基础数据结构最终一致算法的理论总结，能根据一定的规则自动合并，解决冲突，达到强最终一致的效果。通过查阅相关资料，我们了解到CRDT要求我们在数据同步的时候要满足交换律、结合律和幂等律。
gydtep
发表于 2021-2-15 19:50:05
如果操作本身满足以上三律，merge操作仅需要对update操作进行回放即可，这种形式称为op-based CRDT，如果操作本身不满足，而通过附带额外元信息能够让操作满足以上三律，这种形式称为state-based CRDT。
gydtep
发表于 2021-2-15 20:31:42
通过DRC的拆解，数据库操作有三种：insert、update、delete，这三种操作不管哪两种操作都是不能满足交换律的，会产生冲突，所以我们在并发级别（主键）加上额外信息，这里我们采用序号，也就是2中提到的染色的过程，这个过程是保留的。而主键之间是并发的，没有顺序而言。当接收消息的时候我们并不保证强顺序，采用LWW（Last Write Wins）的方式，也就是说我们执行当前的SQL而放弃前面的SQL，这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性（实例+单元+数据库+MD5(SQL)）对每个消息做幂等，保证每个SQL都不会重复执行。而对于结合律，我们需要对每个操作单独分析。
gydtep
发表于 2021-2-17 13:45:21
在 1988 年，当时施乐 PARC 的首席科学家 Mark Weiser 提出了“Ubiquitous Computing”的概念，“在未来，计算将无处不在”。随着互联网的发展和进化，5G、AIoT 等新技术的涌现，随处可见的计算需求已经成为现实，无处不在的计算正在改变我们的世界。
gydtep
发表于 2021-2-17 14:12:14
基于 MicroVM 的安全容器的占比将逐渐增加，可以提供更高的安全隔离能力。虚拟化和容器技术的融合，已经成为了一个重要趋势。在公共云上，比如 AWS 的 Firecracker 已经成为 Lambda/Fargate 等 Serverless 云服务的基础设施；阿里云的袋鼠容器引擎，已经成为 ECI/ASK 的基础。
gydtep
发表于 2021-2-18 08:25:28
除了 FaaS 的快速发展，Serverless 和容器技术也开始融合，尤其是得到了云厂商的高度关注。通过 Serverless 容器，一方面可以根本性解决 K8s 自身的复杂性，让用户无需受困于 K8s 集群容量规划、安全维护、故障诊断等运维工作；另一方面进一步释放了云计算的能力，将安全、可用性、可伸缩性等需求下沉到基础设施实现，可以帮助云厂商形成差异化竞争力。
