求救,分布式事务怎么处理

求救,分布式事务怎么处理,第1张

1性能和时延问题在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小。服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗:1)客户端需要对消息进行序列化,主要占用CPU计算资源。2)序列化时需要创建二进制数组,耗费JVM堆内存或者堆外内存。3)客户端需要将序列化之后的二进制数组发送给服务端,占用网络带宽资源。4)服务端读取到码流之后,需要将请求数据报反序列化成请求对象,占用CPU计算资源。5)服务端通过反射的方式调用服务提供者实现类,反射本身对性能影响就比较大。6)服务端将响应结果序列化,占用CPU计算资源。7)服务端将应答码流发送给客户端,占用网络带宽资源。8)客户端读取应答码流,反序列化成响应消息,占用CPU资源。通过分析我们发现,一个简单的本地方法调用,切换成远程服务调用之后,额外增加了很多处理流程,不仅占用大量的系统资源,同时增加了时延。一些复杂的应用会拆分成多个服务,形成服务调用链,如果服务化框架的性能比较差、服务调用时延也比较大,业务服务化之后的性能和时延将无法满足业务的性能需求。11 RPC框架高性能设计影响RPC框架性能的主要因素有三个。1)I/O调度模型:同步阻塞I/O(BIO)还是非阻塞I/O(NIO)。2)序列化框架的选择:文本协议、二进制协议或压缩二进制协议。3)线程调度模型:串行调度还是并行调度,锁竞争还是无锁化算法。1I/O调度模型在I/O编程过程中,当需要同时处理多个客户端接入请求时,可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上,从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比,I/O多路复用的最大优势是系统开销小,系统不需要创建新的额外进程或者线程,也不需要维护这些进程和线程的运行,降低了系统的维护工作量,节省了系统资源。JDK15_update10版本使用epoll替代了传统的select/poll,极大地提升了NIO通信的性能,它的工作原理如图1-1所示。图1-1 非阻塞I/O工作原理Netty是一个开源的高性能NIO通信框架:它的I/O线程NioEventLoop由于聚合了多路复用器Selector,可以同时并发处理成百上千个客户端Channel。由于读写 *** 作都是非阻塞的,这就可以充分提升I/O线程的运行效率,避免由于频繁I/O阻塞导致的线程挂起。另外,由于Netty采用了异步通信模式,一个I/O线程可以并发处理N个客户端连接和读写 *** 作,这从根本上解决了传统同步阻塞I/O一连接一线程模型,架构的性能、d性伸缩能力和可靠性都得到了极大的提升。Netty被精心设计,提供了很多独特的性能提升特性,使它做到了在各种NIO框架中性能排名第一,它的性能优化措施总结如下。1)零拷贝:(1)Netty的接收和发送ByteBuffer采用DIRECTBUFFERS,使用堆外直接内存进行Socket读写,不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存(HEAPBUFFERS)进行Socket读写,JVM会将堆内存Buffer拷贝一份到直接内存中,然后才写入Socket中。相比于堆外直接内存,消息在发送过程中多了一次缓冲区的内存拷贝。(2)Netty提供了组合Buffer对象,可以聚合多个ByteBuffer对象,用户可以像 *** 作一个Buffer那样方便地对组合Buffer进行 *** 作,避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。(3)Netty的文件传输采用了transferTo方法,它可以直接将文件缓冲区的数据发送到目标Channel,避免了传统通过循环write方式导致的内存拷贝问题。2)内存池:随着JVM虚拟机和JIT即时编译技术的发展,对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer,情况却稍有不同,特别是对于堆外直接内存的分配和回收,是一件耗时的 *** 作。为了尽量重用缓冲区,Netty提供了基于内存池的缓冲区重用机制。性能测试表明,采用内存池的ByteBuf相比于朝生夕灭的ByteBuf,性能高23倍左右(性能数据与使用场景强相关)。3)无锁化的串行设计:在大多数场景下,并行多线程处理可以提升系统的并发性能。但是,如果对于共享资源的并发访问处理不当,会带来严重的锁竞争,这最终会导致性能的下降。为了尽可能地避免锁竞争带来的性能损耗,可以通过串行化设计,即消息的处理尽可能在同一个线程内完成,期间不进行线程切换,这样就避免了多线程竞争和同步锁。为了尽可能提升性能,Netty采用了串行无锁化设计,在I/O线程内部进行串行 *** 作,避免多线程竞争导致的性能下降。表面上看,串行化设计似乎CPU利用率不高,并发程度不够。但是,通过调整NIO线程池的线程参数,可以同时启动多个串行化的线程并行运行,这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。4)高效的并发编程:volatile的大量、正确使用;CAS和原子类的广泛使用;线程安全容器的使用;通过读写锁提升并发性能。2高性能序列化框架影响序列化性能的关键因素总结如下。1)序列化后的码流大小(网络带宽的占用)。2)序列化&反序列化的性能(CPU资源占用)。3)是否支持跨语言(异构系统的对接和开发语言切换)。4)并发调用的性能表现:稳定性、线性增长、偶现的时延毛刺等。相比于JSON等文本协议,二进制序列化框架性能更优异,以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比,结果如图1-2所示。图1-2 序列化性能测试对比数据在序列化框架的技术选型中,如无特殊要求,尽量选择性能更优的二进制序列化框架,码流是否压缩,则需要根据通信内容做灵活选择,对于、音频、有大量重复内容的文本文件(例如小说)可以采用码流压缩,常用的压缩算法包括GZip、Zig-Zag等。3高性能的Reactor线程模型该模型的特点总结如下。1)有专门一个NIO线程:Acceptor线程用于监听服务端,接收客户端的TCP连接请求。2)网络I/O *** 作:读、写等由一个NIO线程池负责,线程池可以采用标准的JDK线程池实现,它包含一个任务队列和N个可用的线程,由这些NIO线程负责消息的读取、解码、编码和发送。3)1个NIO线程可以同时处理N条链路,但是1个链路只对应1个NIO线程,防止产生并发 *** 作。由于Reactor模式使用的是异步非阻塞I/O,所有的I/O *** 作都不会导致阻塞,理论上一个线程可以独立处理所有I/O相关的 *** 作,因此在绝大多数场景下,Reactor多线程模型都可以完全满足业务性能需求。Reactor线程调度模型的工作原理示意如图1-3所示。图1-3 高性能的Reactor线程调度模型12 业务最佳实践要保证高性能,单依靠分布式服务框架是不够的,还需要应用的配合,应用服务化高性能实践总结如下:1)能异步的尽可能使用异步或者并行服务调用,提升服务的吞吐量,有效降低服务调用时延。2)无论是NIO通信框架的线程池还是后端业务线程池,线程参数的配置必须合理。如果采用JDK默认的线程池,最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式,当线程数过大时,会导致激烈的锁竞争,此时性能不仅不会提升,反而会下降。3)尽量减小要传输的码流大小,提升性能。本地调用时,由于在同一块堆内存中访问,参数大小对性能没有任何影响。跨进程通信时,往往传递的是个复杂对象,如果明确对方只使用其中的某几个字段或者某个对象引用,则不要把整个复杂对象都传递过去。举例,对象A持有8个基本类型的字段,2个复杂对象B和C。如果明确服务提供者只需要用到A聚合的C对象,则请求参数应该是C,而不是整个对象A。4)设置合适的客户端超时时间,防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞,进而引起后续其他服务的消息在队列中排队,造成故障扩散。5)对于重要的服务,可以单独部署到独立的服务线程池中,与其他非核心服务做隔离,保障核心服务的高效运行。6)利用Docker等轻量级OS容器部署服务,对服务做物理资源层隔离,避免虚拟化之后导致的超过20%的性能损耗。7)设置合理的服务调度优先级,并根据线上性能监控数据做实时调整。2事务一致性问题服务化之前,业务采用本地事务,多个本地SQL调用可以用一个大的事务块封装起来,如果某一个数据库 *** 作发生异常,就可以将之前的SQL *** 作进行回滚,只有所有SQL *** 作全部成功,才最终提交,这就保证了事务强一致性,如图2-1所示。服务化之后,三个数据库 *** 作可能被拆分到独立的三个数据库访问服务中,此时原来的本地SQL调用演变成了远程服务调用,事务一致性无法得到保证,如图2-2所示。图2-2 服务化之后引入分布式事务问题假如服务A和服务B调用成功,则A和B的SQL将会被提交,最后执行服务C,它的SQL *** 作失败,对于应用1消费者而言,服务A和服务B的相关SQL *** 作已经提交,服务C发生了回滚,这就导致事务不一致。从图2-2可以得知,服务化之后事务不一致主要是由服务分布式部署导致的,因此也被称为分布式事务问题。21 分布式事务设计方案通常,分布式事务基于两阶段提交实现,它的工作原理示意图如图2-3所示。图2-3 两阶段提交原理图阶段1:全局事务管理器向所有事务参与者发送准备请求;事务参与者向全局事务管理器回复自己是否准备就绪。阶段2:全局事务管理器接收到所有事务参与者的回复之后做判断,如果所有事务参与者都可以提交,则向所有事务提交者发送提交申请,否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚 *** 作。分布式事务回滚原理图如图2-4所示。图2-4 分布式事务回滚原理图两阶段提交采用的是悲观锁策略,由于各个事务参与者需要等待响应最慢的参与者,因此性能比较差。第一个问题是协议本身的成本:整个协议过程是需要加锁的,比如锁住数据库的某条记录,且需要持久化大量事务状态相关的 *** 作日志。更为麻烦的是,两阶段锁在出现故障时表现出来的脆弱性,比如两阶段锁的致命缺陷:当协调者出现故障,整个事务需要等到协调者恢复后才能继续执行,如果协调者出现类似磁盘故障等错误,该事务将被永久遗弃。对于分布式服务框架而言,从功能特性上需要支持分布式事务。在实际业务使用过程中,如果能够通过最终一致性解决问题,则不需要做强一致性;如果能够避免分布式事务,则尽量在业务层避免使用分布式事务。22 分布式事务优化既然分布式事务有诸多缺点,那么为什么我们还在使用呢?有没有更好的解决方案来改进或者替换呢?如果我们只是针对分布式事务去优化的话,发现其实能改进的空间很小,毕竟瓶颈在分布式事务模型本身。那我们回到问题的根源:为什么我们需要分布式事务?因为我们需要各个资源数据保持一致性,但是对于分布式事务提供的强一致性,所有业务场景真的都需要吗?大多数业务场景都能容忍短暂的不一致,不同的业务对不一致的容忍时间不同。像银行转账业务,中间有几分钟的不一致时间,用户通常都是可以理解和容忍的。在大多数的业务场景中,我们可以使用最终一致性替代传统的强一致性,尽量避免使用分布式事务。在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色,它的工作原理如下:在做本地事务之前,先向MQ发送一个prepare消息,然后执行本地事务,本地事务提交成功的话,向MQ发送一个commit消息,否则发送一个rollback消息,取消之前的消息。MQ只会在收到commit确认才会将消息投递出去,所以这样的形式可以保证在一切正常的情况下,本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景,诸如网络超时、VM宕机等。假如系统执行了local_tx()成功之后,还没来得及将commit消息发送给MQ,或者说发送出去由于网络超时等原因,MQ没有收到commit,发生了commit消息丢失,那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问(回调)发消息的系统(checkCommit)进行检查该消息是否应该投递出去或者丢弃,得到系统的确认之后,MQ会做投递还是丢弃,这样就完全保证了MQ和发消息的系统的一致性,从而保证了接收消息系统的一致性。3研发团队协作问题服务化之后,特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组,例如AWS的TwoPizzaTeam,每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。随着服务数的膨胀,研发团队的增多,跨团队的协同配合将会成为一个制约研发效率提升的因素。31 共用服务注册中心为了方便开发测试,经常会在线下共用一个所有服务共享的服务注册中心,这时,一个正在开发中的服务发布到服务注册中心,可能会导致一些消费者不可用。解决方案:可以让服务提供者开发方,只订阅服务(开发的服务可能依赖其他服务),而不注册正在开发的服务,通过直连测试正在开发的服务。它的工作原理如图3-1所示。图3-1 只订阅,不发布32 直连提供者在开发和测试环境下,如果公共的服务注册中心没有搭建,消费者将无法获取服务提供者的地址列表,只能做本地单元测试或使用模拟桩测试。还有一种场景就是在实际测试中,服务提供者往往多实例部署,如果服务提供者存在Bug,就需要做远程断点调试,这会带来两个问题:1)服务提供者多实例部署,远程调试地址无法确定,调试效率低下。2)多个消费者可能共用一套测试联调环境,断点调试过程中可能被其他消费者意外打断。解决策略:绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直联方式将以服务接口为单位,忽略注册中心的提供者列表。33 多团队进度协同假如前端Web门户依赖后台A、B、C和D4个服务,分别由4个不同的研发团队负责,门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高,可以满足交付时间点。但是C和D服务所在团队由于同时需要开发其他优先级更高的服务,因此把优先级排的相对较低,无法满足2周交付。在C和D提供版本之前,门户只能先通过打测试桩的方式完成Mock测试,但是由于并没有真实的测试过C和D服务,因此需求无法按期交付。应用依赖的服务越多,特性交付效率就越低下,交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务,只要1个核心服务没有按期交付,则整个进度就会延迟。解决方案:调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来,基于调用链首入口的交付日期作为输入,利用依赖管理工具,可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具,可以避免人为需求排序失误导致的需求延期。34 服务降级和Mock测试在实际项目开发中,由于小组之间、个人开发者之间开发节奏不一致,经常会出现消费者等待依赖的服务提供者提供联调版本的情况,相互等待会降低项目的研发进度。解决方案:服务提供者首先将接口定下来并提供给消费者,消费者可以将服务降级同Mock测试结合起来,在Mock测试代码中实现容错降级的业务逻辑(业务放通),这样既完成了Mock测试,又实现了服务降级的业务逻辑开发,一举两得。35 协同调试问题在实际项目开发过程中,各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本,往往会造成人力资源浪费,影响项目进度。解决方案:分布式服务框架提供Mock桩管理框架,当周边服务提供者尚未完成开发时,将路由切换到模拟测试模式,自动调用Mock桩;业务集成测试和上线时,则要能够自动切换到真实的服务提供者上,可以结合服务降级功能实现。36 接口前向兼容性由于线上的Bug修复、内部重构和需求变更,服务提供者会经常修改内部实现,包括但不限于:接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。在实际项目中经常会发生服务提供者修改了接口或者数据结构,但是并没有及时知会到所有消费者,导致服务调用失败。解决方案:1)制定并严格执行《服务前向兼容性规范》,避免发生不兼容修改或者私自修改不通知周边的情况。2)接口兼容性技术保障:例如Thrift的IDL,支持新增、修改和删除字段,字段定义位置无关性,码流支持乱序等。4总结服务化之后,无论是服务化框架,还是业务服务,都面临诸多挑战,本章摘取了其中一些比较重要的问题,并给出解决方案和最佳实践。对于本章节没有列出的问题,则需要服务框架开发者和使用者在实践中探索,找出一条适合自己产品的服务化最佳实践。

希望有帮助~实现为DLL的COM组件是一种特殊的DLL,要求符合COM规范,导出特定的函数。只有支持COM标准的DLL才能注册,所谓注册就是在注册表里面写入那些信息。DLL只有DLL一种形式,里面可任意定义函数无限制,只能运行在本机上 ,而COM有DLL和EXE两种存在形式。dll与COM的关系:COM是一种规范,按照是COM规范实现的dll可以被视为COM组件,例如我们用mfc建立的Active X控件工程其中的接口封装是靠idl描述的所以可以视为COM组件。从上面的说明可以看出COM组件的接口是一组具有特定规范的函数,所以COM组件可以视为dll但dll不一定是COM组件。

ContentProvider是干嘛用的?它被用于跨进程做数据共享用。其实你把Android的四大金刚(组件)放到一起,仔细想想他们各自的用途就会发现都是必不可少。他们共同的特点是跨进程。做为java工程师,想写个跨进程的东西不是很好写吧。

Activity用于展示数据内容,不同的activity可以通过intent跨进程进行调用。比如在Gallery中调用邮件分享照片

Service用于实现进程间方法的调用。被举得最多的栗子就是UI调用音乐播放服务。Service不仅仅是在后台运行的一段代码而已。如果是这样的话,为什么不自己写个handle-looper在自己的app中默默运行呢?关键在于跨进程通信ipc。

ContentProvider用于共享数据。多个进程间共享数据,可以通过共享文件的方法,而共享文件的话,权限自己怎么控制呢?linux的内存映射和管道什么的在android好像调用不了,好吧我没调用过 >_<|||。ContentProvider让开发者能够在拥有读写权限的情况下通过一条地址(比如content://comfool/tab1)来访问共享数据。

BroadcastReceiver,可以接收系统和任意app发出的信号intent,如果通过匹配则配触发。同样是跨进程的。

日常开发的大部分任务都是开发单个进程的app,所以这些跨进程的东西有啥用?如果你的app是个大胖子吃了很多内存(比如应用),android对内存是有限制的,oom是经常遇到的头疼的问题吧。android对每个进程的内存使用量是有限制的,而你要是在一个app中开多个进程协同作战,将内存大户发配到不同的进程中,oom就没那么容易了。AndroidManifestxml的activity内有个process属性,用于让app分配不同进程,而默认都在一个进程中。这时,如果你有相同的内容要在两个不同进程的activity中展示,同时在某些情况下要对其修改,是不是就得用进程数据共享了?ContentProvider在这时就有用场了。

大部分时候都只需要调用系统的ContentResolver来 *** 作,调用参数都被封印在androidprovider包的各个类中。MediaStore这个类就很有用哦。访问多媒体资源就靠它了。android继承了linux而拥有了一个类似文件数据库的东西,里面存着各种文件的路径信息。MediaStore就是访问媒体文件的入口。

自己做ContentProvider可以向外提供两种数据:格式化数据和流数据。格式化数据就是类似数据库中的表。当然你不是一提ContentProvider就想起数据库,用一个叫MatrixCursor可以在没有数据库的情况下返回cursor对象。流数据指的就是文件。这包括自己在/data/data中的数据也包括apk中的资源数据。这些数据其他apk在没有root权限的情况下是没法访问的,而ContentProvider说,我能。

怎么自建ContentProvider就去其他地方查吧。

1、不要排斥新技术和新工具。

Android Studio 10 之后的版本,基本已经稳定到可以支持正常的工作开发的程度了。单纯就书写效率而言,Android Studio 带来的好处绝对大于它和Gradle的学习成本。JetBrains的IDE,用过都说好。

还有就是适当的提升targetSdkVersion到新版本。

2、代码设计方面的问题,大部分都能在Android系统源码里找到解决方案。

当你想设计一个新模块,或者实现一个新ui组件的时候,应该采用哪些设计模式、应该以哪种形式给外界提供接口之类的问题,大部分都可以参考Android系统的源码,找到实现方式。Google为安卓程序员提供了一座现成的宝库。

3、理解Android和Java内存管理方式,至少要理解垃圾回收和Java的引用。

就好比学OC就要先理解黄金法则一样,而java的内存管理,其实比OC要好理解多了。

这可能会帮助你大大减少程序异步 *** 作产生的空指针崩溃。也会帮助你理解为什么滥用单例模式会导致内存的臃肿。还会帮助你养成不用“+”去连接超大字符串的好习惯。

4、ContentProvider并不是只有在跨进程共享数据的才有用,把数据库表映射到一个独立的uri是Google鼓励的实现方式。

从设计上讲,用uri(统一资源标识符)去描述数据,肯定比sql语句要理想。

从效果上讲,用CursorLoader读取数据是让iOS程序员都羡慕不已的事情,作为android程序员,何苦不用呢。

5、理解Activity任务栈。

非Activity的Context对象如果直接启动Activity会报错,这只是一个表面现象,真正起作用的其实是Activity任务栈机制。

理解Activity任务栈机制以及Activity的各种启动方式,会帮助解决大部分页面关系错乱问题,以及应用互相掉起、任务栏进入应用、后台d窗引起的各种问题。

6、对于一些奇葩的第三方ROM,调用其非主流api的时候,可以使用反射。

在适配一些第三方ROM的的时候,调用一些在开发环境中没有,但在运行环境中有的方法时,可以使用反射。比方说,华为双卡手机可能会提供获取第二块SIM卡信息的api,如果直接调用,在开发环境可能无法通过正常编译,用反射就没问题。这属于不得已而用反射的一种情况。

7、SQLite的锁,是数据库级别的锁,也就是说同一个数据库的写 *** 作无法并发执行。

所以,在数据库设计的时候,如果表太多,尽量将没有关联的表拆到多个数据库文件中。

8、Bitmap的内存占用问题。

这是一个困扰2X时代android程序员的问题。

2X时代Bitmap对象虽然存储在堆内存中,但是用了一个byte数组存储其像素信息。通过计数器来记录该像素信息被引用的个数。有人认为这个byte数组在native堆中,但事实上它也在堆中。

只有在使用者调用recycle()后,Bitmap对象才会释放像素信息,才会在失去引用后,被垃圾回收机制销毁。再加上DVM的heap size有严格的阀值,所以在使用大量资源的时候,及其容易发生OOM。

解决办法一般都是,用一个哈希表存储Bitmap对象的软引用,作为内存缓存,并在适当时机掉用其recycle()。

30以上版本Bitmap对象可以通过垃圾回收机制完全销毁,理论上不用再调用recycle()。

以上就是关于求救,分布式事务怎么处理全部的内容,包括:求救,分布式事务怎么处理、请问注册DLL有什么用、为什么有contentprovider等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9845568.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存