你好，我是陈浩网名作者的house.在弹力设计篇呢，我们讲过异步通讯的设计模式，有助于提高系统的稳定性和容错能力。
那其实呢异步通讯在分布式系统中啊，还可以增加整个系统的吞吐量，从而呢可以面对更高的并发，并且呢还可以从容的利用好现有的系统资源。
那为什么这么说呢？我们来试想一下，在你的工作中有很多人呢会来找你，让你帮着做事儿。
那如果你是这种请求响应式的工作方式呢，那么本质上来说呢，你是在被动工作，也就是被别人驱动的工作方式。
那当你在做一件事儿的时候，如果有别人来找你做其他事儿，那你呢就会被打断，而要去干别的事儿。
如果你可以统筹安排这些事情呢，也许五件事啊可能只需要两个小时。
。那如果不能呢或者老被别人打断思路，那你可能就要画上五个小时。
义务处理任务呢可以让你更好的利用时间和资源利用，好的时间和资源呢性能啊自然就会提升上来。
那这就好像邮递业务一样。
你寄东西的时候呢，邮递公司会把大量的去往同一方向的订单合并处理，并统一的调配物流交通工具，从而在整体上更为节省资源和时间。
那在分布式架构中呢，我们的系统啊被拆成了很多的子系统。
那如果想把这堆系统合理的用好，并更快的处理大量的任务，我们呢就需要统一的规划和统筹整体。
那这样呢就可以达到整体的最优。
那在本质上呢，这个和邮递公司处理邮件一样啊，是相同的道理。
在计算机的世界里呢，到处都是异务处理。
比如说当程序读写文件的时候，我们的操作系统啊并不会真正同步的去操作硬盘。
而是把硬盘读写的请求呢先在内存中后一小会儿，然后再对这些读写请求啊做merge和salght.也就是说呢，merge是把相同的操作合并，相同的读操作呢只读一次。
相同的写操作呢只写最后一次，而sort呢是把不同的操作排个序。
那这样呢可以让硬盘向一个方向转一次啊，就可以把所有的数据都读出来，而不是来来回回的转。
那这样呢可以极大的提高硬盘的吞吐率。
那再比如我们的TCP协议向网络发包的时候，会把我们要发的数据呢先在缓冲区中进行囤积。
当囤积到一定尺寸的时候呢，才向网络发送。
那这样呢就可以最大化利用我们的网络带宽，而传输速度和性能呢也会变得很快。
那这个呢就是异步系统所带来的好处啊，让我们的系统呢可以统一调度。
那另外呢我举前面这两个例子啊，是想告诉你，我们可能会觉得异步通讯会比较慢。
那其实呢并不是这样，我们同样也可以把异步做的比较实时。
那多说一句，就算是有延时异不处理，在用户体验上也可以给用户带来一个不错的用户体验。
那就是用户呢可以有机会反悔之前的操作。
那之前呢我们在弹力设计中讲的是异步通讯，那这里呢我想讲的是异步任务处理。
那当然呢这里面是没有什么冲突的，只不过呢异步通讯讲的是怎么把系统连接起来。
而我们在这里想讲的是怎么处理任务。
那首先呢我们需要一个前台系统，把用户发来的请求啊一一记录下来，有点像请求日志。
那这样呢我们的操作在数据库或者存储上只会有追加的操作啊，性能就会很高。
我们收到请求之后呢，给客户端返回，收到请求正在处理中。
然后呢，我们有一个任务处理系统，来真正的处理收到的这些请求。
那为了解耦呢，我们需要一个任务派发器，那这里呢就会出现两个事儿，一个是推模型push,一个是拉模型。
那所谓铺是推模型呢，就是把任务派发给相应的人去处理啊，有点像一个工头的调度者的角色。
而铺拉模型呢则是由处理的人来拉取任务处理。
那这两种模型啊各有各的好坏。
一般来说呢复试模型可以做调度，但是他需要知道下游工作节点的情况。
那除了要知道哪些是活着的，还要知道他们的忙闲程度。
那这样一来呢，当下游的工作节点扩容缩容啊，或者有故障需要维护等一些情况发生的时候呢，试节点都需要知道，那这个呢就会增加一定的系统复杂度。
而铺的好处呢则是可以让上游节点不用关心下游节点的状态啊，只要自己忙得过来，就会来拿任务处理。
那这样呢可以减少一定的复杂度，但是呢少了整体的任务调度。
那一般来说呢我们构建的都是推拉结合的系统，复士端会做一定的任务调度。
比如说他可以像物流那样，把相同商品的订单啊都合并起来，打成一个包，交给下游系统，让他一次处理掉。
也可以把同一个用户订单中的不同商品啊，给拆成多个订单，然后铺端呢来订阅这个push端发出来的义务消息处理相应的任务。
那在这里呢我们需要提一下event sourcing这个设计模式啊，也叫做事件溯源。
所谓一般sourcing呢，它主要想解决的问题啊，就是我们可以看到数据库中的一个数据的值。
但是呢我们完全不知道这个值是怎么得出来的。
就像银行的存折一样，我们可以在银行的存折中呢看到我们收支的所有记录，也能看得到每一笔记录之后的余额。
那当然呢如果我们有了所有的收支流水账的记录呢，我们就完全不需要保存余额了。
因为我们呢只需要回放一下所有的收支事件啊，就可以得到最终的数据状态。
那这样一来呢，我们的系统啊就会变得非常简单，只需要追加不可修改的数据操作时间，而不是保存最终的状态。
那除了可以提高性能和响应时间之外呢，还可以提供事物数据一致性，并保留了可以启用补偿操作的完整记录和历史记录。
那还有一个好处呢，就是我们的代码里如果有了bug,在进录状态的系统里呢，我们修改了bug之后啊，还需要做数据修整。
然而呢在一般的sourcing的系统里面啊，我们只需要把所有的事件重新播放一遍就好了。
因为整个系统呢就没有状态了，事件不可变，并且呢还可以使用指挥加操作，进行存储、用户界面、工作流或者启动事件的进程啊，可以继续。
而处理事件的任务呢可以在后台义务的运行。
此外呢处理事务期啊不存在征用。
那这两点呢可以极大的提高应用程序的性能和可伸缩性。
那这里的事件呢是描述已经发生操作的简单对象和描述事件代表的操作所需的相关数据。
那事件呢不会直接更新数据存储，只会对事件进行记录，以便在合适的时间啊进行处理。
那这样呢可以简化实施和管理事件，溯源呢不需要直接更新数据存储中的对象，因此呢有助于防止并发更新造成冲突。
最重要的一点啊就是异步处理，加上事件溯源的方式，可以很好的让我们整个系统进行任务的统筹安排批量处理，可以让整体的处理过程呢达到性能和资源的最大化利用。
那关于般eent sourcing呢，一般啊都会和CQIS一起提。
另外呢你可以通过文中这个链接啊，去get hub上面啊，看一看项目的势例啊，来得到更多的信息。
那接着呢我们来说异务处理的分布式事务在前面的分布式系统的本质一本中呢，我们说过，对于分布式事务在强硬执行下，在业务层上呢只能做两阶段提交。
而在数据层面上呢，需要使用raft或者penanels的算法。
但是我想说啊，在现实生活中呢，需要用到强意志性的场景实在不多，不是所有的场景都必须要强意志性的事物的。
我们仔细想一想，现实生活当中的很多例子，比如说我们去餐馆吃饭，就要先付钱，然后拿一小票啊去领餐。
那这种情况下，交钱和取货这两个动作分开，可以让我们的餐馆有更高的并发和接客能力。
那如果要做成两阶段提交呢，顾客先锁定好钱，餐馆呢锁定好食材，最后一手交钱一手交餐啊，那么这是一件非常恐怖的事情。
是的，你可以看到我们的现实世界中呢有很多这样先付钱拿小票去领货的场景，也有先消费啊，然后拿一个账单去付钱的场景。
总之呢完全不需要两阶段去交这种方式，我们完全可以使用异步的方式来达到一致性。
当然呢是最终的一致性，要达到最终的一致性能，我们需要有一个交易凭证。
也就是说呢，如果一个事物需要做a和b两件事儿，比如说把我的钱转移给我的朋友。
首先呢就要先做扣钱交易，然后呢记录一下扣钱的凭证，再拿这个凭证啊，去给我朋友的账号上加钱。
那在达成这个事物的过程中呢，有几点需要注意。
那第一点呢就是凭证需要非常好的保存起来，不然呢会导致事务做不下去。
那第二点呢，就是凭证处理的密能性问题。
不然在从事的时候呢，就会出现多次交易的情况。
那第三点呢，就是如果事务完成不了，就需要做补偿事务处理。
最后呢我们来谈一谈异步处理的设计要点。
异步处理中的事件驱动和事件溯源是两个比较关键的技术。
异步处理呢可能会因为一些故障，导致我们的一些任务呢没有被处理。
比如说消息丢失没有通知到，或者说通知到了没有处理这一系列的问题。
那异步通知的方式呢，需要任务方处理完成之后，给任务发起方回传状态，那这样来确保不会有漏掉的。
另外呢发起方也需要有一个定时任务，把一些超时没有回传状态的任务啊再重新做一遍。
你可以认为啊这是异步系统中的对账功能。
那当然了，如果要重做就需要处理法，这是密等性处理。
另外呢就是义务处理了整体业务事务问题。
也就是说呢，义务处理在处理任务的时候呢，并不知道能否处理成功，于是呢就会一步一步的处理。
呃，如果到最后一步不能成功呢，那么你就需要回滚。
那这个时候呢就需要走我们在弹力设计中所说的补偿事务的流程。
那当然啊并不是所有的业务都可以使用义务的方式。
比如说一些需要强意志性的业务啊，使用异步的方式啊可能就不适合了。
那这里呢就需要我们小心的分析业务。
我相信呢绝大多数的业务场景啊都用不到强抑志性啊，包括银行的业务。
另外呢在需要性能的时候呢，我们也需要牺牲掉强抑制性啊，变成最终抑制性。
在运维的时候呢，我们要监控任务队列里的任务积压情况。
呃，如果有任务积压了啊，要能做到快速的扩容。
如果不能扩容，而且任务积压太多呢，就可能导致整个系统挂掉，那么就要开始对前端流量进行限流。
那在最后呢，我还想强调一下，异步处理系统的本质呢就是把被动的任务处理变成主动的任务处理。
那他的本质呢就是在对任务进行调度和统筹管理。
好了，我们来总结一下今天分享的主要内容。
首先呢我介绍了一部通讯，它在弹力设计中的作用呢是提高系统的稳定性和容错能力。
那其实呢我们还可以在异步通讯的基础上统筹任务来提高系统的吞吐量。
那接着呢我又讲了异步通讯的设计啊，包括推拉结合的模型，异步处理配合事件溯源一起使用呢会大大简化bug,修复后的数据恢复，也能用于实践存储的事务一致性。
我用餐馆吃饭作为比喻，介绍了异部处理的事物一致性啊，一般不是强一致性，而是最终的一致性。
那这样呢才能取得高的吞吐量。
最后呢我指出了异步处理的设计要点。
在下节课呢我们会讲述数据库扩展，希望能对你有帮助。
也欢迎你来分享一下你的义务处理过程是怎样统筹安排来提高执行效率的呢？异务事务又是怎样实现的呢？我在文末呢给出了分布式系统设计模式系列文章的目录啊，希望你能在这个列表里呢找到自己感兴趣的内容。
扫一扫
427
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
