当接收消息的时候我们并不保证强顺序，采用LWW（Last Write Wins）的方式，也就是说我们执行当前的SQL而放弃前面的SQL，这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性（实例+单元+数据库+MD5(SQL)）对每个消息做幂等，保证每个SQL都不会重复执行。而对于结合律，我们需要对每个操作单独分析。
update操作天然满足结合律。但是这里又要考虑一种特殊情况，那就是执行结果为0。这说明此语句之前一定存在一个insert语句，但这个语句我们还没有收到。这时我们需要利用这条语句中的数据将update语句转成insert再重新执行一次。
创新的应用开发、交付方式：基于自动化、可观测、可管理的软件交付流程，加速创新效率的同时保障系统稳定性。
接下来将以系列文章的形式，和大家分享阿里云容器服务团队在云原生计算领域的探索和思考。本文主要聚焦在云原生基础设施。
在技术上，容器技术彻底解耦了应用和运行时环境，可以帮助应用更加快速平滑地迁云；容器轻量化、自包含的特性极大简化了应用弹性，释放云的核心价值。此外，容器技术的标准化促进生态的分工和协同。基于 Kubernetes，社区开始构建上层的业务抽象。
针对这些挑战，华为推出了 Volcano 项目，提供了一个针对数据计算类任务的独立调度器。阿里云在和 K8s 上游社区共同合作，在 Scheduler V2 framework 上，通过扩展机制增强 K8s 调度器的规模、效率和能力，具备更好的兼容性，可以更好地支撑多种工作负载的统一调度。
此外，托管服务网格 ASM 提供统一的服务治理能力，结合阿里云云企业网 CEN、智能接入网关 SAG 提供的多地域、混合云网络能力，可以实现服务就近访问，故障转移，灰度发布等功能。
免运维、极致弹性、极致成本
托管服务器资源，不需要用户自己运维服务器，同时也相应地具备极致弹性和极致成本的能力。
SAE 这样一款以 K8s 为底座、具备 Serverless 的特点、以 aPaaS 为形态的产品，完全符合云原生的特点。在技术层面，底层使用容器、K8s，集成了微服务，包括各种 DevOps 工具。在架构层面，因为底层依赖于这些技术，所以可以非常方便地让用户遵照云原生架构的原则，去设计出自己的应用实践，最终让客户的应用可以最大化地享受到云原生的红利，实现应用的轻量、敏捷以及高度自动化，极大地降低迈入云原生时代的门槛。
云原生时代带来的最大变化在于基础设施和业务逻辑的真正解耦。此前，中间件逻辑存在于应用程序的进程中，而现在压测、限流等都可以在Sidecar中实现，从而解耦了基础设施和业务逻辑。然而，这种解耦是不断进行着的，即使在未来也很难做到业务完全不需要关注基础设施。比如，业务流量应该多大，DB节点应该设置多少个，业务流量和DB的设计是否符合要求。比如，同步的关键业务对应的流量链路和异步化任务可能运行在同一个节点中，那么如何实现二者流量隔离就是一个难题。再比如，如何结合基础设施和业务要求进行部署，保证内存和CPU合理分配。在基础设施对这些内容无感知的前提下，如何自动化地进行混布和限流。从应用研发的视角来看，此前需要写很多代码来实现业务逻辑和基础设施交互；而现在相应的代码量会减少很多。
