分布式柔性事务的TCC方案

分布式柔性事务的TCC方案

- 起源 - TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出, 在该论文中,TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司,并且还注册了TCC商标。国内最早可查引进TCC概念,应是阿里程立2008年在 软件开发2.0大会 上分享主题《大规模SOA系统中的分布事务处理》中。 Atomikos公司在商业版本事务管理器ExtremeTransactions中提供了TCC方案的实现,但是由于其是收费的,因此相应的很多的开源实现方案也就涌现出来,如:ByteTCC、Himly、TCC-transaction。但是笔者都不推荐使用,下文会详细说明。 - 组成 - TCC 是一种补偿型事务,该模型要求应用的每个服务提供 try、confirm、cancel 三个接口,它的核心思想是通过对资源的预留(提供中间态,如账户状态、冻结金额等),尽早释放对资源的加锁,如果事务可以提交,则完成对预留资源的确认,如果事务要回滚,则释放预留的资源。 TCC模型完全交由业务实现,每个子业务都需要实现Try-Confirm-Cancel三个接口,对业务侵入大,资源锁定交由业务方。 1、Try:尝试执行业务,完成所有业务检查(一致性),预留必要的业务资源(准隔离性)。 2、Confirm:确认执行业务,不再做业务检查。只使用Try阶段预留的业务资源,Confirm操作满足幂等性。 3、Cancel:取消执行业务释放Try阶段预留业务资源。 一个完整的业务活动由一个主业务服务与若干子业务服务组成: 1、主业务服务负责发起并完成整个业务活动 2、业务服务提供TCC型业务操作。 3、业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在业务活动提交时确认所有的TCC型操作的Confirm操作,在业务活动取消时调用所有TCC型操作的Cancel操作。 成本: 1、 实现TCC操作的成本 2、业务活动结束时Confirm或Cancel操作的执行成本。在Confirm和Cancel范围内的操作成功性需要框架来保证,只能一直重试保证资源被消耗或者释放。 3、业务活动日志成本 适用范围: 1、强隔离性、严格一致性要求的业务活动 2、适用于执行时间较短的业务 - TCC与2PC对比 - TCC将事务提交划分成两个阶段,Try即为一阶段,Confirm 和 Cancel 是二阶段并行的两个分支,二选一。从阶段划分上非常像2PC,我们是否可以说TCC是一种2PC或者2PC变种呢?其实不可以,原因如下: 1、2PC的操作对象在于资源层,对于开发人员无感知;而TCC的操作在于业务层,具有较

Java定时任务框架对比

Java定时任务框架对比

汇总情况 Quzrzt LTS Elastic-Job xxl-Job saturn opencorn antares 1. 什么是集群,分布式定时任务 把分散的,可靠性差的计划任务纳入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。 2. 常见开源方案 elastic-job , xxl-job ,quartz , saturn, opencron , antares, lts 2.1 elastic-job elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 , 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。 Elastic-Job-Lite定位为轻量级无中心化解决方案,使用jar包的形式提供分布式任务的协调服务。 Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案,额外提供资源治理、应用分发以及进程隔离等服务 亮点: 基于quartz 定时任务框架为基础的,因此具备quartz的大部分功能 使用zookeeper做协调,调度中心,更加轻量级 支持任务的分片 支持弹性扩容 , 可以水平扩展 , 当任务再次运行时,会检查当前的服务器数量,重新分片,分片结束之后才会继续执行任务 失效转移,容错处理,当一台调度服务器宕机或者跟zookeeper断开连接之后,会立即停止作业,然后再去寻找其他空闲的调度服务器,来运行剩余的任务 提供运维界面,可以管理作业和注册中心。 官方亮点说明: 分布式 重写Quartz基于数据库的分布式功能,改用Zookeeper实现注册中心。 并行调度 采用任务分片方式实现。将一个任务拆分为n个独立的任务项,由分布式的服务器并行执行各自分配到的分片项。 弹性扩容缩容 将任务拆分为n个任务项后,各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群,或现有服务器下线,elastic-job将在保留本次任务执行不变的情况下,下次任务开始前触发任 务重分片。 集中管理 采用基于Zookeeper的注册中心,集中管理和协调分布式作业的状态,分配和监听。外部系统可直接根据Zookeeper的数据管理和- 监控elastic-job。 定制化流程型任务 作业可分为简单和数据流处理两种模式,数据流又分为高吞吐处理模式和顺序性处理模式,其中高吞吐处理模式可以开启足够多的线程快速的处理数据,而顺序性处理模式将每个分片项分配到一个 独立线程,用于保证同一分片的顺序性。 失效转移 弹性扩容缩容在下次作业运行前重分片,但本次作业执行的过程中,下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样 失效转移功能也会

Docker run 命令参数及使用

Docker run 命令参数及使用

Docker run 命令参数及使用 Docker run :创建一个新的容器并运行一个命令 语法 docker run [OPTIONS] IMAGE [COMMAND] [ARG...] OPTIONS说明: 01.[root@www ~]# docker run --help 02. 03.Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...] 04. 05.Run a command in a new container 06. 07. -a, --attach=[] Attach to STDIN, STDOUT or STDERR 08. --add-host=[] Add a custom host-to-IP mapping (host:ip) 09. --blkio-weight=0 Block IO (relative weight), between 10 and 1000 10. --cpu-shares=0 CPU shares (relative weight) 11. --cap-add=[] Add Linux capabilities 12. --cap-drop=[] Drop Linux capabilities 13. --cgroup-parent= Optional parent cgroup for the container 14. --cidfile= Write the container ID to the file 15. --cpu-period=0 Limit CPU CFS (Completely Fair Scheduler) period 16. --cpu-quota=0 Limit CPU CFS (Completely Fair Scheduler) quota 17. --cpuset-cpus= CPUs in which to allow execution (0-3, 0,1) 18. --cpuset-mems= MEMs in which to allow execution (0-3, 0,1) 19. -d, --detach=false Run container in background and print container ID(后台运行) 20. --device=[] Add a host device to the container 21. --disable-content-trust=true Skip image verification 22. --dns=[] Set custom DNS servers 23. --dns-opt=[] Set DNS options 24. --dns-search=[] Set custom DNS search domains 25. -e, --env=[] Set environment variables(设置环境变量) 26. --entrypoint= Overwrite the default ENTRYPOINT of the image 27. --env-file=[] Read in a file of environment variables 28. --expose=[] Expose a port or a range of ports 29. --group-add=[] Add add

聊聊G1 GC的String Deduplication

聊聊G1 GC的String Deduplication

序 本文主要研究一下G1 GC的String Deduplication -XX:+UseStringDeduplication jdk8u20给G1 GC带来了String Deduplication特性来将相同的字符串指向同一份数据,来减少重复字符串的内存开销 该特性默认是关闭的,可以使用-XX:+UseStringDeduplication来开启(前提是使用-XX:+UseG1GC) 具体的实现大致是JVM会记录char[]的weak reference及hash value,当找到一个hash code相同的String时,就会挨个char进行比较,当所有都match,那么其中一个String就会修改指针指向另一个String的char[],这样前者的char[]就可以被回收 实例 实验代码 @Test public void testG1StringDeduplication() throws InterruptedException { List<String> data = IntStream.rangeClosed(1,10000000) .mapToObj(i -> "number is " + ( i % 2 == 0 ? "odd" : "even")) .collect(Collectors.toList()); System.gc(); long bytes = RamUsageEstimator.sizeOfAll(data); System.out.println("string list size in MB:" + bytes*1.0/1024/1024); System.out.println("used heap size in MB:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage().getUsed()*1.0/1024/1024); System.out.println("used non heap size in MB:" + ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage().getUsed()*1.0/1024/1024); } 关闭StringDeduplication -XX:+UseG1GC -XX:-UseStringDeduplication 输出如下: string list size in MB:586.8727111816406 used heap size in MB:831.772346496582 used non heap size in MB:6.448394775390625 整个jvm heap占用了约831MB,其中string list占用了约586MB 开启StringDeduplication -XX:+UseG1GC -XX:+UseStringDeduplication 输出如下: string list size in MB:296.83294677734375 used heap size in MB:645.0970153808594 used non heap size in MB:6.376350402832031 整个jvm heap占用了约645MB,其中string list占用了约296MB 小结 jdk8u20给G1 GC带来了String Deduplication特性来将相同的字符串指向同一份数据,来减少重复字符串的内存开销 该特性默认是关闭的,可以使用-XX:+UseStringDeduplication来开启(前提是使用-XX:+UseG1GC) 在有大量重复string的前提下,使用G1 GC开启String Deduplication确实能够节省一定的内存,可

JVM第一篇:一个Java内存泄漏的排查案例

JVM第一篇:一个Java内存泄漏的排查案例

最近在看《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家。 这两天在“小怪的java群”里面也对JVM内容进行了一个讨论,讨论的内容主要包括如下几个方面: 1)内存溢出和内存泄露的介绍? 2)如何排查和处理内存泄露? 一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出:你申请了10个字节的空间,但是你在这个空间写入11或以上字节的数据,出现溢出。 2、内存泄漏:你用new申请了一块内存,后来很长时间都不再使用了(按理应该释放),但是因为一直被某个或某些实例所持有导致 GC 不能回收,也就是该被释放的对象没有释放。 下面具体介绍。 1.1 内存溢出 java.lang.OutOfMemoryError,是指程序在申请内存时,没有足够的内存空间供其使用,出现OutOfMemoryError。 产生原因 产生该错误的原因主要包括: JVM内存过小。 程序不严密,产生了过多的垃圾。 程序体现 一般情况下,在程序上的体现为: 内存中加载的数据量过于庞大,如一次从数据库取出过多数据。 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收。 代码中存在死循环或循环产生过多重复的对象实体。 使用的第三方软件中的BUG。 启动参数内存值设定的过小。 错误提示 此错误常见的错误提示: tomcat:java.lang.OutOfMemoryError: PermGen space tomcat:java.lang.OutOfMemoryError: Java heap space weblogic:Root cause of ServletException java.lang.OutOfMemoryError resin:java.lang.OutOfMemoryError java:java.lang.OutOfMemoryError 解决方法 增加JVM的内存大小 对于tomcat容器,找到tomcat在电脑中的安装目录,进入这个目录,然后进入bin目录中,在window环境下找到bin目录中的catalina.bat,在linux环境下找到catalina.sh。 编辑catalina.bat文件,找到JAVA_OPTS(具体来说是 set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%")这个选项的位置,这个参数是Java启动的时候,需要的启动参数。 也可以在操作系统的环境变量中对JAVA_OPTS进行设置,因为tomcat在启动的时候,也会读取操作系统中的环境变量的值,进行加载。 如果是修改了操作系统的环境变量,需要重启机器,再重启tomcat,如果修改的是tomcat配置文件,需要将配置文件保存,然后重启tomcat,设置就能生效了。 优化程序,释放垃圾 主要思路就是避免程序体现上出现的情况。避免死循环,防止一次载入太多的数据,提高程序健壮型及时释放。因此,从根本

联系我们

联系电话

4000-640-466

联系邮箱

service@f-li.cn

办公地址

上海黄浦区外滩源1号

谢谢,您的信息已成功发送。
请填写信息。